In February I attended an online training course where participants test a software product using the Rapid Testing methodology called Rapid Testing Intensive (RTI) Online taught by James Bach. I found it to be a great way to test a product, get feedback on your work, build a software testing portfolio and learn about the Rapid Testing methodology.
Last July I took a similar in person training course appropriately called Rapid Testing Intensive Onsite. I meant to write about my experience but never did so allow me to describe it now:
The onsite version was an intense four and a half days of lecture, learning, testing and other team activities. From survey testing, to group stand up presentations, to the occasional after hours (with beer in hand) dice game it was a week of mental challenges with quite a bit of fun mixed in. After some encouragement from a few twitterers I shared my notes in the form of a live blog: (day 1, day 2, day 3, day 4, day 5).
During that time I was the “lone tester” in my company and taking a week to work on a team with other testers from around the world was a welcome change and an enjoyable experience. When a team member found something interesting or became confused the rest of the team became involved in the discussions which lead to new ideas about where to test. If someone didn’t clearly understand something someone else in the group could help. All this team work lead to some exciting discoveries.
Coming back to my original story I can do a little bit of comparison:The online version was much more concentrated than its onsite counterpart but maintained all of the important aspects with an opening lecture, followed by a 90 minute testing assignment and then a break. During the break James would do the assignment himself and when the participants were back he’d show what he did, explain his approach and then review the work of those who were brave enough to ask for it.
Asking for your work to be reviewed live (webcast) can be a little intimidating. I remember doing the stand up presentation for my group onsite and I made a lot of mistakes in front of others but the result was I learned about safety language. This time around I knew mistakes would mean I’d learn more so I didn’t hesitate to ask. After the feedback session there was a little more lecture and then the day is done. This was the schedule for the rest of the course except with each day the assignments build off of one another and get deeper into the product.
Having essentially taking this course twice (first onsite, second online) my approach was to focus on understanding the assignments while also building examples of my work that I would be proud to share afterwards. I used James Bach’s Heuristic Test Strategy Model to generate ideas for covering the product we were testing that would go into my Product Coverage Outline. Through both experiences I got new inspiration / ideas on how to organize and document my deep / combination testing. I played around with the way I take notes and continued to experiment with a method James calls concise documentation (however I prefer the catchier term “lean documentation”) which means there should be no fluff in your documentation, just the important parts.
Perhaps the most visible output from the RTI online are the work examples you build while documenting your testing – the Product Coverage Outline, deep testing matrices, testing notes, etc. These documents, after some cleaning and framing, will become the basis for my software testing portfolio – a public example of the work I’ve done and am capable of doing.
Not so visible are the truly important parts from the RTI online: learning about testing and deliberate practice. After all you can only get better at something if you practice it. Rapid Testing teaches us how productive and exciting testing can be by focusing on personal skill and the thinking part of testing. In my experience testing has always been about documentation (think test cases) and not about thinking / questioning what needs to be done. Every time I’ve taken a course in modern software testing practices (like RST) I feel like I start to understand more of the things that effect what I do and I start to question the assumptions involve. With the RTI I get to learn and practice which makes me feel like I’m growing and getting better.
I’ve found the product of those learning experiences, of the direct feedback to my work has improved how I test at work and how I view my product and the value of my labor. I’m not satisfied with where I’m at now, I might never be, but I do understand how far I’ve come and how far I have to go. See you at the next RTI.