Monday, September 27, 2010

Test Strategy 2

What is Test Strategy?

In simple words – Test strategy means “How you are going to test the application?” You need to mention the exact process/strategy that you are going to follow when you will get the application for testing.

I see many companies follow test strategy template very strictly. Even without any standard template you can keep this test strategy document simple but still effective.


Simple Tips to Write Test Strategy Document:

1) Include product background in test strategy document. In first paragraph of your test strategy document answer – Why stakeholders want to develop this project? This will help to understand and prioritize things quickly.


2) List all important features you are going to test. If you think some features are not part of this release then mention those features under “Features not to be tested” label.


3) Write down the test approach for your project. Clearly mention what types of testing you are going to conduct?
I.e. Functional testing, UI testing, Integration testing, Load/Stress testing, Security testing etc.


4) Answer questions like: How you are going to perform functional testing? Manual or automation testing? Are you going to execute all test cases from your test management tool?


5) Which bug tracking tool you are going to use? What will be the process when you will find a new bug?


6) What are your test entry and exit criteria?


7) How you will track your testing progress? What metrics are you going to use for tracking test completion?


8 ) Task distribution – Define roles and responsibilities of each team member.


9) What documents you will produce during and after testing phase?


10) What all risk you see in test completion?


Test Strategy 1

How do you create a test strategy?

The test strategy is a formal description of how a software product will be tested. A test strategy is developed for all levels of testing, as required. The test team analyzes the requirements, writes the test strategy and reviews the plan with the project team. The test plan may include test cases, conditions, the test environment, a list of related tasks, pass/fail criteria and risk assessment.


Inputs for this process:


- A description of the required hardware and software components, including test tools. This information comes from the test environment, including test tool data.


- A description of roles and responsibilities of the resources required for the test and schedule constraints. This information comes from man-hours and schedules.

- Testing methodology. This is based on known standards.

- Functional and technical requirements of the application. This information comes from requirements, change request, technical and functional design documents.

- Requirements that the system can not provide, e.g. system limitations.


Outputs for this process:

- An approved and signed off test strategy document, test plan, including test cases.

- Testing issues requiring resolution. Usually this requires additional negotiation at the project management level.


What Test plan and what it consists?

What Test plan and what it consists for Software Testing Projects ?


Test plan: It contains item to test & it is a statagic document. It consists of 
objectives ,scope ,approach and focus in software testing effort



Test Consist :
1)Revision history
2)Introduction
3)Objective
4)Process
5)Test Strategy
6)Entry/Exit Criteria
7)Schedule
8)Milestone
9)Deliverable
10)Commands


Types of Software Testing 2

The development process involves various types of testing. Each test type addresses a specific testing requirement. The most common types of testing involved in the development process are:

• Unit Test.
• System Test
• Integration Test
• Functional Test
• Performance Test
• Beta Test
• Acceptance Test.


Unit Test
The first test in the development process is the unit test. The source code is normally divided into modules, which in turn are divided into smaller units called units. These units have specific behavior. The test done on these units of code is called unit test. Unit test depends upon the language on which the project is developed. Unit tests ensure that each unique path of the project performs accurately to the documented specifications and contains clearly defined inputs and expected results.

System Test
Several modules constitute a project. If the project is long-term project, several developers write the modules. Once all the modules are integrated, several errors may arise. The testing done at this stage is called system test.


System testing ensures that the entire integrated software system meets requirements. It tests a configuration to ensure known and predictable results. System testing is based on process descriptions and flows, emphasizing pre-driven process links and integration points.


Testing a specific hardware/software installation. This is typically performed on a COTS (commercial off the shelf) system or any other system comprised of disparent parts where custom configurations and/or unique installations are the norm.

Functional Test
Functional test can be defined as testing two or more modules together with the intent of finding defects, demonstrating that defects are not present, verifying that the module performs its intended functions as stated in the specification and establishing confidence that a program does what it is supposed to do.

Acceptance Testing
Testing the system with the intent of confirming readiness of the product and customer acceptance.

Ad Hoc Testing
Testing without a formal test plan or outside of a test plan. With some projects this type of testing is carried out as an adjunct to formal testing. If carried out by a skilled tester, it can often find problems that are not caught in regular testing. Sometimes, if testing occurs very late in the development cycle, this will be the only kind of testing that can be performed. Sometimes ad hoc testing is referred to as exploratory testing.

Alpha Testing
Testing after code is mostly complete or contains most of the functionality and prior to users being involved. Sometimes a select group of users are involved. More often this testing will be performed in-house or by an outside testing firm in close cooperation with the software engineering department.

Automated Testing
Software testing that utilizes a variety of tools to automate the testing process and when the importance of having a person manually testing is diminished. Automated testing still requires a skilled quality assurance professional with knowledge of the automation tool and the software being tested to set up the tests.

Beta Testing
Testing after the product is code complete. Betas are often widely distributed or even distributed to the public at large in hopes that they will buy the final product when it is released.

Black Box Testing
Testing software without any knowledge of the inner workings, structure or language of the module being tested. Black box tests, as most other kinds of tests, must be written from a definitive source document, such as a specification or requirements document.

Compatibility Testing
Testing used to determine whether other system software components such as browsers, utilities, and competing software will conflict with the software being tested.


Configuration Testing
Testing to determine how well the product works with a broad range of hardware/peripheral equipment configurations as well as on different operating systems and software.

Independent Verification & Validation
The process of exercising software with the intent of ensuring that the software system meets its requirements and user expectations and doesn't fail in an unacceptable manner. The individual or group doing this work is not part of the group or organization that developed the software. A term often applied to government work or where the government regulates the products, as in medical devices.

Installation Testing
Testing with the intent of determining if the product will install on a variety of platforms and how easily it installs.

Integration Testing
Testing two or more modules or functions together with the intent of finding interface defects between the modules or functions. Testing completed at as a part of unit or functional testing, and sometimes, becomes its own standalone test phase. On a larger level, integration testing can involve a putting together of groups of modules and functions with the goal of completing and verifying that the system meets the system requirements. (see system testing)

Load Testing
Testing with the intent of determining how well the product handles competition for system resources. The competition may come in the form of network traffic, CPU utilization or memory allocation.

Performance Testing
Testing with the intent of determining how quickly a product handles a variety of events. Automated test tools geared specifically to test and fine-tune performance are used most often for this type of testing.

Pilot Testing
Testing that involves the users just before actual release to ensure that users become familiar with the release contents and ultimately accept it. Often is considered a Move-to-Production activity for ERP releases or a beta test for commercial products. Typically involves many users, is conducted over a short period of time and is tightly controlled. (see beta testing).


Regression Testing
Testing with the intent of determining if bug fixes have been successful and have not created any new problems. Also, this type of testing is done to ensure that no degradation of baseline functionality has occurred.


Security Testing
Testing of database and network software in order to keep company data and resources secure from mistaken/accidental users, hackers, and other malevolent attackers.

Software Testing
The process of exercising software with the intent of ensuring that the software system meets its requirements and user expectations and doesn't fail in an unacceptable manner. The organization and management of individuals or groups doing this work is not relevant. This term is often applied to commercial products such as internet applications. (contrast with independent verification and validation)

Stress Testing
Testing with the intent of determining how well a product performs when a load is placed on the system resources that nears and then exceeds capacity.

User Acceptance Testing
See Acceptance Testing.

White Box Testing
Testing in which the software tester has knowledge of the inner workings, structure and language of the software, or at least its purpose.


Types of software Testing 1

There are several Software Testing Types are  describe below:

Black box testing – Internal system design is not considered in this type of testing. Tests are based on requirements and functionality.


White box testing – This testing is based on knowledge of the internal logic of an application’s code. Also known as Glass box Testing. Internal software and code working should be known for this type of testing. Tests are based on coverage of code statements, branches, paths, conditions.


Unit testing – Testing of individual software components or modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. may require developing test driver modules or test harnesses.

Incremental integration testing – Bottom up approach for testing i.e continuous testing of an application as new functionality is added; Application functionality and modules should be independent enough to test separately. done by programmers or by testers.

Integration testing – Testing of integrated modules to verify combined functionality after integration. Modules are typically code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.

Functional testing – This type of testing ignores the internal parts and focus on the output is as per requirement or not. Black-box type testing geared to functional requirements of an application.

System testing – Entire system is tested as per the requirements. Black-box type testing that is based on overall requirements specifications, covers all combined parts of a system.

End-to-end testing – Similar to system testing, involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.

Sanity testing - Testing to determine if a new software version is performing well enough to accept it for a major testing effort. If application is crashing for initial use then system is not stable enough for further testing and build or application is assigned to fix.

Regression testing – Testing the application as a whole for the modification in any module or functionality. Difficult to cover all the system in regression testing so typically automation tools are used for these testing types.

Acceptance testing -Normally this type of testing is done to verify if system meets the customer specified requirements. User or customer do this testing to determine whether to accept application.

Load testing – Its a performance testing to check system behavior under load. Testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system’s response time degrades or fails.

Stress testing – System is stressed beyond its specifications to check how and when it fails. Performed under heavy load like putting large number beyond storage capacity, complex database queries, continuous input to system or database load.

Performance testing – Term often used interchangeably with ’stress’ and ‘load’ testing. To check whether system meets performance requirements. Used different performance and load tools to do this.

Usability testing – User-friendliness check. Application flow is tested, Can new user understand the application easily, Proper help documented whenever user stuck at any point. Basically system navigation is checked in this testing.

Install/uninstall testing - Tested for full, partial, or upgrade install/uninstall processes on different operating systems under different hardware, software environment.

Recovery testing – Testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.

Security testing – Can system be penetrated by any hacking way. Testing how well the system protects against unauthorized internal or external access. Checked if system, database is safe from external attacks.

Compatibility testing – Testing how well software performs in a particular hardware/software/operating system/network environment and different combination s of above.

Comparison testing – Comparison of product strengths and weaknesses with previous versions or other similar products.

Alpha testing – In house virtual user environment can be created for this type of testing. Testing is done at the end of development. Still minor design changes may be made as a result of such testing.

Beta testing – Testing typically done by end-users or others. Final testing before releasing application for commercial purpose.

 @ Happy Testing @

SDLC and STLC

SDLC is software development life cycle which has the following stages.

1. Requirement or Information gathering
2. Analysis
3. Design
4. Coding/implementation
5. Testing
6. Installation
7. Release and maintenance

Whereas STLC is software testing life cycle which is a part of SDLC and has the following stages:


1. Requirement
2. Prepare test plan
3. Review
4. Prepare test cases
5. Execute the test
6. report analysis
7. Bug analysis(log the bugs)
8. Bug report
9. Close testing


System testing and Functional testing

Functional testing -> is the technique utilized in the system tesing.Its a black box testing type... Functional testing is noting but testing or check whether a sytem functions properly as per the req..  

System testing -> is the phase after integration testing phase.After all modules get integrated and tested for integration, the system is tested as a whole.

Saturday, September 25, 2010

3 Layer Architecture Model





Figure : 3 Layer Architecture Model

Why we are Useing Stored Procedures ?

There are several advantages of using stored procedures instead of standard SQL.

1. Stored procedures allow a lot more flexibility offering capabilities such as conditional logic.

2. Because stored procedures are stored within the DBMS, bandwidth and execution time are reduced. This is because a single stored procedure can execute a complex set of SQL statements.

3. SQL Server pre-compiles stored procedures such that they execute optimally.

4. Client developers are abstracted from complex designs. They would simply need to know the stored procedure's name and the type of data it returns.

Sunday, September 5, 2010

eid mubarak

wish u all HAPPY

Eid Mubarak 2010

thanks

rose 2010 : 3




gift




rose 2010 : 2




rose 2010 :1





poem