Test Execution

In the STLC phases(Test planning, Test Preparation, Test Execution and Test Closure) the Test Execution is the one of the most important phase carried out by the Testers

• Test Plan describes the planning of Test policy and Test strategy. A road map for the entire testing activity
• Test Design describes the design techniques Example: Structural based, Specification based and Experienced based
• Test Execution describes the actual execution of the Test
• Test Closure describes the Entry and Exit criteria of test closure and Summary report of the Tests

Let us see the various phases in Test Execution,

1. Build Verification Test(BVT)
2. Test Case or Script execution
3. Defect Reporting
4. Re-testing or Regression Testing
5. Test Execution status

1. When the developers are ready with the build, the build is released by the manager. Then the Testers will start the BVT by the sanity or smoke test. Only the after the test if the build not with the major defect it is accepted. else the build is rejected

2. Test cases are used in the manual Testing to find the defects where as the Test Scripts are used in the Automation testing to find the defects.

• The specific test cases/script are identified and executed
• Analyze the result by checking the difference in Expected Result and Actual Result
• If Test pass then log the result with the proof of execution and update the Requirement Traceability matrix
• If Test fails testers will raise a defect report and also update in the test execution log, Test status report

The step by step process of test execution

Case 1: “Pass”

1. The results are recorded
2. update the End user document(if required)

Case 2: “Fail”

1. Record results
2. Record the defect
3. when the defect is resolved by the Developers, the Testers will do Re-Testing or Regression Testing

• Verify and confirm the difference between the ER and AR
• Analyze failure by changing the following,

1. Condition
2. Options and Settings
3. Software and hardware configuration
4. data

• Incident summary is prepared

3. Defect Reporting

• The defect can be reported in the excel sheet or in the respective defect management tool as per the Test policy which may vary project to project.
• IEEE standard for the Test Defect Report
  • Defect ID
  • Defect Description
  • Build Version ID
  • Module name
  • Test Case ID
  • Reproducible
  • Severity
  • Priority
  • Test Environment
  • Status
  • Tester Name
  • detected on
  • Reported to
  • Reviewed by
  • Suggested Fix(Optional)

Bug Life Cycle

• New – When a bug is raised it will be in the new state
• Assigned – When the bug is assigned to the developer
• Resolved – When developers fixed or rectified the bug
• Reopen – When the resolution was deemed incorrect
• Verified – When the QA verifies the solution works
• Closed -  When the bug is verified and closed
• Deferred or Rejected – When a bug is ignored or rejected by the developers when it is duplicate, invalid ro wont fix.

4. Re- Testing is done to confirm that the defect is fixed.

Regression Testing is done to check that the defect is fixed and the fixing does not cause a new defect in the unaffected area. Hence it is tested through automated scripts which may runs multiple times.

5. Test Execution Status

The test execution report contains

• Total no of Test Cases
• total no of test executed
• no of failed
• no of defect fixed
• no of defect rejected