Process · Test Release
Get builds into the lab without wasting a cycle.Seven steps, two smoke-test gates.
A broken build in the test lab burns a cycle and a morale dividend. These seven steps (anchored by two smoke-test gates) prevent that by catching failures before they reach the team.
- Steps
- 7
- Smoke-test gates
- 2
- Applies to
- Every test release
The test release process is the most under-engineered link in most test programs. Fix the link and the whole execution cycle stops leaking days.
Key takeaways
Four things to remember.
01
Decide content before you cut the build
Bug fixes, features, docs, resolve what is in and what is out before development spins up. A build with ambiguous content produces ambiguous test results.
02
Smoke test twice
Once after build, once after install in the lab. The same test from two sides catches different classes of failure.
03
Reject bad builds loudly
When the lab smoke test fails, uninstall and resume the old cycle. Do not try to salvage a half-working build; it costs more than it saves.
04
Version everything
Mark the build with a version both in the artifact and in the source repository. Traceability during triage depends on it.
Why this exists
The problem this process fixes.
Test releases are where time gets lost. A build lands, a test case fails, a tester files a bug, a developer responds that the build is broken, and four days of reporting later, the team realizes nobody actually ran a smoke test.
These seven steps close that gap. The two smoke-test gates (after build, after install) make the question "is the build good enough to test?" answered in minutes, not days.
The checklist
7 steps, in order.
- 1
Select the content (bug fixes, new features, and documentation) for a particular test release.
- 2
Implement the changes required for the bug fixes and new features, checking those changes into the source repository as they are completed and unit tested.
- 3
Fetch the source files from the repository; compile, link, and otherwise assemble the build; and, mark (in the build and in the repository) the build with a version number.
- 4
Smoke test the build. If the tests pass, continue with the next step; if the tests fail, figure out what went wrong, fix the problem, and return to the previous step.
- 5
Create an installable media image of the build; package it appropriately; and, deliver it to the person responsible for installing it in the test lab.
- 6
Install the build in the test lab.
- 7
Smoke test the build in the lab environment. If the tests pass, begin the test cycle; if the tests fail, uninstall the build, resume the old test cycle, and return the build to the development team to start over at the first step.
One more thing
The seven-step sequence takes minutes per step and saves days per cycle. The discipline is the gate-keeping: the two smoke tests are not optional, and neither is the "return the build to development" path when one fails.
Take it with you
Download the piece you just read.
The library is free. Tell us who you are so we can send you updated versions. One form; this browser remembers you after that.
In the library
Pair this with.
Process · The Master Framework
Four phases, applied in order, every project.
The top-level testing process used on every engagement. Four phases contain twelve sub-processes, each of which is documented in its own checklist in this library.
Read →Process · Test Execution
Run the tests, capture the data, adjust daily.
Test execution is where the risk register becomes results. These eight steps cover selection, assignment, the per-test inner loop, blocking-issue resolution, and the daily replanning that keeps a cycle on the rails.
Read →Process · Change Management
Triage every change. Integrate only the approved ones.
Undisciplined change is the largest single risk to test completion. This process defines the Change Control Board loop (from intake through final approval) so nothing slips into a release untested or unscored.
Read →
Keep reading
Related reading
- Primer
Careers in Software Quality: Roles, Skills, and First Steps
What testers, test automation engineers, quality engineers, and test managers actually do, the skills each role uses, and practical first steps for students and career changers, including the ISTQB Foundation certification.
Read → - Primer
Errors, Defects, and Failures: What a Bug Really Is
Everyone says 'bug', but testers use three precise words: error, defect, and failure. Learn the difference, why it matters, and how severity and priority decide which problems get fixed first.
Read → - Primer
How Software Gets Attacked: Common Vulnerabilities in Plain English
The most common ways attackers break into software, explained without jargon: trusting input, broken access control, weak sign-in, misconfiguration, and outdated components. Each one comes with the defense that stops it.
Read → - Primer
How to Report a Bug So It Actually Gets Fixed
Finding a bug is half the job. Learn how to write a bug report a developer can act on: a clear summary, exact steps to reproduce, expected versus actual results, and the habits professional testers use to make every report count.
Read → - Primer
Security Testing Basics: Finding Weaknesses Before Attackers Do
An introduction to security testing for new testers and developers: thinking in threats, designing abuse cases, testing access control, the role of automated scanners and penetration tests, and the rules that keep security testing legal and ethical.
Read → - Primer
Staying Safe Online: Passwords, Sign-In, Phishing, and Updates
The everyday security habits that stop most attacks: strong unique passwords, multi-factor sign-in, spotting phishing, keeping devices updated, and sharing carefully. Written for students, families, and anyone starting out.
Read →
Practices
Where this leads
- QA & testingSoftware testing
Software quality consulting since 1994: we test the releases that matter, coach your team on the method, and measure how its testing matures.
Book a call →