During the Agile Testing Days 2010 in Berlin I attended a presentation of Marcus Gaertner. He mentioned Testing Dojo in his session. I already heard the term Coding Dojo and was already interested to find out if it is possible to set up a Testing Dojo. To find out, I first started to find out what a Coding Dojo exactly is. I wrote a short memo about this and here is the result…. If you think I forgot something in my description, please leave a comment!
In a next blog I will try to describe how I think a Testing Dojo could be organized. Marcus already wrote a excellent blog about a testing dojo. I will refer to this blog about what a testing dojo is, what you need and how to organize is.
This blog is based on the following resources:
- http://web.cs.wpi.edu/~gpollice/Dojo.html
- http://codingdojo.org/
- http://en.wikipedia.org/wiki/Randori
- http://en.wikipedia.org/wiki/Kata
Some other interesting links are:
- http://confluence.agilefinland.com/display/af/Coding+Dojos
- http://www.shino.de/2010/06/04/xp2010-testing-dojos/
Introduction
Testing is a skill, to become a master tester you need experience. You increase your experience by doing your daily work as a tester. Every day you will encounter new problems where you need to apply your existing knowledge to solve the problem. When the problem is solved, you have increased your knowledge and experiences.
To increase your knowledge as a tester you should meet with other testers. When you share your ideas of testing with other testers you will receive feedback. Feedback that makes you think about your testing approach.
It is your own responsibility to become an experienced tester. You should take initiative to grow as a tester, not wait until someone delivers the knowledge to you.
A testing dojo combines the things described above. You actively work on a challenging problem, meet with other testers and take your own responsibility in becoming a good tester. In the sections below I try to describe what a Dojo meeting. It is a introduction for people who are not familiar with a Dojo meeting.
Dojo
A Dojo is a place where people come to improve their skills. Most common is a Coding Dojo. As important as improving the skills, it should also be fun!
The idea is people meet for a time boxed period, with a computer attached to a beamer or desktop sharing tool installed and a challenge. What kind of challenge will be discussed later. During the session the group works on the challenge. Remember it is time boxed, when time is up, the Dojo ends.
In a Dojo everyone is equal, there is no difference because of experience. A junior person could learn from an experienced person and an experienced person could learn from the fresh look of a junior person. Everyone should be respected for their knowledge and contribution to the Dojo.
The idea of the Coding Dojo comes from Dave Thomas’s idea of Coding Kata. Laurent Bossavit’s instituted a Coding Dojo in Paris where it has been running on a weekly basis since January 2005. It has been a weekly programming get together where programmers of varying skill levels meet as equals. The Coding dojo is not dependent upon any specific programming language. Often one person may exhibit a solution to a challenge one week in C++ and the next week, another member might solve the same problem in Ruby or .Net. The goal is to learn.
Forms of Dojo Meetings
There are two types of Dojo meetings, Kata and Randori. The description of both words according to Wikipedia:
- Kata (型 or 形 literally: “form”) is a Japanese word describing detailed choreographed patterns of movements practised either solo or in pairs;
- Randori (乱取り) is a term used in Japanese martial arts to describe free-style practice or sparring, sometimes with multiple attackers. The term literally means “chaostaking” or “grasping freedom,” implying a freedom from the structured practice of kata.
A Kata Dojo is session where someone solves how to solve a problem. The presenter thought about the problem in front of the meeting but did not do any work. In the Dojo the presenter creates the solution whereby everyone is able to see what the solution is. Every step the presenter takes should be clear for everyone, as soon as it not clear it should be explained to the group. During the Dojo the group should comments on the solution with the goal to improve the solution. In the end the group, including the presenter, should have the best possible solution with the knowledge available. It is wise to have some breaks during the Dojo to discuss in smaller groups the possible solutions.
In a Randori Dojo the whole group participates in creating the solution. By using pairs, two persons are constantly working on the problem. Every pair works time boxed, for example seven minutes. When this time box ends, the person (driver) who was controlling the keyboard and mouse, goes back to the audience. The person (navigator) who was thinking out loud and reviewing the work of the driver, becomes the driver. A new person from the audience becomes the new navigator.
Rules of Dojo
There are some simple rules you could follow when organizing a Dojo. It is wise to shortly evaluate every Dojo when it’s done and change the rules if necessary. There is always room for improvement.
Positive comments
Goal is to learn and everyone is equal. Try to give positive comments, it should be focused on improving.
Slow Down
Everyone should be able to follow your steps. Don’t rush, make sure everyone understands your steps.
Interrupt when it is not clear for you
When you see something happening what you don’t understand, ask a question.
Think out loud
The presenter or pair should think out loud. The group is not able to anyone’s mind. Therefore, explain what you are doing and why you are doing something.
Agenda and Facilitator of Dojo
It is wise to assign a facilitator. The facilitator should create an agenda and if necessary prepare the room, computer, etc. Make sure the agenda has also a time table, a Dojo is a
During the Dojo the facilitator should make sure the rules are followed. It is up to the facilitator to decide if he also would like to part in the Dojo.
An example agenda:
- 2 minutes: decide on date for next session;
- 30 minutes: solve the problem;
- 5 minutes: mid-session break to discuss how things are going;
- 30 minutes: code some more;
- 13 minutes: quick retrospective of the session.