What Are the Stages of Software Testing?

Type “what are the stages of software testing” into a search box and you’ll get two different answers. One site lists four levels, from unit up to acceptance. Another gives a five- to seven-step process, running from planning through to closure. Both are correct, but they disagree because they answer different questions.

However, if you ask a tester on your own team, you’ll get a third answer that’s entirely unrelated, but also correct. That third answer never shows up in search results, which is why it surprises people. It has nothing to do with the product as a whole, and everything to do with a single bug. Each one moves through a short series of states. Someone confirms it’s real, a developer fixes it, and a tester verifies the result. That series is what people mean when they say a bug has moved to the next stage.

This guide separates the three, so you can tell them apart and work out which one you need. Most companies are staffed for one or two, which is why the third tends to slip. A dedicated QA team covers all of them.

What Are the Stages of Software Testing? Three Things People Mean

The confusion is genuine, because one phrase covers three separate ideas and a source that explains one of them rarely mentions the rest.

Look at the middle column, where levels are about scope, the life cycle is about process, and the bug life cycle tracks one defect from report to closed. On any given afternoon, your team can be at the system level, midway through the life cycle, and holding forty defects in four different states. None of those facts contradicts the others.

The number of stages depends on who you ask, and anybody promising one right answer is simplifying. The variation is not random:

• Levels are settled at four. Nobody seriously argues for a different count.
• The life cycle is not settled. Some writers split planning from analysis and others combine them, which is where five, six and seven all come from.
• Bug states follow convention, not a standard. Seven of them are near-universal, and your tracker decides whether there are more.

The Four Testing Levels and What Each One Catches

Levels answer the scope question: how much of the product you test at once. They run from the smallest piece up to the finished thing with a real person using it.

• Unit testing: One function, method or class, checked on its own with everything around it faked. Developers write these alongside the code, and they run in seconds.
• Integration testing: Two or more pieces checked together, which tells you whether they agree about the data passing between them. This is where a working login and a working profile page turn out to disagree about what a user ID looks like.
• System testing: The whole assembled product, checked end to end against what it was meant to do. Independent testers run it, because by now you want somebody who didn’t build it.
• Acceptance testing: The people who asked for the product decide whether they got it. This is the last gate before release, and it answers a question no earlier level asks. Alpha and beta testing both sit here, along with formal sign-off.

Read that last column downward and you have the argument for running all four. Each level is blind to something the next one catches, and the price of a fix climbs at every step. A naming mistake caught by a unit test costs a developer two minutes. The same mistake found during acceptance costs a release.

None of that changes on mobile. The four levels apply there too, and knowing which app testing stage you’re in tells you who should run the checks and how expensive a miss becomes.

Example: Password Reset Through Four Testing Levels

Let’s take a password reset for instance, since nearly every product has one and everybody has used it in real life.

Unit testing looks at the small pieces separately. Does the token generator produce something nobody can guess? Does the expiry calculation return the right timestamp? A developer writes these while building the feature, and they finish in milliseconds.

Integration testing asks whether those pieces agree with each other. The request has to reach the email service, the token has to survive the round trip, and the database has to record that a reset is pending. Most password reset bugs live at those handoffs, because every piece works perfectly well alone.

System testing follows the whole journey the way a person would. Request a reset, open the mail, click the link, choose a new password, sign in. A tester also walks the paths nobody designed for: clicking the link twice, letting it expire, asking for three resets in a row.

Acceptance testing asks something else entirely. Does this match what the business agreed? If your security team said reset links expire after one hour and the build ships with 24, all three earlier levels pass and the feature is still wrong.

Acceptance is the only level that catches it, which is why all four earn their place. Three can come back green while the product still fails the one test that reflects what somebody actually asked for.

Why Regression, Performance and Security Are Types, Not Stages

Here’s the distinction that saves the most confusion once you have it. A stage is something you move through in order, while a type is work you can do at more than one of them. The following are testing types:

• Regression testing isn’t tied to a level at all, since its job is confirming that what worked last week still works today. Run it across anything a change could reach, not only the part that changed.
• Performance testing can target a single service on its own or the whole system under real load. Put it wherever a slow response would genuinely cost you something.
• Security testing can examine one endpoint’s permissions or the finished product the way an attacker would. Treat it as continuous, because a single access change can open a gap no functional test notices.

So when somebody asks which stage performance testing belongs to, the honest answer is that the question doesn’t quite work. It belongs to whichever level you’re worried about. That’s why a useful test plan names both the level and the type.

Software Testing Life Cycle: Brief Overview

The other common answer to what are the stages of software testing is a process, not a set of levels. That process is the software testing life cycle, usually shortened to STLC. It describes how a test effort is organized rather than what gets tested: reviewing the requirements, planning, building test cases, preparing an environment, running the tests, then closing out with a report.

That sequence deserves more room than this article can give it, and we have a dedicated walkthrough. Our software testing life cycle guide covers each phase along with its entry and exit criteria.

One clarification belongs here, because it causes real arguments. That first phase depends on having requirements a tester can work from, which is a separate problem with its own answer in our guide to software testing requirements. The life cycle tells you when requirements get reviewed. It doesn’t tell you what a good one looks like.

The Bug Life Cycle: From New to Closed in Seven States

Testing finds bugs, whichever level or type it happens at, and each of them then follows a sequence of its own. This is the third thing called stages, and it’s the one your developers most likely mean.

1. New from the reporter: the bug is logged, and nobody has agreed yet that it’s real.
2. Assigned to an owner: triage has accepted it and handed it to a named person.
3. In progress with a developer: someone is working on the fix.
4. Fixed in the developer’s view: a claim rather than a conclusion.
5. Retest by a tester: somebody checks that claim against the original reproduction steps.
6. Verified by the retest: the problem is genuinely gone.
7. Closed and recorded: the work is finished.

Two more states sit outside those seven. Reopened means a verified fix broke again, which usually points to a missing regression test rather than a careless developer. Deferred means the team agreed the bug is real and chose not to fix it yet, which is a legitimate call as long as somebody wrote down why.

Where a bug was found makes no difference to the states it passes through. One caught by a unit test and one caught in acceptance follow the same seven. What changes is how much each step costs by the time you get there.

How QAwerk Runs These Stages in Practice

We don’t treat testing as a single phase near the end. Our engineers join at whatever point a project has reached and work inside the sprint, so the four levels run continuously instead of stacking up before a release. For the week-to-week detail, see our guide to agile testing.

In practice, that means we pick a product up wherever it stands. Some teams bring us in before a line of code exists, while the requirements are still being argued over. Others hand us a finished build and a launch date. Both work, though the first costs less, for the same reason a unit test is cheaper than an acceptance failure.

Quality depends on who does it. We have 30+ senior QA engineers averaging 9 years of experience each, and we’ve identified more than 50,000 critical bugs across 300+ projects since 2015. That experience matters most at the exact points where levels go blind: knowing which integration is likely to disagree, and which acceptance scenario nobody thought to write down.

To find out where your product actually sits against the four levels, talk to our QA team. We’ll map your current coverage before you commit to anything.

FAQ

What are the stages of software testing?

Three different things, and which one somebody means usually depends on their job. Developers mean the four testing levels: unit, integration, system and acceptance. QA leads mean the testing life cycle, the process a test effort runs through from planning to sign-off. Anyone reporting a defect means the bug life cycle, which tracks one issue rather than the work.

How many stages of software testing are there?

Four, five to seven, or seven, depending on which sense you mean. There are four testing levels and that count is stable across sources. The life cycle is drawn with anywhere between five and seven steps. A bug moves through seven common states plus whatever else your tracker defines. No single figure answers the question.

What is the difference between testing levels and the STLC?

Scope against process, and the split shows up in who owns each. Levels describe how much of the product a given check covers, so they belong to whoever writes that check. The STLC describes how the whole effort gets planned, staffed and signed off, so it belongs to the QA lead. Neither one constrains the other.

What is the bug life cycle?

The set of states one defect passes through between being reported and being closed, running from new through assigned, in progress, fixed, retest and verified. Watching where bugs pile up tells you where your process is stuck. A queue sitting in retest points at QA capacity, while a queue sitting in assigned points at triage.

At what stage should testing start?

Testing should start before any code exists, at the point where somebody reviews the requirements and asks what happens when things go wrong. Unit testing then begins during development rather than after it. Waiting for a finished build means the cheapest bugs to fix have already had more code built on top of them.