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 are equally demanding as well.  Testers are supposed to be alert and enthusiastic in each and every phase 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.

The 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 scratch. Though there is pride in being since inception, it comes with some responsibilities and challenges too.

Challenges

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

• Keep your mind open and pay attention to every word of the product owner.
• Don’t just listen, clear your doubt however small it seems to be.
• Always use notebooks for fast note keeping. You should use a laptop, only if you can really type at a fair speed.
• Repeat the sentences and get them clarified from the PO which you think is what you understood.
• Draw block diagrams, link text, etc. to make requirements clear at a later period of time.
• If the teams are in different locations, try hard to make it a WebEx or similar recording. It will always help when you have a doubt after the discussions are over.

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

Once it is been documented with all the necessary points, distribute and discuss 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 that is not just sufficient to test the software better but should also instill confidence in every stakeholder regarding the quality of the product.

Challenges

The most crucial aspect of this phase is to create a strategy that 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 with high importance.

Best practices

• Here are some of the best practices, which when followed can provide you great relief and result in smooth testing.
• Go through the requirement document once again. Highlight the import points with respect to the environment of the target software.
• Make a list of environments where the software will actually be deployed.
• Environments can be understood as a type of Operating Systems or Mobile Devices.
• If Windows is the operating system, list down all the versions of the window where you will be testing your software. If the versions viz. Windows 7, Windows 10, or Windows Server(s) are still not defined in the requirement document, then it is high time when these should be discussed.
• On a similar note, get the target browsers with the versions discussed and documented if the AUT is a web-based system.
• Make a list of all the third-party software’s that the application will need (If required/supported). These may include Adobe Acrobat, Microsoft Office, any add-ons, etc.

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

The below figure will help you to understand the outline of the 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 a test strategy, test planning is also a crucial phase.

Challenges

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

• Always keep in mind, not to leave any stone unturned when it comes to testing your application.
• It’s time to formulate a test strategy.
• Create a matrix of the environment so that the software is tested on all platforms.
• Like, as Windows 10+Internet Explorer 11+ Windows Office 2010+.
• Like Android 4.2.2+ Chrome browser.
• If your application works with multiple databases (If documented), keep the databases (MySQL, Oracle, SQLServer) in the test matrix in such a way that they are too integrated with some tests.
• Configure test machines accordingly and name them as SetUp1, SetUp2, etc.
• SetUp1 will have Windows 7+ IE 10+ Office 2007+.
• SetUp2 may have Windows 10+ IE Edge+ Office 2013+.
• SetUp3 may have an Android phone with your .apk file installed.
• Congratulations! Your test setup is ready and you have also included every possible combination of platforms that your application will work upon.

#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.

The below diagram depicts the categorization of various testing types:

Challenges

Testing is a cumbersome process that 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.

• It’s always advisable to look at the application with a fresh look, WITHOUT GOING THROUGH TEST CASES.
• Follow the navigation path of your software (AUT).
• Get yourself familiar with the AUT.
• Now read the test cases (All) of any particular module (Maybe of your choice).
• Now go to the AUT and match the findings with those mentioned in the expected section of the test cases.
• The idea behind this is to test every mentioned feature on every supported platform.
• Make a note of every deviation however trivial it seems to be.
• Write down the steps of how you reach any deviation, take screenshots, capture error logs, server logs, and any other supporting documentation which can prove the existence of defects.
• Don’t hesitate to ask. Though you have the requirement document, there will be times when you will be in doubt.
• Reach out to the developers (if they sit next to you or they are reachable) in doubt before you reach out to the Product Owner. Understand the developer’s perspective on the working of the software. Understand them. If you feel this implementation is not according to the requirement, then inform the test manager.

#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.

Challenges

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

The parameters may not be limited to:

• Functionality /Behavioral.
• Performance.
• Scalability.
• Compatible with the said platforms.

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

Best Practices

• Make sure that all the features on all the platforms are tested.
• Highlight the areas which are not tested or the one which needs more testing efforts.
• Keep a matrix of all the test results before release. The test matrix will give an overall picture of the stability of the product. It will also help the management to take a call on the release dates.
• Provide your input/suggestions to the team about your experiences while testing the product.
• Your input considering yourself as the end-user will benefit the software by large.
• Due to a time crunch or any other such situation, we either miss out on some testing or do not go deep into this. Don’t hesitate to tell me the testing status of your manager.
• Present the application health card to the stakeholders. Health cards should have a number of all the logged, open, closed, and intermittent defects with their severity and priority.
• Draft a release document and share this with the team.
• Work on the release document prepared.
• Improve the areas which are been suggested by the management/team.

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.

Challenges

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

Best Practices

• Always remember, that you are not working on the release document on the date of ACTUAL RELEASE.
• Always plan the release activity prior to the actual release date.
• Standardize the document as per the company policies.
• Your release document should try to establish positive expectations from the software.
• Mention all the software and hardware requirements specific to their versions clearly in the document.
• Include all the open defects and their severity.
• Do not hide major impacted areas due to open defects. Give them a place in the Release document.
• Get the document reviewed and digitally signed [may differ as per company policy].
• Be confident and ship the release document along with the software.

QA Testing Process On A Real Project: Waterfall Method

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

Those who just pass out of 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 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 a 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 gets logged into the bug tracking tool. On bug fix, a tester does bug verification and regression testing of all related modules. If the bug passes the verification it is marked as verified and marked as closed. Otherwise, the 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 applications on different hardware, OS versions, software platforms, different browsers, etc.

Load and stress testing is also carried out according to SRS. Finally, system testing is performed by creating a 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 is 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

• Smoke (BVT) test cases
• Sanity Test cases
• Regression Test Cases
• Negative Test Cases
• Extended 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 – on multiple platforms.

#12) Testing: Smoke Test (BVT): Basic application test to take a decision on further testing.

• Testing of new features
• Cross-browser and cross-platform testing
• Stress testing and memory leakage testing.

#13) Test Summary Report

• Bug reports and other reports are created

#14) Code freezing

• No more new features are added at this point.

#15) Testing: Build and Regression 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.

Conclusion

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.