In the previous part of this 2-part series, we identified how taking a Lean approach to testing can highlight various wastes that testers face in a project team, and external wastes that end users deal with. This concluding part will identify some solutions that can help with reducing the three types of waste, Muri, Mura and Muda and how continuous improvement can lead on to creating value for the customer.
A Lean Approach to Testing - Part 1
In the first of this 2-part series, we will look at the various inefficiencies that are faced by testers in a project team, and for the users of the software that we are helping to deliver.
No Time to Waste
You have probably heard of the 7 wastes (or 8 or even 9!) which focuses on reducing anything that does not add value within a system. This concept was developed at Toyota relating to manufacturing and later applied to software development practices in 2003.
Where is the Value?
As we know, we cannot test everything. This is especially true for End to End testing. This activity is often carried out at the end of the Implementation phase after System testing has completed. There will be many paths through the software and to test them all will be a large task. So only critical paths are tested through the system that provides an acceptable level of test coverage. Add automation into the mix, and this can become extremely challenging at the end of the delivery cycle. Teams often accept that the effort required for automating the End to End tests is too much of a risk to a timely delivery. Often, it is cut down to small manual End to End tests as an afterthought that adds little value to the overall quality or post-release teams. Ironically, this is where it adds the most value!
It all starts with Quality
Testers do not just “do testing” in an Agile team and have many roles to play during the delivery of software. Testers are fully involved in the development lifecycle, meaning quality starts from day one. Although everyone in the team is responsible for quality, the test team tend to drive this and lead by example to promote good working practices, as well as being at the forefront when identifying product risks.
Within any software development team, testing involves investigation and analysis to identify product risks. Testers also provide information to stakeholders about the quality and complexity of testing so confidence levels are well understood. Depending on the methodology used, the success of a release may be largely based on the effectiveness of the test role.
In traditional methodologies, testers mainly contribute to delivery at the end of the process. If the testing phase only begins after analysis, design and implementation phases have been carried out, adapting to change becomes more difficult. Major issues found during this phase are usually so embedded, they are too risky to rework. If budgets and time pressures are a factor, it is always testing that suffers. Producing a high standard of testing becomes more and more challenging, and the blame culture starts to set in.
Working in this way can cause communication issues between business analysts, developers, and testers where requirements are often misinterpreted. Siloed working in these phases can lead to an over the fence attitude, wasted effort and a lack of involvement in decision making. These cause motivation and frustration issues for the testers involved.
The idea of delivering software in small, prioritised work items is to maximize value to the customer as early as possible. But things change. Customer expectations, difficulties with technology, new requirements, and changing priorities are all real complications that must be tackled on a regular basis.
Short feedback cycles are vital so testers can react to ever-changing demands. Collaborating with business analysts, developers and stakeholders is the best way to make sure any re-planning is turned around quickly and efficiently, reducing waste. With better visibility of progress, gives time to plan for the feasibility of automation, non-functional requirements and test harnesses. This adds robust quality attributes, prioritised depending on their business value.
In an Agile team, the tester role is utilised across the whole software life-cycle. Testing starts from day one of the project, and provides a platform to drive quality and influence team members to think likewise. Thinking from a customer point of view during refinement, the test focus includes asking questions, thinking about UX, personas, risks, impacts, workflows and testability early on when there is still time to change things. Being part of requirements analysis from conception ensures test planning is based on a concrete understanding of specifications, dealing with any ambiguity to avoid future rework.
What makes Agile work?
One of the benefits of Agile is that it is easy to adopt, in principle, if you were to implement the rituals and follow the rules. Frameworks like Scrum or Kanban have been provided. However, product maturity, dependencies on other teams, or even company politics means a templated approach does not suit all.
Of all the Agile manifesto points, the key to making it work well is people over process. Each team has different personalities, skillsets, and specialists, which is why no two projects should be run or compared the same way. Agile gives the flexibility to create a working atmosphere where everyone adds value. It is the people that make Agile successful, not the rituals and processes.
The goal is to build a culture that centres on collaboration and teamwork where everyone is responsible for quality. It takes away feelings of blame, pressure, and isolation that testers have frequently been the victim of in older methodologies. The experience of working together in synergy, creates an extremely slick and efficient team and testers thrive in a situation where there is respect and can contribute as equals. This results in the team analysing business value rather than testers trying to gain confidence in a squeezed time frame.
For an Agile team to evolve requires trust. Things always go wrong during the project and people make mistakes. The important lesson is in how issues are dealt with. Empowering the team to learn from their own mistakes is rewarding, allows individuals to encourage each other and improve on estimates through experience. It is possible in a self-organising team, and works well when there is no micromanagement or multi layered hierarchy.
Good testers love to learn. It is the basis of why we have a passion for testing. A self-managing and helpful team where everyone is working towards the same goal is a great motivator. Investigating and learning together with developers, and bouncing ideas against business analysts and other testers ultimately help to mitigate risks and reduces the overall cost of defects because they are captured and fixed much earlier during the development life-cycle.
Modern Agile teams are focused on continuous integration and continuous delivery models. Multiple changes and quick turnaround of defects require testers to be at the centre of decisions. Testers are best placed in a project to understand overall changes and impacts, so reporting risks and test coverage to the business is a benefit for both testers and stakeholders.
Business value in an Agile environment does not just include customer requirements. Creating a lean and efficient team helps to release within budget, allowing time to plan in knowledge transfer, self-learning and training. This investment improves knowledge that can be applied to future projects, and provides a longer-term benefit to the company without compromising delivery.
This is good news for testers developing a T-shaped skill set - the capacity to work across multiple disciplines while specialising in one core skill. Since Agile working is fluid, testers need to be flexible enough to switch between a logical and creative mindset. Product knowledge gained through rapid test feedback and continuous self-development ultimately increases software quality. Exactly what Agile and Testing both aim to achieve.