Challenging areas in Agile testing maturity

First posted on the Polteq website.

A couple of years ago, I had to assess the testing maturity of a company that was practicing Agile/scrum. The maturity model that I needed to use was TPI Next. At the end of the assessment the model showed a lot of areas for improvement. The improvements that would result in a more mature organization according to the model, would in my opinion not benefit the organization. So why did my opinion and the model differ so much? The reason was the Agile/scrum context. The model steers an organization to more structure, where Agile/scrum asks for flexibility. The context of this company required a different view on what needed to improve. That’s when Polteq decided to put effort in creating a test improvement model for this specific context: TI4Agile .

Since the introduction of TI4Agile a couple of years ago, it has been successfully applied many times in different contexts. I have analyzed the results of these assessments and found common challenges with Agile testing maturity that are interesting to share. It appears that many organizations have a low maturity in the following areas, which are a subset of the twelve key areas of TI4Agile:

• Test management
• Test process
• Test automation
• Interaction

Test management and test process share some problems in the transition to Agile development. Both areas were introduced into the traditional testing world to provide more structure to testing. The flexibility and adaptability that is needed in the current Agile context, requires large changes in how to approach test management and test processes.

Test automation has gained a more prominent role in the Agile context, to facilitate iterative and incremental development with fast feedback loops. The increase in importance is recognized by organizations, but often lacks professionalism. Therefore this area lacks maturity.

And last but not least, self-organizing teams require more and better interaction between the team members. Scrum facilitates the interaction in the different meetings that form the basis of the development process. To gain most value out of these meetings, the purpose of these meetings must be clear to all participants.  The team members must be able to switch between very technical topics and complex business situations.

In future posts I will dive deeper into each of the areas to provide more insight in the specific challenges of Agile testing maturity.

Advertisement

Testing needs to change

Abraham Lincoln once said:

“The dogmas of the quiet past are inadequate to the stormy present. The occasion is piled high with difficulty, and we must rise with the occasion. As our case is new, so we must think anew and act anew.”

To tackle the changes in the development processes, testing must grow along with these changes. The shift in most companies is from waterfall (or traditional) development to Agile development. To enable this growth, testing should go from an industrial, manufacturing model towards an agricultural model. You cannot predict the outcome of testing, you can just – like a farmer – create the conditions under which testing begins to flourish. Keep in mind that you can predict the outcome of a single test, but not of the complete testing process. To make testing flourish, you need to adapt testing to the context. In some settings it seems enough to reform your testing, but in most cases a transformation is needed.

I advise starting with a clean slate (transforming) over changing your current process (reforming). Aligning with the new context is easier when you are not bound by decisions made in the old context. Start off with thinking about what you need and not what you have! So what do you need? Your context can have a lot of (conflicting) demands, such as:

• Short time to market
• High quality
• Low costs
• High auditability

From these demands, look at efficient and effective ways to arrange your testing process along with the development process. You must not only find out when to test what, but also how this testing should take place. Do you still need the process driven testing, with testing techniques to get you test cases that can check if the product meets its requirements? Or do you need exploratory testing to validate that you built the right product? Or do you need both, or other approaches?

In my opinion you need to look at your product from multiple angles. So in your process, you should find a combination of approaches that best fits your needs. None of the approaches is completely wrong or right, they are just different. So why not try to take the best of all worlds?