Introduction to Lean Testing Principles

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.

Reducing Muri (Overburden)
This is unreasonable work that is imposed on people, the system and tooling.

Investing in people and tools, collaborating and being empowered allows more productivity, but encouragement from management and peers in the team is required. It really is a mindset change. Wellbeing is becoming more prevalent in the work environment too and must be taken seriously to avoid pressure and stress, so supporting each other will help to manage this.

Testers may find themselves either waiting for developers to pass work over to test, or the other extreme where multiple pieces of work have been thrown over the wall to be tested in a short space of time. Using a Kanban board to map the team’s capacity can be used to visualise the different stages of workflow from analysis through to done. This will highlight any bottlenecks in the flow of work - as long as all work is added to the list. Taking the “if it's not on the board, I'm not doing it” approach gives a real impression of how much work there is to do, so hidden or extra work is not committed to due to false reporting of capacity.

Using WIP limits for development and test will help to prevent team members from being overburdened, as new work cannot be picked up if the work in progress is already at maximum capacity for that stage. This means more collaboration and help between disciplines and peers and ensures that time is not wasted on work that does not add immediate value.

Analysis can also be carried out to measure productivity. Be careful not to use it to berate team members, as ironically it may be seen as micro-managing. Analysing waiting times, wasted time, throughput and rework time are useful metrics or KPIs that can be used to help improve efficiency and is on the road to continuous improvement. It requires openness and honesty from everyone in the team, so the end goal needs to be clear.

Reducing Mura (Unevenness)
This refers to the inconsistency and the irregular flow of work.

Creating short feedback cycles is key to improving the workflow, so for testers to be able to report information quickly and concisely is a skill that needs to be worked on to avoid wasting valuable time. Waiting for email replies or requests can sometimes be dealt with sooner by going to speak in person, using the phone or instant messaging to get quicker answers. Once the culture of the team changes, communication will move quickly and it will be second nature to work in this way.

Analysing how people think and learn is important from a Test Lead perspective, to recognise what motivates and drives testers. It can highlight an imbalance in team skills and may explain why people work at different paces or intensity. There are models such as Myers Briggs or Belbin, and some Neuro-Linguistic Programming techniques can help to build rapport but remember that these are just used as tools so should only be taken with a pinch of salt. Understanding this means that the right people can pick up the right work or highlight areas and objectives for training and self-development.

Standardised work allows consistent working for all testers in the team but remember that any process is in context to the project. It may not work to create the same processes for testers across different teams. Creating a definition of done can also be used to help the team be consistent with handing over and signing off work across the Kanban board.

Chunking work items up into manageable and deliverable sizes will give consistency on delivery and will become more predictable. Work hard to refine estimates or story points so that work is of similar size and complexity, rather than having some work that is quick, and other work that will take a long time to deliver. Smoothing out the rate of work will help to avoid the ‘hockey stick’ effect, where work starts off at a slow pace and then quickens as more pressure is added towards the end of the sprint or phase.

Reducing Muda (Uselessness)
This refers to waste by carrying out non-value-added activities.

If the test team writes test scripts, analyse how much time is spent creating them over how much time is spent executing the software, and think of this in terms of how much value each activity is adding, and who to. Scripts can become out of date quickly as development is implemented, so creating quick smoke tests and doing Exploratory Testing are good Lean ways to give early feedback and instant value.

Creating extensive automation scripts can be wasted effort - especially if the project is short. Utilise time by automating APIs and critical functionality and paths only. Think of it in terms of regression and maintaining the testing after go-live, as manual, creative testing is still a vital activity.

Part of the test role is to think like a user, and this works best if there is close contact with users and the UAT team. Ideally, all work should at least be demonstrated to the business analyst, but giving wireframes, screenshots and early builds to UAT or business partners on a regular basis will prove useful and will help to avoid rework or an unsatisfactory solution. This works well with delivering a Minimum Viable Product as the first release.

It is often highlighted in retrospectives that meetings can take too long, or some of them are unnecessary. Think carefully about who should be attending meetings and do not assume that 1 hour is the right amount of time just because it is the default in Outlook. Try 30 minutes meetings, and make sure the facilitator provides notes and actions for non-attendees. Reporting and metrics also need to add value, so it is important to understand from stakeholders why they require certain information, and what value it adds.

Continuous Improvement (Kaizen)
The idea of Kaizen is to improve standardised processes in order to eliminate waste, fix workflow issues, and solve business problems.

By taking the time to investigate the overburden, unevenness and uselessness that the project team can suffer from, it is possible to create stability and reduce waste. Making mistakes is part of this process and should be embraced as a learning exercise. It is important to reflect using Hansai, as this will help with further improvements through retrospectives.

There are many Lean review processes that can help to eliminate wasted effort and rework, many of them being familiar methods that are used in teams already, such as PDCA, 5 Whys, A3 Problem solving, and root Cause analysis. So, to think in a Lean way is not always such a big step in teams, but it does require consistent buy-in from all team members for it to work well.

Similarities with Agile
The Lean approach has some obvious similarities with Agile, and they work very well together. The point here is that labels do not really matter. As long as the team is focused on doing the best job they can with the resources they have, then continuous improvement will ensure that they are providing better value to customers.

If the model becomes too regimented, it goes against the people over process principle, and there is the danger that focus will be on the tool rather than the outcome. Secondly, the purpose is not to use the extra time to crack the whip, or to allow testers to take it easy - it allows efficiency to be built into teams to be more productive - more time for knowledge sharing, self-developing, contingency and fun, which are all required longer term success and wellbeing.