Downloaded 17 times
Introducing QA Into an Agile Environment
- 1. Introducing QA Intoan Agile Environment Joseph Beale CareWorks Technologies
- 2. What’s Important toKnow 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 TheseGuys?
- 4. Is a TestingDiscipline 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 ColdWar, 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 ColdWar, 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 ColdWar, 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: Assessingthe 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: Assessingthe 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: Assessingthe 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: Assessingthe Challenges • Challenge #4: WE were not confident in our testing processes. Why not?
- 12. The QA SuccessChain Collaboration Commitment Communication Competence
- 13. The Role ofQA QA personnel should have a role in all of these agile processes: Sprint Planning Amigo Reviews Daily Stand-up Demo Retrospective
- 14. The Role ofQA SPRINT PLANNING A QA person might introduce cards for Automation scenarios or any framework or infrastructure tasks related to Automation.
- 15. The Role ofQA 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 ofQA 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 ofQA 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 ofQA 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 ofQA 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 AGILEQA = 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 ALLDEFECTS 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 • Inthe 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 aFunny 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 andWorkflow • 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 andWorkflow • 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 • Wewere 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.
- 30. How to ContactMe • 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!!!