Bloggo back to the blog
Mark Robinson’s Community Choice Submission-->
Presentation Title: What does Lean mean for Software Testing?
Traditionally, software testing occurs after the software is written. From a Lean perspective, this is waste because the software needs to be reworked, retested and often reworked again. Instead, Lean says that quality should be built-in to the way of working.
This presentation will explain how the seven wastes of software development (partially done work, extra features, relearning, hand-offs, task switching, delays and defects) apply specifically to software testing. It will then focus on how the last two can be prevented; delays by using Value Stream Mapping (using a specific example of a defect found by a customer) and defects by regular automated smoke testing and Test Driven Development. Use will be made of entertaining, interactive examples and stories from real life experience.
The conclusion is that traditional ways of measuring test effectiveness, e.g. defect detection rate as a function of defects found by the customer compared to defects found by the test team, are outdated. Instead, the total number of defects found (not just external but also during the internal test phase) needs to be measured and minimised. Each found defect should be translated into an automated test
case to ensure it cannot re-occur: “mistake-proofing”.
Recognise waste so that you can eliminate it: understand the Seven Wastes Use Value Stream Mapping and Kanban to speed up the whole software process, including testing Build quality in up front instead of mainly testing built code.
Lean is all about speed: how can we get the solution to the customer as fast as possible? To increase speed, we need to stop doing activities that do not add any value to the final product – which Lean defines as waste. Things like:
• having lists of work in progress (large defect databases, anyone?),
• adding features nobody will use (and, as testers, having to test them all for each release),
• multiple departments all solving the same problem, all “re-inventing the wheel” without effectively communicating lessons learnt,
• people all working on a part of the solution, playing a “Chinese whispers” game as the requirements move down the value chain and tacit information is lost,
• working on multiple tasks simultaneously, in which time drains away as people mentally switch between jobs
• waiting for people and test systems to become available or decisions to be made and
• making and solving defects, which requires a “hardening” of software via multiple test runs.
Lean helps us by providing tools to identify and reduce waste. One very powerful tool is the Value Stream Map, where a process of delivering value to the customer (feature or bug fix) is mapped out and the lead time is plotted against the effort time. How efficient are our processes, really? Another is Kanban, which forces us to work within the constraints of our available resources and ditch the “wishful thinking” which so often characterises our planning.
As testers, I see our role changing dramatically, from being people who test after the software has been written to people who are actively up-front building quality in, together with developers.
I have already spoken on this at the AgileMinds and SIGiST conferences last year. But I’m learning much more all the time and I’d like to present my latest insights in applying Lean software development to testing at EuroSTAR. For most people, this will be new material explained in an entertaining way with demonstrations and stories, and maybe the odd joke.. Most importantly: I will be describing real world solutions that you can implement the day you return to work.
Mark Robinson passed ISEB Practitioner in Software Testing with Distinction and has had software testing and test team lead roles at various companies. He has also coached junior and senior testers and written software testing articles for Bits & Chips and Computable.
Mark is strongly interested in making testing more effective by using various techniques like Test Process Improvement, internal company wikis and especially Lean Software Development. Mark works for TMC.