When a software schedule slips, cut scope before you cut test time. Testing is the last stage before release, so it absorbs the delay that earlier stages create. In this author's judgment, a team that cuts it ships the same defects it would have found, only later and in front of users.
This article explains why testing gets squeezed, how to start it earlier and what to do when the date will not move.
Why does testing get squeezed?
Testing gets squeezed because earlier stages run late and the release date stays fixed. In the seven-stage view of the software development lifecycle (SDLC), testing comes fifth, after planning, requirements analysis, design and development. Any delay upstream arrives at testing with no extra time attached.
In this author's judgment, the squeeze is a planning problem more than a testing problem. The date was set before anyone knew how long the earlier stages would take. Testing is simply where the arithmetic fails.
What does the testing stage produce?
The testing stage checks the software against the requirements and fixes defects. Its typical output is test results and a release decision. That output list is a summary of common practice, not a standard.
The release decision is the part that matters. It is the point where someone says yes or no to shipping. If test time is cut, the decision still gets made, but with less evidence behind it. In this author's judgment, a team that skips the evidence has not removed the decision. It has made the decision blind.
How do you start testing before the testing stage?
Start test planning in requirements analysis, because a requirement that cannot be checked is not finished. That is this author's judgment, and it moves much of the work out of the crunch at the end.
Here is an illustrative pair that does not describe a real project. The requirement "the
report should load quickly" cannot be checked, because two people will disagree on
"quickly". The requirement "the report loads within a limit the team and stakeholders
agree on, under a load they also agree on" can be checked, once the numbers are filled in. The second version tells the tester what to build a test around before any code exists. The same habit helps in the other direction. If a requirement is hard to turn into a check, the requirement is probably vague, and it is cheaper to fix it in analysis than in testing.
Why test during development?
Test during development so that defects surface while the code is still fresh and the stage is still open. The seven-stage view lists testing as its own stage, but nothing stops a team from checking work as it is built. That is the fix this author recommends for a squeezed Off-page support round 10: Software development lifecycle testing stage.
An Agile team already works this way. Agile runs all seven stages inside each short cycle, and each cycle produces releasable software. Testing is part of every cycle, so it cannot be pushed to the end of the project. The V-Model takes a different route to a similar result. It pairs a matching test stage with every design step, which suits certification-
heavy or safety-critical work.
What should you cu instead of test time?
Cut scope. When the date is fixed and the work is late, the honest options are to ship fewer features or to ship less tested software. In this author's judgment, the first option is almost always safer, because a missing feature is visible to everyone and an untested feature is a risk nobody can see.
Cutting scope is easier when the product can launch in useful parts. The Incremental model builds and ships finished modules one at a time, and it fits products that can launch that way. A team using it can drop the last module and still release something complete.
Two questions help decide what to cut:
Which feature can wait for a later release without making this release useless?
Which feature has the weakest test coverage today?
If the answer to the second question is a feature the product depends on, that is a reason to hold the release, not a reason to ship it.
How do you make the cut stick?
Make the "cut scope before test time" rule visible before the pressure starts. Write down,
at the start of the project, that scope is cut before test time. Name the person who owns
the release decision. In this author's judgment, a rule agreed in calm weather is much
easier to hold than one invented during a crisis.
Handoffs help too. Handoffs fail when stage outputs are vague, because the next team guesses. Defining each stage's output and sign-off in writing gives testing something solid to start from. Under deadline pressure, documentation is the first thing cut, so making the
update of the stage output part of the definition of done protects it. Off-page support round 10: Software development lifecycle
What does a release need besides test results?
A release needs a plan for going back. The deployment stage typically produces a live release and a rollback plan. If testing was thin, the rollback plan matters more, because the team will find problems in production. A plan that nobody has read is not a plan, so the team should check it before release day.
After release, the maintenance stage fixes defects and keeps the software supported and up to date. In this author's judgment, defects that testing missed become maintenance work, so the time was not saved. It moved to a stage where fixing a defect disturbs real users.
Where can you see the other common SDLC challenges?
Testing is one of several predictable pressure points. The TekRevol guide to the SDLC covers six common challenges, including late security, failed handoffs and documentation that falls behind. You can read it in a table that pairs six common SDLC challenges with a fix. The table is TekRevol's judgment, except where it names a source, and the guide says so. Use it as a checklist for your own project. Not every row will apply.
The takeaway
Squeezed testing is a symptom of a date set too early. Start test planning in requirements analysis, test during development and agree in advance that scope goes before test time. Then the release decision rests on evidence.
