The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.
My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.
Suggestion #56: If it doesn't exist: Start a community of practice or other forum where you and colleagues can talk testing, share ideas/experiences and improve as testers together. - Erik Brickarp
Software testing is a skill. There are many components that go into developing that skill. A woodworker learns over time, with practice, and probably a knowledgeable mentor how to use a variety of tools (table saw, planing joiner, router, sander, lathe and a variety of augers/chisels, etc.) to make beautiful furniture. So it is with software testers and with testing. We need opportunities to work with skilled crafts-people, learn from their experiences, try out our own ideas, and see techniques in action. We develop skills with a variety of tools along the way.
Much is said about using tools, writing test plans, creating automation scripts, but if your experience is similar to mine, those metaphorical "guilds and artisan groups for improvement among your peers" didn't seem to exist anywhere in the vicinity of where I worked. Short of a patient co-worker or two, a regular forum to actually improve and practice testing didn't exist.
Fortunately, we live in a different world now, and such "peer learning" options do exist. I'm going to talk at length about one of them here... and I'm amazed I've been able to go this long in this project without directly referencing this as a workshop topic.
Workshop #56: Participate in sessions of Weekend Testing. Work with and understand the model. Learn how to facilitate session. Encourage others to facilitate. Create a literal or virtual Weekend Testing "chapter" and conduct your own Weekend Testing style sessions.
The truth is, there are a variety of ways that software testers can share their ideas, learn from each other, and help develop and model skill improvements in their testing. Hack sessions, lunch or after work gatherings, meet ups, etc. All fill this need in different ways.
The approach I'm going to talk about is one that's well documented, has a high level of learnability, repeatability, and portability. As long as participants have a network connection, it can be done anywhere, any time, with any number of people across many time zones and continents. It's the model that is referred to as "Weekend Testing", and yes, standard declaimer time: I happen to be an active proponent of the methods. I co-founded the Americas chapter of Weekend Testing back in 2010, and I am the "resident facilitator" here in the Americas, along with several dedicated individuals who likewise take turns facilitating sessions.
Weekend Testing is a movement. It is a global community. It is a model and a highly portable "process framework" that, after participating a few times, anyone could take the approach and run their own "sessions".
We actively encourage people to do this.
To get a familiarity with how things work, I recommend going to the main Weekend Testing site and review previous sessions we have run. For the most part, all sessions are roughly structured the same way. The principal individual(s) in a Weekend Testing session is the Facilitator(s). In most cases, saying that you will be a facilitator means you will be the one seeing the session through from concept to execution to reporting of results. as a quick start guideline, here are the steps that I go through each time I propose, plan, schedule, conduct, and report a testing session.
1. The session is announced in advance, with a date, time, name of the facilitator and basic information about the session posted as an upcoming event on the weekend testing site.
2. Facilitators and other interested parties announce the session dates and times and encourage people to participate. We have an email contact list, and we use Twitter heavily for this purpose. There are dedicated Twitter ID's associated with Weekend Testing chapters. The Americas chapter Twitter ID is @WTAmericas.
3. A central place to gather communication is proposed and publicized. The traditional tool for this is Skype, since it allows people with a variety of environments to participate, and since chat transcripts are easy to capture and archive for future reference. Most of the time, we limit the sessions to chat only, since that's the easiest to capture and it allows testers from all over the world to participate without taxing bandwidth.
4. A facilitator establishes an overall Mission and specific Charters around what will be tested. The Mission and Charter are generally chosen to help focus on a particular testing topic or testing technique as the "theme for the session. The facilitator also sets a time limit for the session. Usually, it is two hours. The facilitator also chooses the application to be tested. Often, it's an open source tool or a general purpose application to allow for most participants to feel familiar and be able to participate, no matter their skill level. We also get requests from companies to have us hold sessions to directly test a new version of software for them. When this happens, a representative of that companyparticipates in the session as the "product owner".
5. Sessions start at the designated time, the facilitator will start the actual group chat session about fifteen minutes before the official start of the session. As the Facilitator is contacted by interested participants, they are added to the group chat.
6. At the designated time, the session starts, and then is managed by the Facilitator for the determined amount of time. the facilitator's primary role is to encourage conversation, the completion of the mission and charters, and a discussion/debrief around the designated theme of the session.
Though not set in stone, the de facto standard session runs for two hours, with the following general guidelines for conducting the session:
00:00:00 - 00:05:00 - Introductions of Facilitator and Participants.
00:05:00 - 00:15:00 - Declaration of Mission, Charter(s) and Purpose of the Session, with time to clarify questions from participants.
00:15:00 - 01:00:00 - Active Testing (with discussion in main group or with pairs of testers working together).
01:00:00 - 01:15:00 - Checkpoint of group. Sometimes, it's warranted to extend testing, and if se, we add 10 to 15 minutes to the clock. Regroup if extra time is not needed and go to the next section.
01:15:00 - 01:45:00 - Debrief and discussion. Facilitator asks questions, encourages discussion on the theme, sees what went well, what didn't, what could be improved in the future.
01:45:00 - 02:00:00 - Closing comments, announcements of next session, etc.
7. After the session wraps, the facilitator gathers up any artifacts of the session. Examples are the main chat transcript, additional side chat transcripts from pair testing, if desired, notes, mind maps, bug entries, etc. and packages them together in a location that all participants can later share or reference. This can be as informal as a Google Drive or Dropbox Public folder, or it can be as formal as actually posting to a dedicated web server.
8. Finally, the facilitator or any number of other participants creates an "experience report", which is a basic summary of the session, the focus of the mission and charters, interesting comments that came out during the session, general takeaways, and a link to the full session chat transcript. Generally, the names of all the participants are included in the experience report as well. Here's an example of an experience report on the Weekend Testing site.
Wow, sounds like a lot to handle, huh? In some ways, it is, but it has the benefit of being very modular. Sessions can be handled by one person, or responsibilities shared among a group. The beauty of the Weekend Testing model is that it is very portable. It can be done anywhere, at any time, with any number of participants.
Caveat: it makes sense to keep session participants to a manageable volume. My experience indicates that sessions with five people makes for a good minimum number to keep the discussions interesting and active. Twenty-five people is a reasonable limit, so that everyone gets a chance to meaningfully participate. Beyond that, it becomes very hard to keep the group focused (the phrase "herding cats" is appropriate).
The Skype model (IRC, other chat client, etc.) makes it possible for sessions to be recorded, uploaded, read and reviewed later with context preserved, and acts as a document of learning, teaching and managing others.
One other long standing hallmark: Weekend Testers by design is "school agnostic". You can come from any background, experience level, and approach. We won't judge. We won't criticize. We consider Weekend Testing and the sessions conducted to be a "safe space" to learn, ask questions, get answers, and try out ideas. Anyone looking to carry this idea to their own efforts, we in the Weekend Testing movement ask that you carry that philosophy with you as well.
Bottom Line:
The Weekend Testing model is not the only one out there, but it is, in my opinion, my personal favorite model for a genuine, engaged peer participation method. While we have some standards and protocols we use to help make sessions run smoothly, they can be adapted and modified by those who wish to experiment with different approaches.
I am serious when I say "take the model and run with it". If you want to make a "team version", it's easy to do. If you want to make a go as "Weekend Testing on Campus", go for it. You may even find that you have enough critical mass and interest in creating your own oft meeting chapter.
Regardless of how you choose to do it, just do it. Make a commitment to get a group of people with varying interests, strengths and skills, learn from each other, and provide a way that will help others who come along later.
No comments:
Post a Comment