Software Testing in the SDLC: How the Testing Phase Protects Your Launch

The new customer portal goes live at nine. By ten, support has taken forty calls: the payment page does not load on older iPhones.

Nobody tested it on one. Software testing exists to find problems like this before your customers do, and in a well-run project it starts long before launch week.

What is software testing in the SDLC?

Software testing is the work of checking that a system does what its requirements say, does it well enough, and has not broken anything that worked before. It covers everything from a developer's two-second check of one calculation to a group of accountants spending a week working through real invoices.

In the software development life cycle, testing has its own phase, between development and deployment. When people talk about the SDLC in software testing, they mean exactly this connection: the testing phase checks the system against what the earlier phases produced. The requirements say what "correct" means, the design says how the parts should fit, and the tests prove both.

This post is part of our series on the phases of the software development lifecycle. We have covered requirements analysis, which defines what the tests check against, and the design phase, which defines how the system is built; the series ends with maintenance, where good tests make every change after launch cheaper and safer.

Why software testing is worth what it costs

Software testing can feel like a cost that delays the launch. What does it actually save? More than most budgets assume.

The US National Institute of Standards and Technology estimated in 2002 that an inadequate infrastructure for software testing cost the US economy up to $59.5 billion a year, and that feasible improvements could save about $22.2 billion of it (NIST). The figures are old, but the pattern has only grown with the amount of software around us. Twenty years later, the Consortium for Information and Software Quality put the cost of poor software quality in the US at at least $2.41 trillion in 2022 (CISQ).

At the scale of one project, the arithmetic is simple. A defect found by a developer's automated test costs minutes. The same defect found by a customer costs a support call, an emergency fix, a release outside the plan and some of the customer's trust.

Testing in a modern project: a phase and a habit

Older projects did their software testing at the end. The team built everything first, handed it to testers, and waited for the list of bugs. The problem with that model is timing: the bugs arrive when there is the least time left to fix them.

Modern software development does both. Software testing happens continuously during development, with automated tests running on every change, and there is still a testing phase before release, where the whole system is checked end to end and the business users accept it.

That is why, in our projects, the testing phase is one of the calmest parts of the software development life cycle. In our guide to custom software development, testing runs from the first increment of the build, and the final acceptance testing takes two to four weeks of a roughly six-month first release. Most defects have been found and fixed long before that.

The software testing process, step by step

Whether the testing phase takes days or months, the software testing process follows the same six steps.

1. Plan the testing

A test plan sets out how the software testing will run. It answers a few practical questions: what will be tested and what will not, how (which kinds of tests, such as functional testing and performance testing, and which testing tools), where (which environments and devices), who does what, and, the most important, what counts as "done". These exit criteria stop the endless debate about whether the system is ready: for example, no open critical defects and all key business scenarios passing.

2. Design the test cases

Test cases come from the requirements. Each requirement becomes one or more concrete checks: "when an accountant approves an invoice that matches its purchase order, the invoice moves to the payment queue". Good test cases also cover what should not happen: an invoice without a purchase order, a negative amount, a user without permission.

This is where testable requirements pay off. A requirement like "the system should be fast" cannot become a test case. "Search results within one second for 95% of searches" can.

3. Prepare the test environment and data

Tests need somewhere to run that behaves like production, and data that looks like real data: realistic volumes, odd characters in names, customers with twenty addresses. Many defects only show up with real-world data, so this step deserves more care than it usually gets. Personal data from production should be anonymized before it is used for testing.

4. Run the tests

The tests are run, by people and by machines. Automated tests run on every change throughout the software development process; manual testing focuses on what machines do poorly, such as exploring the system the way a curious user would.

5. Report, fix and retest

Every defect is recorded with the steps to reproduce it and a severity: does it block the business, or is it a typo? Developers fix them in priority order, testers check each fix, and the automated regression tests confirm that the fix did not break something else.

6. User acceptance testing and sign-off

Finally, the people who will use the system every day try it on their real work. User acceptance testing (UAT) is the business's chance to say "yes, this does what we need" before launch, and the last chance to catch a misunderstood requirement cheaply. Plan for it early: the accountants who need to test the invoice module also have month-end to close.

The main types of software testing, in plain language

There are dozens of named kinds of testing, and our post on the types of software testing walks through 22 of them. For a business reader, three questions are enough to make sense of most of them: does the system do the right thing, does it do it well enough, and does it work for the business?

A useful picture is the test pyramid. In the words of an article on Martin Fowler's site, the pyramid "is a metaphor that tells us to group software tests into buckets of different granularity", and it gives an idea of how many tests each group should have (martinfowler.com).

Functional testing: does it do the right thing?

Functional testing checks the system against its functional requirements: when I do this, does that happen? It is the largest group, and it works at every level of the pyramid.

• Unit tests check one small piece, such as one calculation, in isolation. Developers write them alongside the code, and a system can have thousands.
• Integration testing checks that parts work together: the application and its database, the invoice module and the payment provider. Many expensive bugs live at these joins, where two teams made different assumptions.
• System or end-to-end tests walk through whole business scenarios, from login to a paid invoice, the way a user would.
• Regression tests re-run existing checks after every change, to make sure what worked yesterday still works today.

Functional testing answers the question every client asks first: does it work? Integration testing deserves special attention in any system that talks to other systems, which today is almost every business system.

Non-functional testing: does it do it well enough?

A system can do every task correctly and still fail its users. Non-functional testing checks the qualities around the features:

• Performance testing checks speed and capacity: how fast the system answers with 500 people using it at once, and where it breaks.
• Security testing looks for the weaknesses an attacker would use, from outdated libraries to gaps in access control.
• Compatibility testing checks that the system works on the browsers, phones, operating systems and screen sizes your users actually have, like the older iPhones in the opening story.
• Usability and accessibility testing check that people, including people with disabilities, can use the system without help.

Non-functional testing is the part most often squeezed when deadlines get tight. That is a risky trade: performance testing and compatibility testing are much cheaper before launch than after it, when real users find the limits for you.

User acceptance testing: does it work for the business?

User acceptance testing sits at the top of the pyramid. It is the only kind of testing where the people who asked for the system decide whether they got it. It is mostly manual, it uses real scenarios, and it ends with a decision: accept, or go back and fix.

Manual testing vs automated testing

Should software testing be done by people or by machines? Both, for different jobs.

Automated testing pays off for anything that has to be checked again and again: the regression tests that run after every change, unit and integration tests, performance tests. Once written, a machine runs them in minutes, at any hour, identically every time. That is what lets a team ship changes weekly without fear.

Manual testing remains the better tool for judgment: does this screen make sense, is this report readable, what happens if I do something nobody expected? Exploratory testing by an experienced tester finds problems no script was written to look for.

A practical rule: automate what you will run often, and keep manual testing for what needs human judgment. Automating everything is as costly a mistake as automating nothing.

Software testing tools

You do not need to know these tools to commission software, but you will hear their names in progress meetings. These are some of the common testing tools in 2026:

The choice of testing tools matters less than the habit of using them. A modest automated testing suite that runs on every change beats an impressive toolset nobody maintains.

Who does the testing, and how long it takes

Software testing is a shared job:

• Developers write unit tests and do integration testing for their own code. In a healthy software development process, a change without tests is not finished.
• A QA engineer (quality assurance) plans the testing, designs test cases, builds automated end-to-end tests and does exploratory manual testing. A typical team for a first release in our projects includes one.
• Business users do the user acceptance testing, with a product owner deciding when the result is good enough to launch.
• Specialists come in for specific checks, such as penetration testers for security.

As for time: automated testing runs from the first weeks of development, so there is no single "testing month". The final acceptance testing typically takes two to four weeks for a first release of moderate scope. Plan who will do it, and give them the time: acceptance testing squeezed between other duties tends to find problems after launch instead of before.

Common software testing mistakes

Most testing problems come from a handful of habits that are easy to fall into at any point in the software development lifecycle.

• Testing only at the end. Bugs found in the last week are the most expensive to fix and the most likely to delay the launch.
• Testing only the happy path. Real users mistype, double-click, lose their connection and paste strange data.
• Unrealistic test data. Ten neat test customers will not reveal what a database of a million messy ones does.
• No performance testing before launch. The first real load test then happens on launch day, with real customers.
• Forgetting compatibility. The development team uses new laptops and fast connections; your customers may not.
• Skipping user acceptance testing because the business users are busy. Their requirements were misunderstood somewhere; UAT is where you find out.
• Trusting tests nobody checked. AI coding assistants can now write tests in seconds, and a test that always passes proves nothing. Our guide to the types of software testing has six rules for testing AI-generated code.

How we test at Stratoflow

On our projects, testing runs through the whole software development lifecycle. You see working software every week, and every week it is tested before you see it: automated tests on every change, run with standard open-source testing tools, in your repository from day one. Tests and documentation are part of the agreed scope, so they stay with you when the engagement ends.

When the system already exists, we build the safety net first. For an independent London wine merchant, before touching a single framework, we added regression tests around what the business relies on: invoices and documents, spreadsheet imports, product search, orders and billing, and browser tests that walk through real customer journeys. During the upgrade those tests caught two breaks before release, one that would have stopped all PDF generation and one that would have broken spreadsheet imports. All 79 tests passed on the new platform, and the client kept releasing features throughout (case study).

Testing also comes before speed. For a global flight information company, our functional tests first proved that a new calculation engine produced exactly the same daily output as the production system. Only then did we compare performance on identical input data: 65% less calculation time (case study).

Software testing is the last phase of the software development life cycle before your users meet the system, and it decides how calm the rest of its life will be. The series continues after launch with software maintenance, and starts from the beginning with requirements analysis and the design phase. If you are planning a system, or worried about one already live, book a thirty-minute scoping call: you get a written view of scope and price model within a week, and an honest answer if we are not the right team for it.