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: [show]

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.

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 more clear at a later period
of time.
 If the teams are in different locations, try hard making 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 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.

Challenges

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 are some of the best practices, which when followed can provide you a great
relief and result in a 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 the
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, 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.

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 test strategy.
 Create a matrix of the environment so that the software is tested on all platforms.
 Like, 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 test.
 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.

Below diagram depicts the categorization of various testing types:

Challenges

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.

 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.
 Idea behind 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 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 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

A 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 a 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 time crunch or any other such situation, we either miss out some testing or do
not go deep into this. Don’t hesitate to tell the testing status to your manager.
 Present the application health card to the stakeholders. Health card should have a
number of all the logged, open, closed, intermittent defects with their severity and
priority.
 Draft a release document and share this across the team.
 Work on the release document prepared.
 Improve on 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 process-oriented workflow. Here are some of the best practices that are
involved in this phase.

Best Practices

 Always remember, 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 the positive expectations from the
software.
 Mention all the software and hardware requirements with 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 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

 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 – multiple platforms.

#12) Testing
Smoke Test (BVT): Basic application test to take 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 report 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.