Translator

7 Practices to Agile QA

If you are transitioning to Agile/Scrum and wondering how your existing QA practices need to evolve in the new world, here are 7 practices that you should consider implementing.

1. "In-cycle" QA. Traditionally QA team is a separate team and . QA testers should be integral part of the development team. They should be working very closely with the developers on stories in the same sprint/iteration. If QA testing is done in the next sprint for stories implemented in the previous (out-of-cycle), the team will always find itself doing a catch-up and end up accumulating "technical debt." As a rule of thumb, you would need 1 tester for every 3 developers. However, everybody on the team should be willing to jump in and help with QA testing. When planning, make sure to adequately account for QA activities. It is OK to take on fewer stories in the beginning to find the team rhythm before trying to increase the velocity.

2. Implement 5 Quality Gates. Traditionally QA is seen as just performing functional/system tests. But, software development is a highly integrated process. The quality of each activity- requirements, design, and coding, could impact the amount of effort needed in testing. If quality issues that could have been detected and prevented during these other activities are left for testing to catch them, there may not be enough time to fix the issues. Even worse, it may not be found until after deployment. QA needs to expand beyond just testing and should include the following QA gates.


Fig. 1: Quality Funnel
  • Quality Gate#1- peer review of requirements. Make sure stories meet INVEST (independent, negotiable, valuable, estimable, small, and testable) criteria as much as possible. This could be an on-going activity as part of pre-planning/product backlog grooming and not tied to a specific sprint.
  • Quality Gate#2- peer review of design. Make sure the design is in-line with the architecture guideline/style and appropriate alternatives are considered.
  • Quality Gate#3- peer review of codes. Make sure appropriate unit tests are written, coding standards are followed, and above all ensure codes follows design.
  • Quality Gate#4- continuous integration. Make sure code is being integrated and automated tests are run on a continuous basis and any issues that surfaces are addressed immediately.
  • Quality Gate#5- automated functional tests. Make sure QA testers are testing using automated scripts as much as possible.
3. Target 90% test coverage with automated testing. Even though test coverage does not tell anything about the quality of tests, it tells you where you need to focus more than others. Without test automation, it would be difficult to accommodate adequate testing in a sprint.

4. Inspect and adapt. Do not just stop at identifying the technical cause of a bug. Understand where (the quality gate) this bug could have been caught and improve the associated process.

5. Definition of "Done." Include all quality gates as part of your definition of "done."

6. Fix all know bugs first. Traditionally bugs are triaged based on severity as well as other works in the pipeline. The danger of doing this is that a seemingly minor/cosmetic bug could result into a large cumulative technical debt over time. Fixing bugs as soon as they are found can be less costly and time consuming than to wait for the right time to fix them.

7. Prioritize test cases. The intention behind this practice may not be apparent at first. The idea is that tests cost time and money. You can spend inordinate time in tests without getting any incremental/marginal value. Knowing how much testing is enough as well as what tests are more important than others not only will save time but also will ensure quality of testing. In order to understand what to test first, you could map your stories along two dimensions- frequency of use and risks of having bugs. The stories that gets used more often and also would have high risks should bugs are encountered needs to tested first and more.



I would be interested to know how you are doing QA on your Agile projects.

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

A Few Thoughts on the Economics of Software Product Development

Some of you probably already get this… some of you might even disagree… but unless you are building software as a hobby… chances are, you building software for money. In other words, someone is paying you to write software for them. Why would someone pay you money to show up and write software? They are [...]

Podcast with IT Kanban

Kevin Ryan at IT Kanban just released a podcast with me. Check it out
Cheers
Mattias

Lean from the Trenches – Managing Large-Scale Projects with Kanban

I’ve published another book! This one’s called “Lean from the Trenches“. It is about how we scaled a 60-person project by combing techniques from Kanban, Scrum, and XP. I chose this title because it really it illustrates how to put Lean principles into practice in a software project, especially the notion of an end-to-end Kanban read more »

Coming to Brazil

Hi Brazil! I’m happy to say that I’ll be visiting you in a few weeks. I’ll be involved in two public events together with Samuel Crescêncio: Feb 10: Public seminar about Lean & Agile (in Florianopolis). More info coming soon. Feb 13-14:  Certified ScrumMaster course in São Paulo. The course will be in English, but Samuel read more »

AgileExams.com Controversy Resolved…Sort Of

Well it turns out the “controversy” about AgileExams turned out to be the biggest of misunderstandings. The Testimonials Were Authentic: Several of AgileExams customers contacted me and revealed the root cause of this confusion is the fussiness of PMI.org’s online … Continue reading