Keys to Agile Testing Success
Posted on August 21st, 2008 in Software Testing Trends by Stanton Champion
Testing in an agile environment can be a challenge, but the benefits to having good testing are enormous. Here are a few keys to agile testing success:
- Test Early – The key to agile is iteration: developing, testing, and developing again. To get the most out of an agile process, you have to test early. That means that you think about testing not just after the first couple of sprints, but at the very beginning of the development cycle.
- Test Often – A good agile process emphasizes frequent testing. You are looking for defects early in the testing cycle. The longer defects wait in the code, the harder and more expensive they will be to remove.
- Refactoring/Regression – Stop every few weeks to focus on stability. Fix bugs, refactor old code, and run extensive regression testing to make sure you didn’t miss bugs during the ongoing testing process.
- Test from a Customer Point of View – As with any development process, it’s critical that the testers and developers know the customer’s point of view. That means having good stories with customer relevant material, and then sharing those stories with the development team as well as the testing team.
- Separate Testing from Development – This is often difficult for smaller teams, but testers should be independent. Keeping testers separate means they can develop true testing expertise while focusing on finding bugs.
- Communicate – Having good communication between the testers, developers, and product guys is a key essential to a solid agile process. Even though testers should be separate from developers, they should work closely together to get the most from testing.
- Automate What you Can – The best agile teams automate as much of their testing load as they can. Repeatedly testing the same case over and over is a waste of time. Locating new bugs is far more valuable for any tester.
These are a few basic guidelines to getting the most from an agile development process, and there are certainly many more best practices.
uTest is a great fit for agile testing, and our agile testing services can offer in-depth testing results on an on-demand basis. The uTest community can get your agile developers results when they need them.
Want to learn more? Sign up for our upcoming Agile Testing Webinar. Every participant will receive an agile testing case study about how uTest can be an outstanding agile partner.
Very interesting tips! I agree whole-heartedly with all of them except one.
The one I question is separating testing from development. I think that’s what people have been doing for about 15 years, but I’m not sure it works.
Instead, I’d love to see developers become competent testers by constantly testing each other’s work. Not their own work, but each other’s within the team.
What do you think?
Hi Yoav,
To my approach Software Testing (and QA) is not the responsibility of the Testing/QA team ONLY. It’s something that the product guys should do (to validate requirements), the developers should do off course a lot of testing to their own code(a.k.a “unit testing”) and in the Agile way even review their team mate code. And, The testing team should be the final cycle before deploying to verify that all the prior cycles was done properly. In an ideal world (or development process) the Testing team would not find a single bug…:) but since we are all humans I think this cycle is necessary.
Roy
Yoav,
I can think of a few problems with having developers do all the testing. First of all, I completely agree that developers should have some role in the testing process. They should check each other’s work, but I’m not sure that qualifies as real testing. Here’s my thinking:
Testing is its own discipline, so by having people do both development and testing you’re losing some benefits of specialization. Developers should be involved in the testing cycles, but software testing is a profession and a specialty that has its own unique characteristics and methods.
I also think confirmation bias is a problem when people test their own stuff. Developers are too tied to their own product to see all the bugs, even when testing someone else’s code. Having someone, like a tester, who is fully divested from the underlying politics of development can really help dig out new things.
I think the thing to remember here is that separating the two groups isn’t a requirement, just a good practice. There are development groups that do their own testing just fine, either because the project is small enough or the team is structured enough to do the job well. However, I think these are the exceptions, and that most groups could benefit from having more separation.