Now that I know a little about Agile and a little about Lean, I can try to apply the concepts to Software Testing.
One key ‘lean’, or ‘TPS’, concept covers ‘muda’, or waste. Over my years in Software Testing I have tried to make my testing processes more ‘Agile’ or ‘Lean’, but when I started I didn’t have the concept of ‘muda’, I just had the knowledge that things weren’t working, so I changed them and got rid of the things that I thought added no, or little value. Now that I know a little about Agile and a little about Lean, I can try to apply the concepts of ‘muda’ to testing.
The 7 types of waste
- Overproduction
- Waiting
- Transportation
- Inventory
- Motion
- Over-processing
- Defects
Overproduction
The production of ’things’ before another process requires them. This seems like the very definition of a scripted testing process. From my experience as a scripted tester, when I held the belief “all tests must have scripts”. I indulged in this form of waste as a standard practice.
Overproduction led to a lot of Inventory and Inventory led to Defects in the scripts because the system under test would obviously change as its development team continued to construct it.
One method of countering overproduction involved not writing test scripts. Instead I made sure that I learned how to use the system and exercise it in such a way that I could cover the test ideas that I created. I found that I could document my understanding using models and diagrams instead of sequential lists of steps.
I still created Inventory, represented by a lot of test ideas, neatly categorised and cross referenced to documented requirements because our test process led to a lot of Over-processing. As a tester I created a lot of documentation that languished un-read, because I believed that I had to tell my ‘customers’ as much as possible, rather than as much (or as little) as they needed to know to help them make a decision.
I found that the test teams I worked on had rhythms where we would end up Waiting (for requirements and specifications, environments and systems) and then there would erupt a flurry of overwork where we had too much to do on the delivered ’thing’.
Transportation Motion
These resonate less with my memories of software projects but I do remember having to move test cases, defects, metrics etc. from test tools into ‘reports’. (Sadly reports which generally went unread)
Some strategies that I have used to deal with waste on test processes:
- Automatically generate reports and metrics
- Automatically generate test scripts from models
- Automatically maintain cross references
- Stop writing test scripts
- Writing clear high level ’test ideas’
- Cut down report contents to the important points
- View my ’test reports’ as tools for me so that I gain value from them
- Talk people through ‘diagrams’ rather than writing a report Strategies in response to a process that for one reason or another I couldn’t, or didn’t believe, that I could change.
‘fear’ drove some of the wastes:
- Testing will get the blame if we ‘miss’ something so we need to document everything and get it approved
- We have to caveat our test plans and get them ‘approved’ so that people can’t override us later
- If I don’t write a script I might not cover all the ’things’ I have to cover when I execute the ’test’ Some of things these ‘fears’ tried to protect me from happened anyway and resulted from the ‘relationships’ in place. I now try to view the processes and people in place as a system and examine the relationships in that system on a project by project basis.
Unjustifiable ‘beliefs’ about testing drove other wastes:
- All tests must have a test script
- Test plans must follow the IEEE format
- Users must sign off on test scripts
- Testing need ‘complete’ requirements we start test design
- We do not test unstable systems
- Repeat all tests when the system changes
- Testing must remain ‘independent’ from development Most of the beliefs (and there exist plenty more I could list) seem like excuses for not thinking and identifying the most relevant approach to my particular environment.
‘Chances are’ you don’t need to know the 7 wastes, you just need to listen to your gut and the unease which you feel for your current process and approach and take steps to reduce that unease.
‘Chances are’ you just need to look at the ‘value’ that each of your documents and processes add to the overall development effort and cut out as much as possible those that add no, or little value. If, during your analysis, you end up as the only identifiable person getting value from the ’thing’, then make sure you produce just enough to maximise that value.
