Lesson 89: Final Execution & Debugging
The Junior Trap: “Just Run It and Hope”
Picture a junior QA engineer on their first CI/CD project. They’ve written 200 tests across three suites — Web, API, and Mobile. The night before the production release, they run everything manually on their laptop. Green. All green. They push to GitHub, the pipeline triggers, and 40 minutes later the build is red. Seventeen tests failed. But when they run those same tests locally? Green again.
This is test flakiness, and it is the #1 reason QA teams lose credibility with engineering leadership.
The junior’s approach has three fatal assumptions:
Assumption 1: “My machine = CI server.” Your laptop has a cached browser, a warm OS, no competing processes, and a stable network. The CI runner has none of these.
Assumption 2: “Sequential is safe.” Running Web tests, then API tests, then Mobile tests — one after the other — hides resource conflicts. When pipelines parallelize (and they always do eventually), the conflicts explode.
Assumption 3: “A failure is a failure.” The junior sees a red test and rewrites it. But if that test was flaky — passing 7/10 times — rewriting it doesn’t fix the root cause. You’ve just hidden the symptom.
The result: time.sleep(5) everywhere, tests that only pass with a full moon, and a CI pipeline no one trusts.
