Key stages in a testing process

T Srinivasan Managing Director Mercury - India

Recent years have brought a major breakthrough in the field of application testing. Following are some of the common and critical testing stages/processes that organisations could adopt to centralise, organise, prioritise and document their testing efforts.

Requirements Management: Most organizations are still using word-processing tools or spreadsheets to track requirements; however, commercial tools designed for requirements management are a better choice for organisations that want to create a solid, flexible requirements-based testing process. There are a variety of tools to create, store and document requirements and aid the creation, trace ability and management of application requirements.

Planning Tests: Planning tests and designing applications can and must be done simultaneously so that there is a scope to create a complete set of tests that covers each function the system is designed to perform. The test planning must identify test-creation standards and guidelines; select hardware and software for the test environment; assign roles and responsibilities; define the test schedule; and set procedures for running, controlling and measuring the testing process.

Set the Ground Rules: Testers don't need overly bureaucratic processes to slow them down, but ambiguities and lack of clearly defined procedures can make testing a bottleneck for product deliverables. This stage can be used for setting the ground rules for keeping test logs and documentation, assigning roles within the team, agreeing on the naming convention for tests and defects, and defining the procedure for tracking progress against the project goals.

Agree on the Naming Convention: The key to effective defect management is communication among different parties involved in the process. Before reporting mechanisms can be put into place, the testing team needs to set the ground rules, such as define the severity of the bugs and agree on what information must be included in the defect report. For example, many testing organisations categorise defects as follows:

• Cosmetic/UI
  
• Inconsistency
  
• Loss of functionality
  
• System crash
  
• Loss of data

Cosmetic and inconsistency defects are the easiest to report and handle. Although they make it more difficult to use the system, they don't affect system functionality. The defects that result in loss of functionality are more severe and therefore more urgently need to be fixed. Defects that cause the system to crash, or worse - lose data - are commonly referred to as "show-stoppers." These must be documented as thoroughly as possible, and must be fixed before the system goes live.

Map Test Data:Test-data requirements need to be mapped against test procedures. The testing team must understand what types of data need to be obtained to support each type of test, and how this data could be obtained or generated.

Design Test Architecture:Test architecture helps testers get a clear picture of the test building blocks and assists in developing the actual tests. Test architecture helps plan for data dependencies, map the workflow between tests and identify common scripts that can potentially be reused for future testing.

Communicate the Test Plan: Once the test cases have been created, it's helpful to create a master test plan and communicate it to the rest of the organisation - specifically project leaders, developers and marketing - letting them know the areas on which the testing group will be working. This way, more people in the organization have the visibility into the project and can add their input, questions or comments before the actual testing begins.

Analyse Test-Run Results: During the test-execution phase, testers will uncover application inconsistencies, broken functionality, missing features and other problems commonly referred to as "bugs" or "defects." The next step is to view the list of all failed tests and determine what caused the test to fail. If the tester determines that the test failed due to an application defect, this defect has to be reported into the defect tracking system for further investigation, correction and re-test.

Re-Test Repairs: Whatever fixes or changes have been made to repair a known defect, the application needs to be re-tested to verify that the changes have taken effect and that the fix did not introduce additional problems and unexpected "side effects." If the defect does not appear during the re-testing phase, its status can be changed to "closed." If the problem persists and/or the fix has introduced additional problems, the defect is reopened and the cycle is repeated.

Analyse Defects: Analysing defects is the most critical part of the defect-tracking process. It allows testers to take a snapshot of the application under test and view the number of known defects, their status, severity, priority, age, etc. Based on defect analysis, management is able to make an informed decision as to whether the application is ready to be deployed.