SQA Processes. How to Test complete application?

Is there any standard procedure to test the application as a whole? Or How can I test complete application right from the requirement SQA Processes. How to Test complete application?

Is there any standard procedure to test the application as a whole? Or How can I test complete application right from the requirement gathering?

Here are the broad steps to test the application :These are the standard SQA peocesses to be followed in any application testing.

ñ  Marketing Requirements 

 Review of the Objectives set for the Last Released Build
Objectives remaining to be completed are carried forward for the next release.

ñ Branching for the development cycle 

ñ Objectives settings for the Major and customized releases 

Target Date planned for the Releases and decision on the entire Project schedule that is required to achieve these target dates.

ñ A Detailed Project Plan and the release of design Specifications 

This includes the decision on Design Specifications (Productwise), review of the design specs and development schedule. This involves QA during the phase of review.

ñ QA – Develop Test Plan based on Design Specifications 

Test Plan : This is a top-level document that talks about how the product is going to be tested
This includes Objectives, Methodology adopted while testing, Features to be tested and not to be tested, risk criteria, testing schedule, cross-platform support and the resource allocation for testing.

Feature Test Plan : This document talks about how the testing is going to be carried out for each type of testing.

ñ QA – Functional Test Specifications 

This document includes technical details (Software requirements) required prior to the testing. It is important from the tester’s point of view to understand and plan the technical resources prior to the testing.

Application Development : Considering the product features, tester has to make ready his/her own test suit.

ñ QA – Writing of Test Cases (CM) 

- Smoke (BVT) test cases
- Sanity Test cases
- Regression Test Cases
- Extended Test Cases
- Negative Test Cases

ñ Development – Goes on Module by Module. 

ñ Installers Binding and Building 

- Installers are built around the individual product.
- Release Engg is responsible for releasing the Builds.
- Release Engg collects fresh/developed code from the developer’s initially/module wise.
- Installers have to take care of jar files updating, registry entries, and additional software installations.

ñ Build Procedure : 

- A build includes Installers of the available products – multiple platforms.
- For each build one or 2 CDs are made/build the same are pushed to Pune/Chennai based on the priority.
- Each product build are received in the form of zip files under http://pun-qaftp/ftproot/QA-Builds ( Pune-Specific). The procedure goes along for Chennai. San Jose QA picks up builds from Nexus ( Build Specific Server )
- The same zip files need to be unzipped to get the desired installer and the same is put at Pun_fps1/QA/Builds folder. ( Pune-Specific)

ñ QA – Testing : 

- Smoke Test (BVT) to check basic features of the product.
- Smoke Test results has to be posted on http://Chaquita which is an official site for posting Smoke
- Test results and to share the basic testing information.
- Prepare Smoke Test procedure.

ñ QA – Extensive testing : 

- Testing of new features
- Document review
- Cross-platform testing
- Stress testing and memory leakage testing.

ñ QA- Bug Reporting : 

- Use of Trackweb’s “Soffront” as the Bug Tracking tool.
- Further FET (Fixed Effectiveness testing) of the filed bugs.
- Exception study and verification.

ñ Development – Code freeze : 

No more new features are added at this point.

ñ QA – Testing : 

Candidate Builds and regression testing.

ñ QA- Media Verification : 

CDs are cut for the released products and the product is installed using those CDs and it takes place in San Jose.

ñ Decision to release the product : 

A review meeting to analyze the performance of the product, which is set, and the same is compared with the objectives set.

ñ Post-release Scenario : 

One branch is kept for the post release modification and hence the product testing.
Post release review meeting to decide upon the objectives for the next release.

gathering?

Here are the broad steps to test the application :These are the standard SQA peocesses to be followed in any application testing.

ñ  Marketing Requirements 

 Review of the Objectives set for the Last Released Build
Objectives remaining to be completed are carried forward for the next release.

ñ Branching for the development cycle 

ñ Objectives settings for the Major and customized releases 

Target Date planned for the Releases and decision on the entire Project schedule that is required to achieve these target dates.

ñ A Detailed Project Plan and the release of design Specifications 

This includes the decision on Design Specifications (Productwise), review of the design specs and development schedule. This involves QA during the phase of review.

ñ QA – Develop Test Plan based on Design Specifications 

Test Plan : This is a top-level document that talks about how the product is going to be tested
This includes Objectives, Methodology adopted while testing, Features to be tested and not to be tested, risk criteria, testing schedule, cross-platform support and the resource allocation for testing.

Feature Test Plan : This document talks about how the testing is going to be carried out for each type of testing.

ñ QA – Functional Test Specifications 

This document includes technical details (Software requirements) required prior to the testing. It is important from the tester’s point of view to understand and plan the technical resources prior to the testing.

Application Development : Considering the product features, tester has to make ready his/her own test suit.

ñ QA – Writing of Test Cases (CM) 

- Smoke (BVT) test cases
- Sanity Test cases
- Regression Test Cases
- Extended Test Cases
- Negative Test Cases

ñ Development – Goes on Module by Module. 

ñ Installers Binding and Building 

- Installers are built around the individual product.
- Release Engg is responsible for releasing the Builds.
- Release Engg collects fresh/developed code from the developer’s initially/module wise.
- Installers have to take care of jar files updating, registry entries, and additional software installations.

ñ Build Procedure : 

- A build includes Installers of the available products – multiple platforms.
- For each build one or 2 CDs are made/build the same are pushed to Pune/Chennai based on the priority.
- Each product build are received in the form of zip files under http://pun-qaftp/ftproot/QA-Builds ( Pune-Specific). The procedure goes along for Chennai. San Jose QA picks up builds from Nexus ( Build Specific Server )
- The same zip files need to be unzipped to get the desired installer and the same is put at Pun_fps1/QA/Builds folder. ( Pune-Specific)

ñ QA – Testing : 

- Smoke Test (BVT) to check basic features of the product.
- Smoke Test results has to be posted on http://Chaquita which is an official site for posting Smoke
- Test results and to share the basic testing information.
- Prepare Smoke Test procedure.

ñ QA – Extensive testing : 

- Testing of new features
- Document review
- Cross-platform testing
- Stress testing and memory leakage testing.

ñ QA- Bug Reporting : 

- Use of Trackweb’s “Soffront” as the Bug Tracking tool.
- Further FET (Fixed Effectiveness testing) of the filed bugs.
- Exception study and verification.

ñ Development – Code freeze : 

No more new features are added at this point.

ñ QA – Testing : 

Candidate Builds and regression testing.

ñ QA- Media Verification : 

CDs are cut for the released products and the product is installed using those CDs and it takes place in San Jose.

ñ Decision to release the product : 

A review meeting to analyze the performance of the product, which is set, and the same is compared with the objectives set.

ñ Post-release Scenario : 

One branch is kept for the post release modification and hence the product testing.
Post release review meeting to decide upon the objectives for the next release.