Phase 5: Test Execution
Test execution is where QA engineers run test cases against the software and determine pass/fail. But professional execution goes far beyond mechanically running scripts - it involves risk-based prioritization, defect management parallel to execution, continuous progress reporting, and adaptive replanning when conditions change.
Executing Tests Professionally
- Prioritize by risk: Don't execute test cases in ID order. Execute critical path and high-risk tests first. If the project is cut short, the most important tests are done
- Log defects immediately: Don't execute 50 tests and log bugs later. Log defects as you find them so developers can start fixing while you continue testing - parallel defect resolution dramatically reduces cycle time
- Capture evidence: Screenshot or video every defect. A bug report without reproduction evidence costs the developer hours of investigation
- Track execution metrics daily: Tests planned vs executed, pass/fail count, defects opened/closed by severity. Share daily status with the team - no one should be surprised by quality status on release day
- Re-test and regression: Every fixed defect needs a re-test. Every re-test triggers targeted regression on related functionality. Tracking this explicitly prevents the common failure where a fix breaks something else and goes undetected
Entry and Exit Criteria - Phase 5
Entry criteria: Test environment validated and stable, test data prepared, test cases reviewed and approved, build deployed to test environment. Exit criteria: All planned test cases executed (or risk-based decision documented for skipped cases), all critical and high-severity defects fixed and re-tested, defect escape rate within acceptable threshold, Test Summary Report prepared. The exit criteria protect against the common pressure to 'just ship it' when testing is incomplete - stakeholders who agreed to the criteria at planning time can't demand release unless criteria are met.
Combine manual + automated testing for comprehensive coverage
Tip
Tip
Practice Phase 5 Test Execution in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Practice Task
Note
Practice Task - (1) Write a working example of Phase 5 Test Execution from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with Phase 5 Test Execution is skipping edge case testing - empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready qa engineering code.
Key Takeaways
- Test execution is where QA engineers run test cases against the software and determine pass/fail.
- Prioritize by risk: Don't execute test cases in ID order. Execute critical path and high-risk tests first. If the project is cut short, the most important tests are done
- Log defects immediately: Don't execute 50 tests and log bugs later. Log defects as you find them so developers can start fixing while you continue testing - parallel defect resolution dramatically reduces cycle time
- Capture evidence: Screenshot or video every defect. A bug report without reproduction evidence costs the developer hours of investigation