Here is my slide deck from my talk at the Software Testers Atlanta Conference. It was lots of fun to deliver it. Full, engaged, room (even though it was on of those dreaded post-lunch slots!), good questions, good laughs. It was also refreshing to do a US conference without checking into an hotel not to say a 12+ hours flight… (One of the advantages of living in Boston …)
Thank you for the conference team for inviting me! always fun to visit Atlanta (and have some BBQ on the way back to the airport…)
I recently had a couple of weeks with a few activities related to “Agile Testing”. “Agile Testing” for those not familiar with it is the name we give to the set of thinking guidelines, principles and practices that help run the testing aspects of product development/maintenance in a more effective way under an Agile delivery approach.
A question that came up while presenting the concepts today at a client was “What’s broken? Why do we need this?”. While my presentation covered some of the rationale the question made even more clear (not that I needed any convincing…) that the guided evolutionary approach to improvement is a winner. If they don’t yet feel the need/pain there is a lower chance they will do something about it.
The question comes up – why don’t they feel the pain? Or alternatively, maybe they feel the pain but don’t associate it with the need for “Agile Testing”.
So I wanted to briefly touch on a few questions/indications that you might need to pull ideas from “Agile Testing” as your next improvement step.
Some indications you might need to look at “Agile Testing”
- You applied WIP Limits and testing is becoming a bottleneck. Not once or twice, but quite consistently.
- You agreed to include test automation as part of the “Definition of Done” and you are seeing a queue building up meaning the automation is slowing the entire process down, creating significant slack for the people NOT doing automation.
- You find a lot of defects which send you to rework technical design due to lack of mutual understanding of the functional requirements / stories, or you find yourself leaving things ugly since there is no time to do the rework – earning you some customer feedback that you are not really providing high quality deliverables.
- You are not able to run a very granular flow – everyone claims smaller stories are not useful since the overhead to deliver them to testing and test them is so high. Let’s just keep using bigger items and deliver to testing not more than every 1-2 weeks.
- People feel that the test automation approach you have now doesn’t cut it. The total cost of ownership / lifetime costs are very high, and even though people understand the need to have automated coverage in order to integrate often, they are very frustrated by the costs.
- Testers are confused. Do they need to be automation specialists? Domain experts? Technical experts? Supermen? In this Agile Whole Team approach where there is flexibility and collective ownership – what is their unique value? what should they focus on?
My latest presentation touches on some of the reasoning why these issues come up when going Agile, as well as introduces how “Agile Testing” can help. For more about this you are welcome to join me at one of the upcoming Agile Testing workshops AgileSparks runs in Israel and Europe. Contact us for more information.
If you didn’t have the chance to see me talk at LSSC11, you can check out the video over at the LimitedWipSociety WIKI.
More videos are available to LSSC members – anyone interested in Lean/Kanban/Systems Thinking should seriously consider joining and checking those videos out!
A couple of months ago I ran into Think Testing – a new magazine for testers in israel (published in Hebrew).
I found it very interesting, and decided I want to contribute.
My article has been published in issue number #3. It tries to provide some insight on the experience of a tester when his organization/team decides to go Agile.
(Update: article no longer available in original location so use slideshare now)
I also like the design work they are doing for the magazine. It has a real professional aura.
Let me know what you think.
UPDATE: An english translation is now available at slideshare
The Lean Software and Systems Consortium US-based community conference will be May 3-6 next year, in Long Beach California. I'll be there, talking about "Using Kanban and CFD to effectively manage Agile Testing"
For some initial ideas in that area you can checkout earlier blog posts as well as http://www.slideshare.net/yyeret/using-kanban-and-cfd-to-effectively-manage-agile-testing
The Lean Software and Systems Conference is the Kanban conference for North and South America in 2011. This is where the community gathers and is where you will get the first chance to see and hear the best new material.
Are you also interested in presenting a case? The Call for Papers and Registration are now open. The CfP Deadline is Dec 19th and will not be extended.
Use #LSSC11 to join the twitter before, during and after the conference!
Hope to see you there!