18 August 2014

Using STWC to explain testing

When I explained STWC (Software Testing World Cup) to a friend recently, I realized that story actually encapsulated testing in a pretty good and concise way:

Well, the general setup was pretty easy: Each team had 3 hours to test a product, revealed just before the competition started. Throughout the whole competition we had people in charge of the product available on a live video channel so that we could ask questions and get valuable information from them as we were testing. Finally, before the three hours were up, we had to file all our bugs and send in a test report containing stuff like critical bugs, suggestions for improvements, what we had covered and so on. The winner was then chosen based on value from bug reports, the test report and how well we communicated with stakeholders. And value of bug reports was not our bug count but rather severity of the bugs, if the programmers managed to understand and reproduce the bugs based on our descriptions and so on.

Our team started out by just clicking around in the application, trying understand how it worked. In parallel we watched an introduction given by the product owner where he shared what he wanted us to focus our testing on etc. After doing this for a few minutes we stopped to share what we had learned, split up the work and briefly talked test strategy. When done, we started exploring, or well test, the product, stopping every now and then for debriefs to ensure everyone had a good flow. At the end we finalized the report, made some improvements to our bug reports and well, that was it.

To just briefly explain concepts like debriefs, touring, the importance of questions and communication, common artifacts/output, value from bug reports and how the process of testing actually (can) look like, is hard! Being able to put them into a simple context like this, seems to me like an efficient way and if something is still unclear I can just zoom in on that specific detail, for instance:

Hang on, what do you mean with test strategy?

Well, in the intro the product owner shared what parts he wanted us to focus on; the email functionality, screen resolutions and the possibility to "steal" other user's customers. The strategy in this case was: Is this enough or should we focus on something else? Any general ideas on how to test these things? Who does what? How do we use our time, like how often to debrief and when to start with the test report? Also, as part of the strategy, we set some roles to make sure nothing was forgotten; so Agnetha was responsible for our communication with stakeholders, I was responsible for the test report and Sofia was responsible for the quality of our bug reports. All and all a plan on what to do, roughly how to do it and who should do what.

My message with this blog post is: If you are to explain something complex, it often helps to find a simple context to apply it on. The story is like a picture, even when brief it can tell a thousand words worth of complex, abstract details.

By the way: Gerald Weinberg is a master when it comes to explaining complex concepts using simple stories. I do recommend his books if you wanna see this in full action (guess that's kind of an unnecessary recommendation as I seem to be the last tester to have discovered his brilliance)

No comments:

Post a Comment