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.
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.
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.
3 comments:
Thanks for sharing this Chris. It sounds a lot more hands-on than the RST course and the idea of building a portfolio of re-usable, presentable material sounds good. Find me on the course in the near future I reckon!
Hi Simon,
RST (rapid software testing) is the basis for the RTI - so you'll briefly cover RST materials, ideas, etc. in the lecture and then put them into practice with the exercises. It's a lot of fun.
Hi chris,
Thanks for sharing about RST.
Would like to read the series of blog posts.
Post a Comment