0% found this document useful (0 votes)
21 views4 pages

The QA Process

Download as docx, pdf, or txt
Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1/ 4

The Agile QA process involves the following steps12:

1. Risk Analysis and Impact Assessment: The QA team gathers input from internal and external
stakeholders as well as target end users.

The QA team gathers input from internal and external stakeholders as well as target end
users. They identify the potential risks and issues, and categorize them based on their
anticipated effects. The analysis may not catch everything, but it will leave room to deal with
unforeseen issues if they occur.

2. Create Test Plan: QA and stakeholders create a test plan.

QA and stakeholders create a test plan. The plan covers every facet of the testing strategy,
such as the objectives, timeline, order of deliverables, and estimated budget as well as
resources for manual and automated testing. The plan also clearly outlines the objectives for
each testing method (i.e. Unit, Acceptance, Integration, and Smoke tests). This way, each
test is performed at the right time, in the right testing environment, and captures actionable
insights that help improve software quality.

Unlike a Waterfall test plan, an Agile plan is more flexible and incorporates continuous
feedback into each stage of development. This helps the team identify and resolve bugs
earlier and faster. As a result, bugs are less likely to be ingrained into the final product.

3. Predict Release Date: Every time a new feature or function is implemented into the build, it is
tested.

Every time a new feature or function is implemented into the build, it is tested. The feature
or function is uploaded to the source-code repository and thoroughly tested. If it is release-
ready, it passes. If not, the test results are recorded and sent to the development team. The
devs will then revise the feature or function and resubmit for review.

With each successful Agile sprint, the team will have a better idea as to what the most
realistic release date might be. They can then share this information with the customer. Most
customers will appreciate this level of honesty, and feel relieved knowing that their project is
being well-managed.

4. Daily Scrums

During a sprint, all stakeholders will meet each morning to share information and progress
updates. They may also set goals for that particular day, and prioritize any unmet goals from
the previous day.

Daily Agile scrums are a great way to motivate the team, resolve unforeseen issues, and
reflect on progress so far. They also help break down silos between departments, by filling in
knowledge and information gaps, as well as establishing shared accountability to keep
everyone focused and on the same page.

5. Sprint Review Meeting

At the end of a sprint, an informal meeting is held. Here, the team demonstrates the product
in-progress and determines what is finished and what needs more work. The usability of the
product is assessed in stages, throughout the course of development, in collaboration with
all stakeholders at once.
This is more beneficial than the traditional Waterfall approach. In Waterfall, the usability of a
software product is assessed near the end, after all of the coding and design decisions have
been made. By incorporating continuous feedback into each stage of development, Agile
makes it easier to identify what works and improve upon what does not work.

The Agile QA process begins at the inception of the software development life cycle and is repeated
in two-week sprints until the project is released2.
QA Process

QA process in agile is a way of ensuring the quality of software products throughout the
development lifecycle. QA is not a separate phase but a continuous activity that involves
collaboration, feedback, and testing. Some of the steps involved in agile QA process are:

 Risk analysis and impact assessment

The QA team gathers input from internal and external stakeholders as well as target end
users. They identify the potential risks and issues, and categorize them based on their
anticipated effects. The analysis may not catch everything, but it will leave room to deal with
unforeseen issues if they occur.

 Creating test plan

QA and stakeholders create a test plan. The plan covers every facet of the testing strategy,
such as the objectives, timeline, order of deliverables, and estimated budget as well as
resources for manual and automated testing. The plan also clearly outlines the objectives for
each testing method (i.e. Unit, Acceptance, Integration, and Smoke tests).

 Writing test cases

The test data preparation and test scenario writing activities go hand-in-hand, and not
necessarily sequentially. The (manual and to-be-automated) scenarios to be tested for this
story should be identified and updated in the Test Case Management tool being used.

 Approve the test cases


Once the test scenarios are written, these should be shared / reviewed (at least informally)
with the Business Analysts and the developers developing this story, to ensure the scenarios
are complete, and also the developers can probably identify missing pieces in the code at a
much earlier stage.

 Executing test cases

The QA team needs to identify test scenarios that make sense to be automated, and which
can be automated. Then the script automation should be started.

 Reporting and fixing defects

Along with the standard / regular defect reporting and verification process, a few additional
activities help a lot in reducing the turnaround for defects. When reporting the defects,
attach screen shots / videos (where applicable) to help the developers reproduce the
problem easily. This will ensure in quicker turnaround on the defect.

 Regression testing

There should be at least one round of Exploratory Testing for the story, and the features /
functionalities around the changes that have been developed as part of the story to ensure
there are no regressions or other issues in the product. Based on the time available in the
iteration, this can happen either on a developer sand-box, or deployed builds. Exploratory
Testing is very important and typically a lot of issues are found from this type of testing.
 Release testing

Every time a new feature or function is implemented into the build, it is tested. The feature
or function is uploaded to the source-code repository and thoroughly tested. If it is release-
ready, it passes. If not, the test results are recorded and sent to the development team. The
devs will then revise the feature or function and resubmit for review.

You can find more details about each step in these sources:

 Agile QA Process - Agile Alliance (PDF)

 How to Implement Quality Assurance (QA) Into the Agile Process

 Benefits of Setting QA Process in an Agile Environment

You might also like