Testing Phase in SDLC: Types, Steps and an Example

The testing phase in SDLC is the fifth of the seven phases of the software development life cycle. It's where the team checks the software against the requirements before anyone depends on it.

Development hands it reviewed, merged code, and deployment shouldn't start without its sign-off.

The example all the way through is the invoicing tool from the SDLC overview, built for a plumbing firm whose office manager makes invoices from a Word template. It's made up.

What the testing phase is for

The testing phase exists to find the defects that matter before users do, and to give whoever owns the release enough evidence to say yes or no.

It can't prove the software is free of bugs. Edsger Dijkstra wrote in his Notes on Structured Programming that program testing "can be used to show the presence of bugs, but never to show their absence".

So the phase doesn't end when the bugs run out. It ends when someone with the authority decides the known risks are acceptable.

I think that's the part teams forget.

Inputs and the deliverable

The testing phase takes in the requirements, the design, the code and an environment to run it in, and hands deployment a tested build with a sign-off.

• Requirements - The user stories with their acceptance criteria, or a business requirements document if your team writes one. Every test should trace back to one of them.

• Design - The data model and the API contracts, which tell you what the integration tests have to check.

• Code - Reviewed, merged code from development, with the unit tests the engineers wrote alongside it.

• An environment - Somewhere that behaves like production, with test data shaped like the real thing.

What comes out is a test plan, results from an automated suite that passes, a defect list with a severity on every item, and a signed acceptance sheet.

The defect list matters as much as the passing suite. It tells deployment and maintenance what's known to be wrong and shipped anyway.

Who leads the testing phase

QA leads the testing phase, but nearly everyone on the project has a job in it.

• QA - Writes the test plan, owns the automated tests above unit level, does the exploratory testing and keeps the defect list.

• Engineers - Write unit tests with the code, fix defects and keep the suite fast enough that people actually run it.

• The PM - Decides what counts as a blocking defect, which known bugs can ship, and who does acceptance testing.

• The user - Runs acceptance testing and signs. If the real user can't, pick someone who does that job every day.

Winston Royce argued against leaving testing to the designers in 1970, in his paper Managing the Development of Large Software Systems. He wrote that many parts of the test process "are best handled by test specialists who did not necessarily contribute to the original design".

On a small team with no QA, the engineers own the automation and the PM owns acceptance. I'd still have each engineer test someone else's stories, not their own.

Types of testing in the testing phase

The main types of testing in the SDLC testing phase are unit, integration, end-to-end and user acceptance testing, with regression testing run across all of them after every change.

• Unit tests - Check one function or class on its own. They're fast, and most of your tests should be these.

• Integration tests - Check that parts work together and with outside services, such as email or a payment provider.

• End-to-end tests - Run a complete task through the real interface, the way a user would. They catch what the others miss, and they break more often.

• User acceptance testing - The people who'll use the software confirm it does their job.

• Regression testing - Re-runs the existing tests after a fix or a new feature, to catch what the change broke somewhere else.

For the mix, a 2015 post on Google's Testing Blog by Mike Wacker says Google often suggests "a 70/20/10 split" as a good first guess: 70% unit tests, 20% integration tests and 10% end-to-end tests.

Steps of the testing phase

The testing phase runs in seven steps, from a test plan to a signed acceptance sheet, with a loop between running the suite and fixing what it finds.

1. Write the test plan. Decide which level tests each acceptance criterion, and set the exit criteria: what has to be true before anyone signs.

2. Set up the environment and test data. Copy the shape of real data, never your real customers' details.

3. Write the test cases. Automate anything that will run more than twice, and keep a short list of exploratory checks for a person.

4. Run the suite. All of it, including the tests far from the change.

5. Log defects. Each one goes into a defect tracker like Jira with the steps to reproduce it, what should have happened and a severity.

6. Fix and re-run. Engineers fix in severity order, then the whole suite runs again, because a fix can break something else. Repeat until the suite passes and no blocking defect is open.

7. User acceptance testing and sign-off. The user works through real tasks, and the release owner signs against the exit criteria.

The diagram as text

• Write the test plan: which level tests each acceptance criterion, and the exit criteria.
• Set up the environment and test data, in the shape of real data, never your real customers' details.
• Write the test cases, automating anything that will run more than twice.
• Run the suite, all of it, including the tests far from the change.
• Log defects, each with steps to reproduce, what should have happened and a severity.
• Fix and re-run in severity order, then run the whole suite again; repeat until the suite passes and no blocking defect is open.
• User acceptance testing and sign-off: the user works through real tasks and the release owner signs.
• In waterfall the steps run once; agile runs steps 3 to 6 with every change.

Testing in agile versus waterfall

In waterfall the testing steps run once, after development ends. Agile runs steps 3 to 6 with every change, and I think that's the biggest difference between agile and waterfall for anyone who tests.

Royce saw the risk in the one-pass version. He wrote that the testing phase at the end of the cycle "is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed". Later in the paper he called the test phase "the phase of greatest risk in terms of dollars and schedule".

In agile a story isn't done until it passes its tests. The Scrum Guide says a backlog item that doesn't meet the Definition of Done "cannot be released or even presented at the Sprint Review". Put the test levels a story has to pass into your team's definition of done, so nobody argues about them at the review.

Microsoft's DevOps guidance calls moving tests earlier in the pipeline shifting left, and says it "ensures that most testing is completed before a change merges into the main branch".

Acceptance testing by the real users often still waits for a release, even in agile.

The invoicing tool at this phase

For the invoicing tool, deployment gets four things from QA: the test plan, a green run of the suite, the defect list and the acceptance sheet the office manager signed.

The test plan starts from the top story's acceptance criteria: the invoice carries the right tax rate, and it goes out by email as a PDF. Each criterion gets tests at more than one level.

• Unit tests - Cover the tax and totals logic: the tax rate, a discount, a job with nothing billable and rounding on every line.

• Integration tests - Send an invoice to a test inbox and take a payment in the payment provider's sandbox.

• End-to-end tests - Only a few. Each runs one job from completed to paid.

On the first full run, a job with a discount comes out a penny off, because the editor rounds each line and the PDF rounds the total. That's severity 1, since a wrong invoice is worse than no invoice.

The PDF also cuts off a long customer address. That's severity 3, so it goes on the list and ships.

Then comes acceptance testing. The office manager takes a week of real jobs, builds each invoice in the new tool and checks it against the one she made from the Word template.

Her check turns up something no test was written for. The invoice lists parts in the order they were added, and her customers expect labour first.

Fixing the ordering takes a day. She signs once that and the penny are sorted, and the address bug goes on the list that deployment and maintenance inherit.

Common mistakes in the testing phase

The testing phase mistakes I'd fix first are testing only the happy path and cutting the phase when development runs late.

• Only the happy path - The first tests anyone writes are the ones they expect to pass. Write the ones for a zero total and a missing address too.

• Too many end-to-end tests - Wacker's post calls a suite that relies mostly on end-to-end tests an inverted pyramid, or ice cream cone. Those tests are slow and fail for reasons that aren't bugs, and the post warns that flaky tests "are often ignored, even when they find real product issues".

• Cutting the phase to hold the date - If development runs late, I'd move the release before I'd cut testing.

• No agreed severities - Without a written definition of severity 1, the borderline defects turn into arguments about whether they block the release.

What AI changes in the testing phase

AI makes tests cheap to write, so the hard part moves to choosing what to test and reading what the model wrote.

GitHub Copilot's /tests slash command writes a suite of unit tests for the file you have open. Those tests "may not cover all scenarios", GitHub says. When Copilot writes invalid tests, its docs suggest giving it examples of inputs and outputs for the function.

Playwright's generator agent turns a Markdown test plan into test files, checking selectors and assertions live as it runs each scenario. Its docs say the generated tests "may include initial errors", for the healer agent to repair.

The risk I'd watch is where a test comes from. A model that writes tests by reading the code can end up with tests that agree with the code, bugs included.

Give it the acceptance criteria as well as the file, then check its tests against those criteria. A PM who reads code well enough to follow a pull request can do that check, and it's the one that catches the gap.

An AI feature inside the software can give a different answer to the same input, so you score it against a fixed eval set instead of checking for one exact output. I'd put an eval harness in from week one on any AI build.

Testing phase checklist

Before anyone signs off the testing phase, check these.

• Every acceptance criterion has at least one passing test.

• The full suite passed on the exact build you're about to release.

• No defect is open at a severity your exit criteria block on.

• Every known defect that ships is on the list, with an owner.

• The user, not the team, ran acceptance testing and signed.

• Skipped tests have been counted and read by a person.