How Many Test Phases Are There? A Comprehensive Explanation for Tech Leads

At first sight, it may seem that the Software Testing Life Cycle includes just five phases: Sleep > Eat > Test > Rest > Repeat 😉 But the testing process is full of tech nuances, and there are a lot of details Tech Leads may need to figure out.

For instance, one of the first things that cause confusion is that people who speak about test phases often mean different things. To be more specific:

• Some refer to test phases as levels of testing and refer them to the readiness of a software product.
• The others mean software testing life cycle (STLC) and its place in a software development life cycle (SDLC).
• Some just want to know the details about a software testing company’s processes when looking for a QA outsourcing partner.

After reading this article, you’ll (hopefully) have a clear understanding of STLC phases, their particularities, a testing phase in SDLC, and some other insights to organize effective development processes in a team.

Levels of Testing and Stages of Product Readiness

At different stages of testing, organizations involve different team members to help businesses achieve their quality goals in a strategic, documented manner. So, let’s start sorting out things with levels of testing.

There are four testing levels. Each of them determines whether tests are carried out on an individual module, a group of modules, or the system as a whole.

Unit Testing

It’s the first level of testing, and it is run by developers. They check individual components or units of software to determine whether each is fully functional. Here, a unit can refer to a specific individual program, function, or procedure. Commonly, the software developers perform it before delivering software to testers for formal testing. One of the biggest benefits of unit testing is the ability to run it every time a piece of code is changed, allowing errors to be detected and fixed as quickly as possible.

Integration Testing

No matter how efficiently modules work in isolation, if they aren’t properly integrated, it will affect the functionality of the software. To solve this problem, integration testing enters the room. After developers combine all of the units within a program, QA engineers can test them as a group, exposing faults (if any 😉) in the integration between the modules.

There are four approaches to integration testing:

• big-bang testing (convenient for small systems, when all the modules are simply put together and tested);
• bottom-up testing (each module at lower levels is tested with higher modules until all modules are tested);
• top-down testing (firstly, high-level modules are tested, then low-level ones);
• hybrid testing (a combination of top-down and bottom-up testing approaches).

System Testing

At this level, testing is performed on a complete integrated system. The task is to evaluate the system’s compliance with technical, functional, and business requirements and make sure it meets quality standards. Basically, system testing is the first attempt of checking an application as a whole.

Acceptance Testing

The final level of testing is conducted to determine whether the system is ready for release. Its key goal is to ensure that all the requirements are fulfilled, and users are going to get the functionality the company planned to provide. Once this stage is completed and the software passes, the program goes to production.

Software Testing Phases and Product Readiness

There are four levels of testing, but more testing activities that depend on the readiness of software. For example, some tests are meant for earlier stages, and some are for later. Static testing and product verification are two examples of such checks.

Static Testing

Static testing is one of those activities that help prevent defects early, but many teams don’t perform it. A QA team can start static testing before a single line of code is written. As you might have guessed, it focuses on documentation. What to review at this stage?

• specification requirements;
• mockups and other design documents;
• prototypes and specifications;
• test plan and/or strategy;
• use cases, test cases, checklists;
• automated test scripts;
• and more.

It can be a formal review, a technical inspection, or a walkthrough. In any case, static testing is very effective in detecting gaps in logic, design defects, usability issues, and deviation from standards. The result is fewer defects during dynamic testing (which is a direct interaction with a system) and higher development productivity.

Product Verification

Verification is the process of estimating a software system or its components to find out whether the results at the specified stage meet the requirements and conditions communicated at the beginning of this stage. In other words, a QA team aims to find out whether the set goals and deadlines are met.

Verification is usually associated with the fourth level of testing – acceptance testing. A QA team is to make sure that a build is working as intended and is ready for release. Verification is a quick check that takes place after every release or patch – when a new software build is delivered to an end-user.

STLC Phases in Different Development Models

Software testing life cycle (STLC) is a sequence of tasks and activities performed by a QA team during software development. Traditionally, software testing occurs shortly before product release to ensure it is bug-free. However, as digital systems evolve, a lot of organizations choose not to wait until a product is fully developed to test it.

In general, there are five phases of testing in every development pipeline:

1. Software analysis.
2. Test planning.
3. Documentation writing.
4. Test execution.
5. Reporting.

However, this plan can be altered a little depending on what methodology a company uses – a traditional or agile one.

Test Phases in Traditional SDLC Models

A traditional model implies linear and sequential development activities. For example, in a Waterfall model, the process moves in a systematic downward manner from one phase to the next. The output of one step is used as the input for the next one. Thus, it’s mandatory to complete each phase before beginning a new one. The phases of the testing life cycle must not overlap.

Phase 1. Requirement Analysis

A QA team figures out the testable requirements (the desired way a product would be functioning) and ensures that they work for the project.

Requirement analysis may include the following activities:

• defining software features;
• setting testing priorities;
• preparing requirement traceability matrix;
• identifying the testing environment details.

During this phase, a QA team may interact with various stakeholders – system and business analysts, tech leads, etc. to discuss functional and non-functional requirements.

Phase 2. Test Planning

A QA team defines the release schedule, discusses a general project strategy, calculates the expenses, and analyzes the risks involved. After that, a QA manager finalizes the tools and platforms and assigns roles and responsibilities. It all is summarized in a Test Plan.

Phase 3. Test Case Development

At this phase, a QA team prepares and reviews test cases and arranges test data. In particular, the specialists outline different test conditions with input data and expected outcomes.

Phase 4. Environment Setup

Then come the verification and validation of specified requirements in the documentation stage. It is necessary to set up software and hardware configuration to deploy a build for testing. A client’s team can provide an environment, or QA engineers can configure one.

Phase 5. Text Execution

At this stage, software testers run checks and report bugs. If there are serious defects, a build goes back to a development team. After fixing bugs, QA engineers run retests and regression testing.

Phase 6. Test Cycle Closure

It is the last stage of the STLC. A QA team focuses on measuring results, analyzing the test effort outcomes, evaluating test coverage, quality, costs, time, and preparing the final report. It is essential to get a total grasp on the work completed.

Test Phases in Agile SDLC Models

Agile methodologies focus on a team-based approach, promoting software development as a continuous process with changes and updates delivered in portions. Instead of presenting a product in its final version, a team releases it and keeps working on improvements as the product is live.

A product team works in sprints that last two to four weeks. During this time, developers are to add a piece of new code, and QA engineers are to test it. The process goes on and on with a new software build released to production at the end of each stage.

So what are the test phases in agile? During a sprint, software testers:

• prepare and run tests for new functionality;
• retest the functionality with recent bug fixes;
• and run regression tests for the business-critical features.

QA specialists also participate in daily scrums, review meetings, and impact assessments – the procedures that are at the core of agile development.

Test Phases in Documentation

In the documentation, a test phase is a specific clause that describes the testing activities at the particular stage of the testing process.

For example, if a project consists of several parts – website, wearable item, web app, and mobile app – an app’s testing phase can be a separate stage in the QA process that includes several sub-phases.

If a mobile application is all you need to test, the phases can refer to different types of testing. For example, we can run API tests before a user interface is ready, so it can be the first phase. Later on, we run UI testing, it will be the second phase. Finally, we run acceptance tests. Since it means running a final check for an almost-ready-to-hand-over-to-a-user product, it will come at the end of the testing cycle – it’ll be the third phase.

Software Testing Phases at QA Madness

Last but not least, we shouldn’t forget that in practice, the process of testing is individual for every project. And thus, the actual phases of testing and their order may vary.

The QA Madness team always aligns with a client’s processes and deadlines to make sure that testing and other QA procedures fit in perfectly and are as efficient as they could be.

Below, you can see a brief explanation of how manual and automated testing usually go when the QA Madness’s specialists cover them. Keep in mind that these are outlines of the processes. The details vary based on a chosen type of cooperation, the types of testing a client requests, product complexity, etc.

Manual Testing

• Software analysis & defining the test scope. We request requirements and/or designs, study them, and ask questions to understand everything about the product. After summarizing this information, we prepare an estimation of the work scope, the time required to complete the testing, and the approximate cost.
• Test planning. QA engineers start working on the strategy, set up a test environment, and prepare test entities.
• Testing documentation. The team writes and finalizes a test plan/strategy, checklists, or test cases, and gets ready to run tests.
• Test execution. Well, this one is the easiest to guess: we run tests.
• Reporting and deliverables. A client receives bug reports or other agreed documentation that wraps up the results of the completed testing activities.

Automated Testing

• Preparation stage – project analysis, selection of an AT strategy and tools, preparation of test artifacts, and approval of communication channels.
• Active stage – test framework creation and scriptwriting, a configuration of test runs, setting up reporting, and test execution.
• Support stage – preparation of “How to” instructions, report review and test result verification, and test maintenance.

To Sum Up

The fast-paced and dynamic product development, which is essential to keep up with the market demands, encourages companies to look for ways to improve their processes. Cooperation with an experienced QA provider will help you carefully plan the testing activities and improve the quality of software delivered to end-users.

Now, you have a good understanding of how the software testing process goes and what phases it may entail. The next step is integrating these phases in the existing development pipeline or improving the existing QA processes.