Dojo? What is a Dojo?
Dojo (dōjō (道場, Japanese pronunciation: [doꜜː(d)ʑoː]) is a Japanese term which literally means "place of the way". Typically, it is considered the formal gathering place for students of any Japanese martial art such as karate, judo or samurai, to conduct training, examinations and other related encounters.
So, what is a Testing Dojo?
A Testing Dojo is a meeting during which testers come together to work on a testing challenge. The testing challenge can consist of testing a product, generating test ideas for a particular piece of software or even doing a bug-reporting exercise. It’s testing without schedule pressures or deadlines. A way to train testers new to the profession in a collaborative manner.
Testing Dojos help your team gain a shared understanding of its approaches to testing. New testers can directly see how a more senior tester would tackle the program, while a more senior tester can get new insights from the fresh perspectives of the rookies. A Testing Dojo conducted with project managers and programmers can bring transparency to the testing process.
Why I am writing about this?
Because we had a testing event here within the MTech group, where our QA Lead, Jakub Kmínek, prepared a testing riddle for us. He chose one website that we needed to walk through to try to find bugs and dysfunctionality.
So, it was not exactly educating new testers, but showing the rest of us the kind of magic the QA team does on a daily basis.
We had a specific web page to investigate. Then we had to agree where to start, what makes the most sense to investigate first, etc. As a team, we found around 10 areas in which we wanted to focus within the given time of one hour. We sorted them from most important to least important and started testing.
We had rotating roles of tester, recorder or co-pilot and observer. The tester had 7 minutes to test his or her part. They were saying out loud what they were testing, why and what they found. The co-pilot was taking notes and reminding the tester of the objectives of the session. When time was up, people switched roles: the co-pilot became the tester and a new co-pilot was selected.
Jakub was the observer all the time and took notes. After the hour was up, he summarized from his professional point of view what we could do better or what surprised him that we did well.
I think it was a very useful event. Not that we would learn how to do QA, but to get an idea of what our colleagues are doing, how much time testing can take and what the obstacles are that they have to face.
I believe, also based on the team’s feedback, that every participant found this meeting beneficial, and we all agreed that it would be useful to have a similar introduction to other teams as well, or at least to tasks that are possible to demonstrate in such an interactive way.
I am really happy that I could participate in this event and that Jakub had the time and patience to guide us through it.
I think that I can publicly write here that we would welcome more events like this, so if you would like to prepare one for us, please do.
Have courage and be kind.