Practical Software Testing QA Process Flow (Requirements to Release)

A Complete Overview of End-to-End QA Software Testing Process Flow:

Note – We are re-publishing this useful post with updated content.

The job of a software testing professional is not an easy one. It is filled with challenges, which is equally demanding as well.  Testers are supposed to be alert and enthusiastic in each and every phases of the application lifecycle.

Though there are challenges, there are several tremendous opportunities as well to learn and explore the various aspects of testing methodologies, processes and of course the software in detail.

The role of a test engineer begins very early. And right from the conceptualization of the project, testers are involved in discussions with the product owner, project manager and various stakeholders.

This tutorial on “Software Testing Process flow” gives you a complete overview of the various phases in STLC along with the challenges involved and the best practices to overcome those challenges in an easily understandable manner.

What You Will Learn:

Requirement to Release – A Complete Overview

Right from Requirement to Release, each phase is explained clearly. Let’s take a look at them in detail.

#1) Requirement

A project cannot take off without having a clear requirement. This is the most crucial phase where ideas need to get written in a well understandable and formatted document. If you are a part of the project where you are participating in the requirement gathering phase, then consider yourself lucky.

Wondering Why? It is because you are witnessing a project in making from the scratch. Though there is pride in being since inception, it comes with some responsibilities and challenges too.


One cannot imagine all the requirements to gather in a single sitting. Be patient enough.

A lot of discussions will happen, some of which may be simply irrelevant to your project but even then they may contain some vital information for your project. Sometimes the speed of discussions may exceed your grasping capabilities or you would simply not pay attention to the product owner.

The below picture highlights the crucial steps involved in requirement gathering:

Every piece of information that is missed has a huge impact on the overall understanding and testing of the project. To overcome this, here are some best practices which should be followed during this phase.

Best Practices

Though there is no separate wall as such for each and every phase, requirements do change even very late in developments. So, the idea is to grab the most of the requirement and document this properly.

Once it is been documented with all the necessary points, distribute and discuss this all the stakeholders so that any suggestions or changes are caught early and before moving on, everyone is on the same page.

#2) Test Strategy

Testers are supposed to come out with a test strategy which is not just sufficient to test the software better, but should also instill confidence in every stakeholder regarding the quality of the product.


The most crucial aspect of this phase is to create a strategy which when worked upon should deliver a software product that is error free, sustainable and accepted by its end users.

Test strategies are something you will not change every other day.  In some cases, you need to discuss your test strategies with the customers also. So this part should be dealt with high importance.

Best practices

Here the idea behind is to keep every necessary and required platform, devices, and software’s that our application will need to function before us so that a comprehensive strategy can be formulated.

Below figure will help you to understand the outline of test strategy if you are working on an agile project:

#3) Test Planning

After the testers are armed with all the information regarding AUT, the planning phase is where the Strategy is implemented.

Like test strategy, test planning is also a crucial phase.


Since the success (or failure) of the AUT depends largely on how the tests were carried out, this phase becomes an important aspect of the entire test life cycle. Why? Because a part of testing is defined in this phase.

In order to overcome some challenges, these best practices can really be helpful.

Best practices

#4) Testing

Finally, your application build is out and you are ready to find bugs! Now it’s’ time to work on test planning and find as many bugs as possible. There will be some phases in between if you work in an agile environment, then simply follow those scrum methods.

Below diagram depicts the categorization of various testing types:


Testing is a cumbersome process which itself is error prone! One finds many challenges while testing an application. Given below are some best practices to rescue.

Best Practices

Cheer up! You are trying to find defects in the code. You need to pay attention to the overall working of the software.

#5) Before Release

Before we release any product to the market, the quality of the product has to be ensured. Software’s are developed once but they are actually been tested until they are replaced or removed.


A software has to be tested rigorously for many of its parameters.

The parameters may not be limited to:

Challenge is also to predict the success rate of an application which depends on many iterations of the testing performed.

Best Practices

The below picture shows the software release lifecycle map:

#6) Release

Finally, the time comes when we have to deliver the product to its intended users. We all as a team have worked hard to sign off the product and let the software help its users.


 Software test engineers are primarily responsible for the release of any software. This activity requires process-oriented workflow. Here are some of the best practices that are involved in this phase.

Best Practices


QA Testing Process on a Real Project – Waterfall Method

I got an interesting question from a reader, How is testing carried out in a company i.e in a practical environment?

Those who just pass out from college and start searching for jobs have this curiosity – how would be the actual working environment in a company?

Here I have focused on the actual working process of Software Testing in the companies.

Whenever we get any new project there is an initial project familiarity meeting. In this meeting, we basically discuss on who is the client? what is the project duration and when is its delivery? Who are all involved in the project i.e manager, Tech leads, QA leads, developers, testers etc.?

From the SRS (software requirement specification) project plan is developed. The responsibility of testers is to create a software test plan from this SRS and project plan. Developers start coding from the design. The project work is divided into different modules and these project modules are distributed among the developers.

In the meantime, the responsibility of a tester is to create test scenario and write test cases according to the assigned modules. We try to cover almost all the functional test cases from SRS.  The data can be maintained manually in some excel test case templates or bug tracking tools.

When developers finish the individual modules, those modules are assigned to the testers.  Smoke testing is performed on these modules and if they fail this test, modules are reassigned to the respective developers for a fix.

For passed modules, manual testing is carried out from the written test cases. If any bug is found that gets assigned to the module developer and get logged in bug tracking tool. On bug fix, a tester does bug verification and regression testing of all related modules. If bug passes the verification it is marked as verified and marked as closed. Otherwise, above-mentioned bug cycle gets repeated.(I will cover the bug life cycle in another post)

Different tests are performed on individual modules and integration testing on module integration. These tests include Compatibility testing i.e testing application on different hardware, OS versions, software platform, different browsers etc.

Load and stress testing is also carried out according to SRS. Finally, system testing is performed by creating virtual client environment. Once all the test cases are executed, a test report is prepared and the decision is taken to release the product!

Steps in Requirements to Release

Given below are the details of each testing step that is carried out in each software quality and testing life cycle specified by IEEE and ISO standards:

#1) SRS Review: Review of the software requirement specifications

#2) Objectives are set for Major releases

#3) Target Date planned for the Releases

#4) Detailed Project Plan is built. This includes the decision on Design Specifications

#5) Develop Test Plan based on Design Specifications

#6) Test Plan: This includes objectives, the methodology adopted while testing, features to be tested and not to be tested, risk criteria, testing schedule, multi-platform support and the resource allocation for testing.

#7) Test Specifications

This document includes technical details (Software requirements) required prior to testing.

#8) Writing of Test Cases

#9) Development – Modules are developed one by one

#10) Installers Binding: Installers are built around the individual product.

#11) Build procedure :

A build includes Installers of the available products – multiple platforms.

#12) Testing

Smoke Test (BVT): Basic application test to take decision on further testing

#13) Test Summary Report

#14) Code freezing

#15) Testing

#16) Decision to release the product

#17) Post-release scenario for further objectives.

This was a summary of an actual testing process in a company environment.


The job of a software tester is full of challenges, yet an enjoyable one. This is for someone who is equally passionate, motivated and full of enthusiasm. Finding faults in someone is not always an easy job! This requires a lot of skills and a bull’s eye to the defects.

Besides all the qualities, a tester should be process-oriented as well. Like all the other industries, projects in IT are too worked in phases, where every phase has some well-defined goals.  And every goal has a well-defined acceptance criterion. A test engineer has to carry many loads of software quality on his/her shoulders.

While working in any phase of software, testers are supposed to follow the best practices and should align with the process involved in the respective phases.  Following the best practices and well-formulated process not just helps to ease testers work, it also helps in assuring the quality of the software.

Have you been a part of any of the above phases? Feel free to share your experiences below.