Assurity’s Aaron Hodder reviews the second Wellington Tester (WeTest) Workshop on “Applying Lean Principles to Software Testing”
With 16 testers attending this second WeTest on 6 December at the Conference Centre, St Andrews on the Terrace, I opened the Meetup with an introduction to the topic. I then presented an experience report on how I apply Lean principles using mind-mapping software to model the software testing effort, as a learning tool, and as a tool to communicate the testing story to give the entire testing effort a degree of structure, visibility and accountability.
To recap, here are the seven principles of Lean software development:
• eliminate waste
• amplify learning
• decide as late as possible
• deliver as fast as possible
• empower the team
• build integrity in
• see the whole
I think the biggest threats to Lean systems testing are the way documentation is traditionally produced and the prevalence of pre-scripted tests.
I proposed an alternative using James Bach's Heuristic Test Strategy Model as the skeleton for a visual model of the software under test. By using this skeleton to ask questions and as a prompt to learn more about the application, I build a model of the application under test. By presenting the model in a one-page format, learning is amplified as my current understanding of the project is transparent for all to see.
I then went on to demonstrate how testing coverage can be communicated, how the rationale behind test cases can be shown and how testing transcripts can be given context... all in one map.
The beauty of LAWST-style meetings is that the presentation is just the beginning. Attendees are then free to question, criticise and debate in a facilitated manner.
The first topic to be debated was that of management accountability. If your managers are required to report higher up using metrics in specific formats, how can you provide that in a Lean culture? I talked about how I surreptitiously used mind maps and session-based test management, gradually exposing management to these outputs until it became their preferred format. I also proposed asking management what story the metrics were telling and whether the story could be told in an alternative way.
One participant mentioned that they are required to produce massive amounts of documentation to meet a CMMi level. I suggested that one strategy could be to use mind-mapping as a tool and to then export the content to create documents in the required format.
The discussion then turned to test matrices versus mind maps. I illustrated how the same testing situation could be expressed in a test matrix or in a mind map and why I preferred the map approach as it’s easier to see the rationale behind test conditions. I also acknowledged that there are situations where a traditional test matrix might work better.
After the break (during which the discussion had continued), we broadened the topic into other issues around Lean.
Test scripts came up, questioning why they were so often requested or even expected. We concluded that the secondary properties of test scripts produce the most value – for example, as a conduit for the transfer of knowledge of the project, a guide for automation or as a record of what has been completed. We then explored leaner methods for achieving the same outcomes.
Another enjoyable and stimulating night and a great opportunity to meet and learn from other testing practitioners in an open forum.
Thanks to our sponsor Assurity for the venue and refreshments and for ensuring that the workshops remain as accessible to testing practitioners as possible.
The next session will take place on 7 February and will be on the topic of Test Planning.