Weekend Testing: Defocusing
Note. Don’t expect a complete and consistent blog post. Below are my notes put down while exploring the subject.
I have been participating in the Weekend Testing movement for almost a year, since Michael Larsen opened the Americas chapter. I enjoyed both tester-on-a-mission and facilitator roles. As a co-facilitator I planned and prepared a few missions. I posted session reports and wrote about wide spectrum of experiences participants are gaining. For the most part, that was about personal learning and experiences. Now I’m putting the look from the outside (how I see it, you’re welcome to add).
- Weekend Testing makes (and it’s fair to say – has made) the community of passionate testing professionals stronger. Participation in sessions and paired testing brings us together. It’s not only about practicing new testing techniques, it’s also learning about each other.
- Weekend Testing has become a training ground to try out new ideas. Those, who were hesitant and/or blocked to try a new approach or technique at work, now have support and feedback from likeminded testers. But it’s not limited to test ideas only. There’s a lot one can share with programmers, business analysts, and other project members at work. Take mind maps as an example.
- Any tester is welcome to offer his/her product (if it’s publicly available) for a Weekend Testing session. Of course, any product owner can do that as well, – and there are more than a few examples of success of such sessions.
- If you are a hiring manager and a hands-on tester at the same time, you can conduct a ‘field interview’, and then debrief your candidates. That might not cover involvement of the all skills you’re looking for, but candidates will have a chance to demonstrate the most important – exploratory testing skill – in action. It’s quite possible that such a session format will be more common the more hands-on testing managers will be.
There are, however, some areas not really covered (or, at least, not well covered) by the current format and structure of Weekend Testing sessions.
- Approaching tasks with bigger than “simple” complexity. A vague definition, yes, but think of it as something like a “one-step”, or “one-problem”, or “one-concept” thing. The 2 hours format dictates that. So for bigger tasks it’s either focusing on one small piece or an introduction.
- Transparency of the process and visibility of results. If you have not participated in the session it’s unlikely you can learn the same what participants learnt. Chat transcript is of little help, and experience reports are not always available. It’s even worse with testing results. Even though some bug reports are available, the whole everything that was learnt through exploration of the product is getting lost.
- Teamwork scale. Weekend Testing sessions are facilitated but not organized. Participants have all the freedom of engagement on the same mission: some stay in a passive observer role and some actively pursue the mission. Typically, everybody acts on their own, with some exception of paired testing. All this is perfect for learning missions, where duplication of effort brings a benefit of diversity. However, for a product testing, exploring different areas and sharing the information learnt would mean a team work.
One response to "Weekend Testing: Defocusing"
Good to see you educating others about WeekendTesting. Let me share this blog post with my network. *Thumb up*.