Where does Regression Testing fit into Agile?

If you are recent to Agile like us you are probably still figuring out how you previous tasks fit into the process. We have been using scrum for a while now and completed several sprints without releasing a build to customers. When it came time to release we looked over what areas had been changed and it was a very large chunk of core features. Our App is in VB6 so Automated regression tests are out of the question at the moment, i am working on writing an extension for Coded UI Tests though, so this means that all or testing is done manually. To be confident that we did not introduce new buts this meant we had to spend 3 weeks just doing regression testing. This alone goes against scrum principles because your product should be potentially releasable at the end of each sprint. So we knew doing a massive block of testing like this didn’t seem right but what is the best way to handle regressing testing in an Agile environment

I Just started reading Agile Testing by Lisa Crispin and Janet Gregory and its very insightful. I would recommend giving it a read even if your not a tester it talks about different levels of testing and how they fit into the Agile process.

So how do they recommend you handle regression testing? Regression testing should be included as part of your Done Criteria, this makes a lot of since when you think about it. It means that at the end of the sprint your product is potentially releasable. If you haven’t made sure the affected area’s have not been touched then you can not be confidant that releasing the product  would be a good idea. One of the important things of scum is the constant review process, what went well and what didn’t? Which is why this is one small change we are making and i think we will get many more good ideas from this book. Of course the most beneficial way to do this would be to have an set of automated regression tests but if this is not possible its up to the team to help out. This might mean you need your testers to create good documentation that the programmers can follow to make sure the team completes the sprint.

Advertisements
  1. #1 by David Fevre on September 23, 2011 - 7:47 am

    I’ve been thinking about this kind of thing too. In fact, I read an article by the author of that book, Lisa Crispin, today – http://www.financialagile.com/reflections/17-essay201109/113-its-not-testing

    I like the idea of everyone on the team being responsible for quality and not just their particular speciality.

    • #2 by RBurnham on September 23, 2011 - 2:57 pm

      I think this quote sums up what we should all aim for “When programmers commit to producing great software, they start thinking about ways to facilitate test automation. When business analysts are driven to delight customers, they look for opportunities to coordinate with testers and programmers to turn requirements into tests that drive development. Technical writers with passion for the user experience notice ways to enhance features and share those ideas with the team. DBAs wanting happy users find ways to tune performance”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: