A case study of adding testing and software quality assurance in an existing agile work space.

1. Introducing QA Into an Agile Environment
Joseph Beale
CareWorks Technologies

2. What’s Important to Know About Me
• 20 years in IT
• The last 13 or so mostly testing
• The last 6 in mostly agile environments
• Motivated mostly by responsibility
• Seven children at home
• “Responding to change” is a way of life for me

3. Who Are These Guys?

4. Is a Testing Discipline Really Necessary?
• When the testing process is “buried in the mix” it’s
not visible to business partners.
• Agile teams with no QA discipline lean heavily on
Product Owners for validation, adding to their
already heavy workload.
• Developers like to develop, not test.
• A good tester is the developer’s best friend.

5. The Testing Cold War, First Release
• Testing is mostly ad hoc and disorganized, if it exists
at all.
• Business runs cursory validations, finds lots of issues.
• Business points finger at QA team (“Why didn’t you
find all the bugs?!?!”)
• QA stares at the ground and sheepishly promises to
do better next time, while privately vowing to “bury
them” with tests in the next release.

6. The Testing Cold War, Second Release
• Testing is keyed to requirements and rigorously
organized into stages. And there’s a lot of it.
• Business assigns their own testers, who find lots of
bugs (both real and imaginary). They point the finger
at QA and Development.
• Development pushes back against questionable bug
claims, calling them “missed requirements”.
• QA silently vows to closely scrutinize requirements in
the next release.

7. The Testing Cold War, Third Release
• QA team demands many clarifications in
requirements to make them testable.
• Code is delivered with far fewer defects but much
later in the process, leaving little time for business
validation.
• Business grinds their teeth at the prospect of their
work being scrutinized so heavily; vows to use their
own testers exclusively next time.

8. Case Study: Assessing the Challenges
• Challenge #1:
Our business partners felt that they must test every
detail of the application.
Much of that could be attributed to…

9. Case Study: Assessing the Challenges
• Challenge #2:
Our business partners were not confident in (or in
some cases, even aware of) the existing test
processes.
Much of that could be attributed to…

10. Case Study: Assessing the Challenges
• Challenge #3:
Our testing processes and results were not readily
visible to our business partners (or anyone else).
Much of that could be attributed to…

11. Case Study: Assessing the Challenges
• Challenge #4:
WE were not confident in our testing processes.
Why not?

12. The QA Success Chain
Collaboration
Commitment
Communication
Competence

13. The Role of QA
QA personnel should have a role in all of these agile
processes:
 Sprint Planning
 Amigo Reviews
 Daily Stand-up
 Demo
 Retrospective

14. The Role of QA
SPRINT PLANNING
A QA person might introduce cards for Automation
scenarios or any framework or infrastructure tasks
related to Automation.

15. The Role of QA
AMIGO REVIEWS
QA personnel should be involved in helping establish
Acceptance Criteria (Entrance) and determining
whether or not the criteria have been met (Exit).

16. The Role of QA
DAILY STAND-UP
QA personnel will be present at all stand-ups to talk
about cards they are working and answer any questions
that others might have about testing progress,
acceptance criteria, etc.

17. The Role of QA
DEMO
QA personnel should assist the Product Owner(s) in
preparing for the demo and might even lead the demo
in some circumstances. Regardless, what is
demonstrated will reflect not only the judgement of the
PO but also the analysis and approval of the QA person.

18. The Role of QA
RETROSPECTIVE
QA personnel are uniquely equipped to provide
constructive feedback on sprint processes and
interactions. It is simply a matter of applying their
normal skills to a larger question.

19. The Visibility of QA
THE CARD WALL
We added two new columns to the wall: Ready for QA
and QA in Progress. We also identified specific criteria
for moving from Dev in Progress to Ready for QA and
for moving from QA in Progress to Ready for Review.

20. In a Nutshell
AGILE QA = FAST FEEDBACK
Our Agile QA strategy was to incorporate QA personnel
within the existing agile framework and ensure that all
of the traditional QA processes (analysis of
requirements, test case creation and execution, defect
identification, etc.) are broken into small units and
worked through the process like everything else.

21. The Ultimate Goal
ALL DEFECTS SHOULD BE FOUND BY OUR GROUP
When business testers consistently find no defects (or
very few), they will change their testing mentality for
the better.

22. Early Success
• In the first two sprints after this strategy was fully
implemented, velocity was not adversely affected by
the additional process steps.
• In fact, total team velocity continued to trend
upwards, just like it had been trending previously.
• Business collaboration increased in both frequency
and intensity as QA personnel acted as catalysts for
conversation and cooperation.

23. And Then a Funny Thing Happened

24. Responding to Change
• Business partners asked if we had capacity for doing
their testing.
• Needed to determine the types of testing and where
they would take place.
• Conducted a series of meetings to work through it.
• Then socialized the solution to everyone else

25. Changing Terminology and Workflow
• The term “UAT” was discarded because it was
inaccurate and confusing.
• Levels 1, 2, 3: to describe testing accurately based on
scope, location, and data.
• New process to work testing around development
releases and milestones.
• New card category for testing work not associated
with development.

26. Changing Terminology and Workflow
• Level 1: Testing in sprints as usual.
• Level 2: Test based on a Feature Set in container.
• Level 3: Cumulative test based on a super-set of
Features in container.
• Production validation.
• Client site testing.

27. Old World vs. New World
• Development is agile but funding is traditional.
• Culture change happens one layer of bureaucracy at
a time.
• Any form of documentation can become a contract.

28. In Summary
• We were able to earn trust quickly by being
transparent with our process.
• Once we showed some success, the tensions
between business and development began to ease.
• As we expanded into more areas of testing, the need
to collaborate and communicate increased.
• We were able to keep the process agile as long as we
retained the work in our team space.

29. Questions?

30. How to Contact Me
• Email: joseph_beale@att.net
• LinkedIn: search my name
• Twitter: @JosephBealeQA
• Would love to hear your feedback on this
session
https://www.surveymonkey.com/r/PathSessions
2016
• THANK YOU!!!