QA - The Agile Approach
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
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)