February 14, 2014

Testing: are Agility and Complex projects good friends?

BY :     February 14, 2014

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.

Sogeti Labs


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.

Related Posts

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

6 + 5 =

  1. Jos Punter · February 14, 2014 Reply

    Hi Patrice,
    I got one question where does agile say to trow all the experience away that you acquired ?
    “..one should not throw away all the experience acquired”
    This is a common misbelieve of agile. Nowhere does it say to do so.

    I assume this team worked as a scrum team ? Scrum is a frame work especially good for complex projects like these. What you experience was kaizen, you got feedback from your work, communicated, adapted and made the team stronger. The team has added what they needed to improve the whole.My guess is that this team will grow in experience and will become better and better. Probably use some automated testtools to do the regression faster and even more accurate.( which is most important as you already explained).
    Here we had some simalar issue’s now we as the testers in the team, can run our own deployements, which reduces waiting time by over 1day . Use to be 1 day now its 1-2mins. And so on..

    So the answer to your Q = Yes Agilty and complex projects are friends, heck they are Best friends for ever !!

*Opinions expressed on this blog reflect the writer’s views and not the position of the Sogeti Group