QA - The Agile Approach

DZone 's Guide to

QA - The Agile Approach

· Agile Zone ·
Free Resource
QA is always near and dear to our hearts. We all talk a lot about the fact that Quality is "King" but we certainly don't show it. In fact, we cut quality without even so much as a thought - "It's in our bones" (Ken Schwaber). For most of my software career, QA has always been an afterthought. Developers pushed to the limits, dates slipping, so what's the natural thing to do, cut quality, it's the easiest and quickest thing do. The problem with cutting quality and what we don't realize is that technical debt starts to rise exponentially. Eventually, and it's not even that long, 3 - 5 years for most companies, your codebase will drive you and your company into a corner. 

So how can you tell that your company is in this situation? Here are some tell tale signs:
  • New features start to take longer and longer to develop
  • Fewer people on the team know and understand the codebase
  • Making even the slightest changes breaks the code
  • Longer QA cycles at the end of a release
  • Rising Maintenance and support costs
  • More competitors enter the space
  • Shrinking customer base

How to get out of the mess ....

So if you find yourself in this same position what do you do. Well in some cases there's not much you can do and you'll be forced to start again from scratch. However, if you're lucky to catch this early enough, these are the things to start doing right away.

Plan on refactoring your codebase as soon as possible to start to pay back some of the technical debt - although in some cases this might be too late. You can do this in stages, by layer, by feature and functionality, or start with the highest risk code first.

Start implementing test harnesses if you don't already have them,  especially around fragile code segments

Develop an automated and continuous integration environment where code is compiled automatically on check-in

Do a quality release (bug fixes, refactoring only) with no new features added

Ensure you have a senior architect who knows what he is doing

Start doing peer code and design reviews 

If your team is too junior shaking things up a bit may be a good approach

How to avoid these pitfalls from the get go ...

  • Plan on conitnuously refactoring the code base. For every 2 week (10 days to be specific) sprint we spend at least 2 days refactoring code from previous Sprints ... the result is a solid emergent architecture that grows as the features warrant and nothing more.
  • Plan on fixing bugs first - at least high priority one and ones that matter. We spend a further at least 2 days every Sprint resolving bugs. Yes, do the math that leaves only 6 days out of every sprint to do new development work. Only a decade ago, this may not have been possible to work this way. But with changes in technology, we use Ruby on Rails, it is possible to do rapid software development and get a lot done in the 6 days, and even more so with a nice clean emergent architecture
  • Don't just do pair programming. But also pair developers with QA. QA folks think differently to developers and can add a ton of value front end loaded. This pays big divedents in the long run.
  • Retrain your QA teams to learn how to write unit tests/test harnesses and to use tools to monitor unit test code coverage. This not only makes them better at QA but increases their skill level and offers them new career opportunities in the long run
  • Strive for 100% unit test code coverage. Don't do it just for the sake of it but you'll be surprised how this will save your butt time and time again. Writing unit tests is not easy to do even when the environment supports it. The investment is well worth it. We have 100% unit test coverage using RSpec and as a result we are able to deploy new builds to production every  3 days and do this with confidence.
  • Automate as much of the functional testing as possible.
  • Ensure that code is integrated and automated tests are run continuously (In our environment, that means multiple times a day) and any issues that surface must be addressed immediately.
  • Ensure that you define your test criteria up front, even at the user story level.
  • Involve QA continuously rather than throwing the code over the wall to them when you're "code complete" - what were we thinking when we came up with this teminology - in my day code complete meant another 3 months of fixing bugs. Whereas now, code complete means ready to launch.
  • Continuous and on-going peer code and desing reviews
  • Pair programming as often and as required


Written by: Jack Milunksy - COO at Brightspark and Co-founder of Agilebuddy (An Agile project management tool, built with rich collaboration features for Scrum teams). For more from Jack please visit: www.twitter.com/agilebuddy and blog.agilebuddy.com 


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}