QA PROCESS FOR AGILE

DEVELOPMENT

QA IN AGILE PROCESS
The traditional models of software development have TESTING as a separate activity at the end
of the development process. In Agile, there is no such distinct process. Rather, testing is
ingrained into the development process.
QA is NOT the gatekeeper of the quality of the product in agile. Role of QA is around defending
the quality for the team by developing proper measures. On Agile Teams, testers serve as
quality coaches within the team, sharing testing knowledge and supporting quality assurance
work within the team. Quality is responsibility of the ENTIRE Scrum Team.

CHALLENGES
QA face several challenges when working in an agile development:

Inadequate time to prepare test cases and plans.

Lack of detailed requirement (Story)

Changing requirements.

Highly compressed test execution cycles.

Lack of time for testing,regression and executing test cases.

Pace of each iteration or cycle squeeze the test team's ability to develop and maintain tests.

Code that worked in previous sprints gets churned by new features in each
subsequent sprint, increasing the risk of regression

In the section below I have listed the various phases of agile development and the role of QA:
1.
2.
3.
4.
5.
6.
7.

Release planning
Sprint Planning meeting
During the Sprint
Daily Stand up meeting
Bug triage meeting
Sprint review
Sprint retrospect

1. Release planning stage

QA perform the following tasks during release planning:

Create high level test plans.

Get test plan approved by the entire team and the client.

Typical Test plan may include:

Scope of testing

A test strategy that describes how the system is usually tested

New functionalities which are being tested

Types/ level of testing based on the complexity of the features being tested

Infrastructure consideration (Test environment/ both OS and devices which testing has to be performed).

Risks/ mitigation plans

Resourcing

Test estimations

Testing types (functional, integration..)

Entry and Exit criteria.

Milestones and deliverables

2. Sprint planning
When the scrum begins the combined team, including QA takes responsibility for analyzing the
business requirements (e.g. user stories). They together define the sprint goal.

During planning, QA will have a great deal of input and raise helpful questions developers
may not have thought about.
QA is involved early on user stories with product owners and business analysts.
QA provides feedback on user stories while they are being analyzed.
QA determines the testability of the user stories.
QA needs to work with business owners to define Acceptance criteria

Acceptance criteria are the requirements that have to be met for a story to be
assessed as complete. Acceptance criteria constitute our Definition of Done. QA
help to determine if stories and their acceptance criteria are well defined and if
they satisfy customer requirements. User stories are subjective.
Each user story needs to have associated user story acceptance criteria. It helps
to remove ambiguity and improve understanding. Product owner will verify the
deliverable with the acceptance criteria. User story is said to be done only when
all the acceptance criteria for a story is met. A user story can be either done or
not done.

QA Estimate
The QA time effort estimate is a part of overall story point assignment. It is a common mistake
to discount QA time as part of estimate.
o In addition to known defects, we must also allocate time for fixing defects which are
not yet known -- that is, the defects which will be found during the upcoming sprint.
These defects may be related to the stories under development in the current sprint.
Or they may be found during system integration or other testing which could only
take place after an earlier sprint had been completed. Neglecting to allocate time to
fix unknown defects makes the sprint plan inaccurate.
Story Points = Dev Time + Test Time

Story Points are units of measure used in Agile to reflect the amount of work needed to
complete a user story. Agile refers to the estimation exercise as story sizing. When teams do
story sizing, they often forget to include test time in their overall estimation.
More often overlooked is the test-fix-retest cycle thats necessary when a critical defect is
found that prevents the story from being accepted. For our sprints to be successful, its critical
to include these in our sizing.

3. During the sprint

QA performs following tasks during the sprint:

Design
QA should be proactive and test if the designs have any issues:

Test the prototype and analyze the flow.

Identify and report design issues.
Question the product owner and clarify the doubts.
Have discussions with designers and provide suggestion to improve the UX.

Code
QA work side by side with the developers in a single team, taking a proactive approach and try
to avoid problems rather than fixing it at the end.
Below are the activities that QA perform:

Monitor and assist developers in executing Unit test cases.

Create test cases/test ideas/checklists for the current sprint using stories(QA)
Get the test cases/test ideas/checklists reviewed and share them with the team.

Test Ideas
In traditional work, there are often lots of test cases. They also occur in Agile work,
sometimes largely, and sometimes to a lesser extent. The disadvantage of the
traditional test case in an Agile project is that it takes quite a lot of time to plan and
write them. In many cases test ideas work better.
Make a list per area to be tested and in each case describe in 1-2 lines what should be
tested. In the end, your list will look like a bunch of one-liners. It is also wise to create a
supplementary checklist with general tests. If the need arises in the future they can be
converted to traditional test cases.
Agile stresses on working software over comprehensive documentation. Of course,
this does not mean that all documentation is unnecessary. Documentation is a tool to
achieve the goal, and the goal is working software.

Preparation of test data, Configuring testing tools etc

Setup QA test environment
Create traceability between the requirements and test ideas and try to improve the test
coverage.
Agile projects have short iterations enabling the project team to receive early and
continuous feedback on product quality throughout the development lifecycle. One way
to provide rapid feedback is by continuous integration.
o Continuous Integration (CI) is the practice, in software engineering, of merging
all developer working copies with a shared mainline multiple times a day. The
main aim is to overcome integration issues. Continuous Integration
automatically:
Static code analysis
Compile
Unit test (functional/ non-functional)
Deploy
Integration test (functional/ non-functional)
Perform Pair testing with developers to prevent defects.

Pair Testing
When a developer develops a feature, he runs the unit tests and also a quick round of
testing to ensure that the feature is working. He then invites the tester to test the
functionality in dev environment. If there are any issues then developer will fix it
immediately. Once the tests pass the developer will commit the code to the master.
This helps to identify and fix issues early. In this way bugs are detected and resolved
early.
The tester performs further tests in the testing environment. If the tests fail then the
developer continue to fix the issues. Pair testing can be performed when developer
has completed a feature or fixed an issue.

Test Executions
1. Perform Functional and Automated test executions:

Manual testing of new features, changes, and defect fixes.

Perform smoke/BVT tests on the build
Perform exploratory testing on early builds.
Automate regression tests.
o Run automated regression tests.
o Look to improve automation tests by adding and refactoring existing tests.
Log the bugs in the defect tracker.

2. Perform non-functional testing (load, security, usability, accessibility etc)

3. After completion of testing the testing team will send out an end of testing report. The
report will explain the outcome of testing in detail. The report will consist of:
1. Tasks accomplished in the sprint
2. User stories tested
3. Tests performed
4. Summary
5. Matrices
6. Plan for next sprint
Once the testing is complete the team determines, along with the client, which defects are to
be fixed in the current sprint. The estimates for each item should be planned keeping the bug
fixes in mind.

4. Bug triage
The process of deciding which bugs to fix and which to leave in the product is called as Triage.
A bug triage meeting should be held regularly at during the testing cycle of a project. At the bug
triage meeting, each defect should be discussed, even those that are rated at a lower priority.
The developer should present the level of complexity and the risk associated with fixing each
defect. The Change control board (CCB) makes the final decision whether to fix, defer or reject
the bugs. CCB usually consists of representatives of key stakeholder groups. Scrum master
updates the defect tracer as and when the priorities are decided.

Triaging a bug involves:

Making sure the bug has enough information for the developers and makes sense
Making sure the bug is filed in the correct place
Making sure the bug has sensible "Severity" and "Priority" fields

QA role in triage meeting

Prior to the meeting, the QA lead will send out a bug report with the new defects reported
in the current iteration.

QA act as quality advocates in the bug-triage meeting

If a bug is rejected or deferred or rejected and if QA feels that bug is really important to fix
then they can appeal the no-fix decision. QA can say fix it and can argue passionately for
the fix. They can investigate that bug some more and try to add more details to the bug and
ask the scrum master and product owners to reconsider the issue.

Build deployment
1. Dev should freeze the code after the allocated time is completed and must deploy an
integrated build. It is the responsibility of the developers to perform unit testing, integration
testing before deploying build to QA.
2. Developers should send out a mail when they deploy a build. It is mandatory to update JIRA
and make the items Ready for QA.QA team will only take up the defects in Ready for QA
status. The deployment mail should clearly mention the below:
1.
2.
3.
4.
5.

New features implemented.

Version number
The bugs that were fixed.
Known issues.
Impact areas(if any)

3. Testers will reject the build if the app fails the smoke tests or if the mail is not testable.
4. Version control is mandatory. A build should be versioned appropriately (Eg: Inblox 1.0). QA
will mention the build in the bug reports so that bugs can be tracked efficiently. The new
features, bugs fixed in every version should be tracked in a shared folder with the version
number.

QA cycles
In the beginning of the first sprint the team prioritizes and decides which user stories should be
present in the sprint. While the development team starts the implementation simultaneously
the QA team begins work on the test ideas.
The QA starts the testing process once the build is deployed. The defects found are raised.
When QA are testing the sprint 1 the Dev team should move forward and start developing the
new features for sprint 2.
Below is the diagram which explains the Sprint 1:

In some sprints we might encounter lots of issues and a hardening sprint can be planned.
A hardening sprint is an additional sprint that some Scrum teams run at the completion of a
regular sprint. In a hardening sprint, the team stops focusing on delivering new features or
architecture, and instead spends their time on stabilizing the system and getting it ready to be
released. A hardening sprint can be used for bug fixes in previous sprints. Bugs that are
prioritized will be considered here. Hardening sprint may not be a good indication and suggests
that the lots of issues are occurring.

5. Daily Standup meeting

It's important for every QA to attend and contribute to the daily stand-up meetings. QA need
to communicate the following in a stand up meeting:

Report the progress of testing.

Clarify any doubts on user stories from product owners.
The most important part of a daily stand-up meeting is sharing the obstacles that will
prevent you from making progress as a tester on the team.
Discuss major issues that were identified.

6. Sprint review
In Scrum, each sprint is required to deliver a potentially shippable product increment. This
means that at the end of each sprint, the team has produced a coded, tested and usable piece
of software.
So at the end of each sprint, a sprint review meeting is held. During this meeting, the Scrum
team shows what they accomplished during the sprint. Typically this takes the form of a demo
of the new features.
The sprint review meeting is intentionally kept very informal. A sprint review meeting should
not become a distraction or significant detour for the team; rather, it should be a natural result
of the sprint.
Role of the tester in review meeting:

Involve in demonstration the stories to the stakeholders during Sprint Review.

Assist the product owner to analyze and determine if we have met the acceptance
criteria.

7. Retrospective
In Agile development, a retrospective is a meeting held at the end of each iteration to discuss
what was successful, what could be improved, and how to incorporate the improvements and
retain the successes in future iterations.

Retrospectives cover topics such as the process, people, organizations, relationships, and
tools.
Testers should play an important role in the retrospectives. Testers are part of the team and
bring their unique perspective. Testing occurs in each sprint and vitally contributes to
success.
Testers can provide input on both testing and non-testing activities.
Retrospectives can result in test-related improvement decisions focused on test
effectiveness, test productivity, test case quality, and team satisfaction. They may also
address the testability of the applications, user stories, features, or system interfaces. Root
cause analysis of defects can drive testing and development improvements.

BEST PRACTICES

EXPLORATORY TESTING
is a style of testing that emphasizes
concurrent product exploration, test
design, and test execution. In today's
topsy-turvy world of incomplete,
rapidly changing requirements and
minimal time for testing.
Exploratory Testing is very important
and typically a lot of issues are found
from this type of testing.

MIND MAPPING
Mind mapping is a useful tool when
testing.
For example, testers can use mind
mapping for tracebility,reporting,test
cases, improving coverage etc

BETTER COMMUNICATION AND

MORE COLLABORATION AMONG
QA & DEVELOPMENT
Dev and QA are part now of the same
agile team. They need to get together
on a daily basis and have more
frequent communication among
themselves.
Eliminating barriers between QA and
development is esssential for the
success because there is a single agile
team now working to achieve a
common goal.

INCREMENTAL TEST DESIGN

Test cases are gradually built from user
stories and other test bases, starting
with simple tests and moving toward
more complex ones.

TEST EARLY
PAIR TESTING
A developer and a tester sit for an
exploratory session sharing a single
screen. They test a feature by
mutually sharing ideas
Pair testing has proven to be
successful when the deadlines are
close and we need a quality product
in a short span. Pair testing can help
the team to get together, share
ideas and be benefited by each
others strengths.

AUTOMATE REGRESSION TEST

CASES
Completing both regressions testing
and testing of new features in a
short incremental cycle is a big
challenge.
To overcome the challenge, testers
need the skills to automate routine
tasks and adopt newer tools.

Testing should involve in all phases

of SDLC. Test planning should be
started from beginning of the
project.
Start testing early in the software
development would solve the
problem, as the earlier you find a
bug, the cheaper it is to fix it.

TEST ALL THE SOFTWARE WORK

PRODUCTS
Testing involves both static and
dynamic testing. Dont restrict your
testing only the code. Review the
software test products like design
doc,specifications etc