English | EN Agile (testing) – the final solution?
Feb 13, 2014
I am not sure about that! I think our clients – the business – will expect more of us in the near future. The World Quality Report 2013-14 found that 46% organizations don’t have a specific approach to testing in agile projects. They are adapting testing methodologies based on waterfall development models. And as many as 87 % of businesses in the Nordics report that they are using agile, but larger companies are typically seen to implement only certain elements of agile and experience greater difficulties adapting their processes, methods and people to the agile ways. We have to dig in to these challenges and find solutions for the areas not adapted by the companies.
Since Agile Manifesto was written in 2001 we have learned that an agile environment gives the project members more responsibility, more challenges and interesting days at work. More fun at work! According to Everett M. Rogers’ adoption curve, we have reason to believe that we only have the laggards left in waterfall methods in the Nordics, and they might wait until the next big wave comes?
Figur 1 Everett M. Rogers 1963 – Relationship between types of adopters classified by innovativeness and their location on the adaption curve
For us testers, agile environments are an advantage compared to the traditional waterfall projects. The developers have not used all the money and time when we get something to test. However, agile environment in its current form is not the final destination. We can – and must – be even better. The clients expect us to deliver measurable improvements in quality, faster time-to-market, cost reduction and more efficient IT operational processes. There are some challenges in the development process which will force us to improve our development and test processes.
No fault forward
The majority of the projects are planning with sprint tests with good test coverage. In theory this should lead to less testing in the system (integration) tests. If it is a large project, responsible for developing one or several complex systems, it turns out most often that it is difficult to divide up the product backlog between the sprint teams. The consequence is that the sprint teams have challenges to deliver something that is testable at the next test level. We have learned that it often ends up with large tests at the end of a project (with a lot of integration defects between components developed in the sprints). This leads to overrun, delay and not the expected product quality.
The product owner seldom thinks like an IT-engineer
The client starts up a project because they want to achieve business goals. All the important goals are divided into items in the product backlog – functionality they expect us to deliver. The product owners are often very competent in their field, and in the projects they end up being busy prioritizing requirements and providing the development team with a lot of clarifications. I believe they feel that they are more involved in an agile environment, but at the same time they have been given more responsibility for the success. How can they keep track of all the items in the product backlog and at the same time keep an eye on the business goals? Have we given them the right tools so that after the project they can report back to the stakeholders that the projects achieve the business goals, expected ROI, manageable risks, and right product quality?
What’s next?
We have made significant progress in the way the development team works. We work in a much more solid way than before. Now we must look beyond design and development.
We should focus on the Product Owner and the organization around and give real support to the important role of the Product Owner. For example, we should implement better management reporting with relevant information to the stakeholders. A good start is to respect that the business team are experts in something else than software development team. Instead of waiting for the business to adopt our way of working we need to change ourselves and find new ways to collaborate with the business, especially in the requirement and design phase. Good examples are clear quality gates and more use of Model Driven Development (and model based testing), virtual prototypes and testing, and simulation testing.
References:
- World Quality Report 2013-14
- Rogers, E.M. (2003). Diffusion of innovations (5th ed.). New York: Free Press.
About the author
