Overview of the QA Testing Process
The QA Testing Process used at UConn generally follows the emerging Software Testing Life Cycle (STLC) Process. Understanding this process will help every member of the test team, especially when problems arise, by providing a framework and a direction for the testing process.
Software Testing should start very early in the project life-cycle, as soon as there’s a Functional Requirements Document (FRD). The STLC consists of a series of phases carried out methodically to help certify the Application Under Test. These phases are shown here.
Although, it appears that each phase of the STLC is done sequentially, that is not necessarily the case. Some of the phases are dependent on others, and some can happen simultaneously with others. Understanding each phase in the STLC will help to ensure that the testing process flows smoothly and is efficient and effective. Below is a detailed description of each phase of the STLC:
Requirements Analysis Phase
In this first phase of the STLC, the test team reviews the Functional Requirements Document (FRD) to determine what is testable. By studying the requirements, the test team gets a good understanding of the scope and the types of the testing to be done. This phase involves meeting with managers, developers, users, and business owners. Reaching agreement on the requirements is at the core of the user-developer partnership.
During this phase,
- Business Owners agree that the requirements meet their needs.
- Developers agree that they understand the requirements and that they are feasible.
- Testers agree that the requirements are verifiable.
- Management agrees that the requirements will achieve their business needs.
From these requirements, the test team will start creating a list of test scenarios.
|– Functional Requirements Document (FRD).||– Gain agreement on the Functional Requirements Document with the test team.
– Determine the types of testing to be performed like Functional, performance & load, user acceptance, etc.
– Determine the Test environment details where testing activities will be carried out.
– Check out the Automation feasibility (if required) & prepare the Automation feasibility report.
|– An updated FRD.
– A list of Test Scenarios.
Test Planning Phase
Test Planning is the most important phase of the STLC, where all testing strategy is defined. What to test, how the test needs to be done, and who’s going to test it? These are the things determined during the test planning phase. Once the requirements have been reviewed, it’s time to plan the testing process at a high level. The test plan document is created to organize all of the information gathered from this phase. This starts to get everyone on the same page as far as how the testing project will be approached.
In this phase, also, the Test Lead will determine the effort and cost estimates for the testing portion of the project. The result of the Test Planning phase will be the Test Plan and the Testing Effort Estimation document. The test planning phase is not always completed before the QA team starts with the next phase, the test case development phase.
|– The updated FRD.
– Automation feasibility report. (Not currently being used.)
|– Define the objective & scope.
– Determine the testing approach: the strategy.
– Determine test effort estimation and resource planning.
– Define the testing process overview.
– Define the test environment required for entire project.
– Determine the test and reporting schedules.
– Define the control procedures.
– Determine the roles and responsibilities.
– Define the entry criteria, and the suspension, resumption, and exit criteria.
– Define the risk involved if any.
– Specify a testing tool if required.
|– Test Plan document.
– Testing Effort Estimation document.
Test Case Development Phase
The goal of this phase is to determine “how” to test. Depending on the context of the project, either test cases or test scenarios will be developed here. (This phase should be changed to the Test Strategy Phase.)
If test cases will be used, they will be written to guide the tester through each test. Prepare any test data required to run the tests during this phase so you don’t have to spend time doing this during the tests.
The test case development phase is started once the Functional Requirements Document is finished. Also the Requirement Traceability Matrix (RTM) is prepared in this phase. The RTM is an industry-accepted format for tracking requirements to ensure that each test case is mapped with a requirement, and that all requirements are being tested. Once the test cases/scenarios and the RTM are ready, they are reviewed by peer members of the QA Test Team.
|– The updated FRD.
– Automation feasibility report. (For when Automation is used.)
|– Preparation of test cases.
– Test data preparation for executing test cases.
– Preparation of test automation scripts (if required).
– Test cases. (if required)
– Test data.
– Test Automation Scripts. (if required)
Environment Setup Phase
Setting up the test environment is a vital part of the STLC. It’s the configuration of software and/or hardware on which the testing team is to perform the tests.
The process of setting up the test environment does not necessarily involve the test team. Depending on the company or the situation, the developer or vendor may create the test environment. If this is the case, the test team should be prepared to do a readiness check, a Build Verification Test (BVT) of the given environment setup. Make sure any test data necessary is entered into the system and ready to be used. It’s not uncommon for this phase to happen alongside the test case development phase.
|– Test Plan is available.
– Build Verification test cases are available.
– Test data is available.
|– Analyze the requirements and prepare the list of software & hardware required to set up test environment.
– Setup the test environment and test data.
– Once the Test Environment is setup execute the Build Verification test cases to check the readiness of the test environment.
|– Test Environment will be ready with test data.
– Result of Build Verification test cases.
Test Execution Phase
Once the environment is setup, the test strategy is determined, and the test plan is approved, it’s time to run the tests. Much of the testing will be exploratory in nature, using the test scenarios as a guide. This method finds the most defects in the shortest time.
If the users and operators will be performing the tests, the test cases will be used. The testers will execute each test, comparing the results to the expected results, and marking it as pass, fail, or skip. If the test fails, the tester should document what actually happened during the test. This phase also involves the tester logging bugs into the designated bug tracking system (determined in the test plan). Once the defect is fixed by the development team, then the same test case can be rerun based on your test plan.
|– Test Plan document complete and signed off.
– Test cases and scripts complete.
– Environment and test data ready.
|– Execute the test cases based on the test plan.
– Mark status of test cases based on the test plan.
– Do retesting once the defects are fixed.
– Track the defects to closure.
|– Test case execution report.
– Defect report.
Test Cycle Closure
Once all the tests cases are run, the QA Test Lead should confirm all required testing has been completed. This involves an analysis of defects found and other metrics such as how many passed/failed/skipped test cases. This final phase in the STLC might also include a retrospective on the testing project/process. This allows the team to learn and improve for future testing projects.
|– Test case execution is completed.
– Test case Execution report.
– Defect report.
|– Evaluate cycle completion criteria based on Test coverage, Quality, Cost, Time, Critical Business Objectives, and Software Prepare test metrics based on the above parameters.
– Prepare the Final Test report.
– Share best practices for any similar projects in the future.
|– Final Test report.
– Test metrics.