Testing: are Agility and Complex projects good friends?

Feb 14, 2014
Sogeti Labs

Pair testing gone wrongThis post follows previous Gro Rognstad’s entry about how Product Owners should be supported in Agile process, to allow better results in the development process. My humble contribution wants to show that even in adverse conditions, it is still possible to have a controlled and efficient testing process.

In the past few years, we have been able to witness a major shift in software development methodologies: Agile methods, through their various implementations, are now everywhere. Nowadays, companies that do not have their own Agile Software Development Lifecycle (SDLC) seem to be coming from another age (closer to prehistory than to 21st century).

Nevertheless, when coming to complex projects, Agile methodologies are much tougher to manage than initially foreseen, and a lot of challenges must be solved, due to the increased complexity of interactions between several development teams. Talking specifically about testing (sorry, that’s my job…), our experience shows that in these kinds of complex projects, one should not throw away all the experience acquired during the “prehistoric” times we were talking about at the beginning of this post.

Let’s talk about a real example: two years ago we started a project for a low-cost airline that was (as they usually do in this business) moving very fast in a very competitive market. At that time, a lot of new features were developed and tested during each release cycle. And yes, they were able to deliver the new functionality as planned, and in a rather good shape. Unfortunately, doing such a good job on new functionality had a drawback: not enough time and, more than anything, not enough forward thinking to organize an efficient regression testing process. This problem was particularly critical as almost no part of the system was kept untouched during new releases.

Don’t forget that the customer was a low cost airline with a tight budget; because optimization was key, we started by first controlling the regression test process and introducing some TMap® techniques to optimize testing coverage:

  • Effort estimation using standard techniques
  • Risk based test prioritization
  • Optimized test design based on TMap® techniques

These techniques, which are of common use in normal (i.e. not Agile) testing projects, were rather simple to implement and immediately brought profits to the customer, allowing for better control of regression testing process, and limiting defect leakage in production.

Pair testing gone wrongOnce regression testing process went under control, we started to extend these techniques to the rest of the testing phases, resulting also in benefits on the coverage obtained during the testing of new features. Once again, utilizing “old-world” techniques but maintaining agility helped to join the best of both world: fast movement and quick results but in a controlled and predictable matter, something which is more than important when you really want to go fast…

This post was based on the document created by Isaac Alvarez from Sogeti Spain, which describes in a more detailed way the real story behind this post. Interested to know more? Let me know.

About the author

SogetiLabs gathers distinguished technology leaders from around the Sogeti world. It is an initiative explaining not how IT works, but what IT means for business.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Slide to submit