DEV Community: Burrak Leo

When The Schedule Slips, Cut Scope Before You Cut Test Time

Burrak Leo — Mon, 02 Nov 2026 10:54:56 +0000

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.

How to write an architecture decision record your team will actually read

Burrak Leo — Tue, 27 Oct 2026 09:38:17 +0000

An architecture decision record (ADR) is a short log entry for one significant design decision, and it works only if it is brief, specific and easy to find. Teams that skip ADRs tend to repeat old debates. Teams that write them badly end up with a folder nobody opens.

This article covers which decisions deserve a record, what to put in one, and how to keep the records useful as the system changes.

What is an architecture decision record?

An ADR is a log of a workload's key decisions that shows how and why the system took its shape. That is how Microsoft's Azure Well-Architected guidance, updated April 13, 2026, describes it. The record captures the reasoning behind a choice, not only the choice.

The reasoning is the part that disappears. Microsoft's guidance says undocumented decisions tend to be forgotten, which leads to repeated debates. A new engineer sees a design that looks odd, proposes the obvious fix, and the team spends time rediscovering why it was built that way.

Which decisions deserve a record?

Write an ADR only for architecturally significant decisions, meaning choices that are costly to reverse. Martin Fowler's guide says an architect's key task is to reduce irreversibility, and it adds that what counts as architectural depends on what the developers consider important.

In this author's judgment, these usually qualify:

Choosing an architectural style, such as a modular monolith or microservices.
Choosing a data store or a way to share data between components.

Choosing synchronous calls or asynchronous messaging between parts of the system. Setting a boundary that a team will have to respect for years.

Naming a variable does not qualify. If reversing the decision takes an afternoon, skip the record. If reversing it takes a quarter, write one.

What goes in an ADR?

A useful ADR holds the problem and its context, the options considered, the decision with its trade-offs, and a status such as Proposed or Accepted. Keep each part to a few sentences.

How do fitness functions fit with ADRs?

A fitness function checks that the system still follows the decision the record describes. Wikipedia says architects should use fitness functions, which are tests of a quality goal such as response time, to keep the architecture in check as the system changes.

This pairing matters because of architecture erosion. Perry and Wolf described the problem in 1992, according to Wikipedia: the implemented system drifts from the intended architecture. A record states the intent. A fitness function tests it. Without the test, the record becomes a statement about a design that no longer exists.

For example, if a record says the checkout service must not call the email provider directly, a test can fail the build when someone adds that call. This example is illustrative.

Where do ADRs sit among other architecture documents?

ADRs record decisions, and other documents show structure. No single diagram serves every reader, which is this author's judgment. Wikipedia notes that Philippe Kruchten's 4+1 view model, published in 1995, separates concerns across views, and that the C4 model helps teams model "just enough." The international standard for architecture description is ISO/IEC/IEEE 42010.

Use views to show what the system looks like and ADRs to explain why. TekRevol's software architecture guide includes a worked decision record for keeping order management in one deployable application next to a comparison of six architectural styles, which shows how a record can sit beside a style choice.

The takeaway

Write ADRs for decisions that are costly to reverse. Keep each one short, name the options and the consequences, append instead of rewriting, and test the intent with fitness functions. A good record answers the question a future engineer will ask: why did we build it this way?