I was reviewing a test case when Outlook announced, “You have mail.” Since mail is always more interesting than test case documents, my curiosity kicked in. It was from the human resources team and read, “Dear Parimala, our monthly movie screening at the office is scheduled for this afternoon. The 1936 Charlie Chaplin classic Modern Times will be shown.”
The movie begins with Chaplin as a factory worker. His job is to tighten every nut that comes down the assembly line conveyor belt. Chaplin cannot afford even to sigh; otherwise, he’ll miss a nut and his manager will punish him. It was fun to watch how Chaplin coped when he missed a few nuts for reasons such as a bee swirling over him, his manager interrupting him, and wanting to stretch his hands.
To increase productivity of the factory workers, management installs a machine to “help” Chaplin. The machine is an automated feeding and cleaning device that ensures that the staff take the minimum amount of time to eat lunch and get back to work. The way Chaplin responds to the automatic feeding machine is hilarious because of the bugs in the machine.
Later, as some of the scenes replayed in my mind, I wondered, “Were we laughing at Chaplin or at ourselves?” Modern Times was made seventy-four years ago. We thought the world had changed completely since then, but we were wrong. Consider the following:
In testing, we seem to be in a rut. It appears we are paid to be “checkers” but given the fancy title of “testers” to make things look better.
In Michael Bolton’s words, “Checks are machine decidable; tests require sapience.”  Testing is an exploratory process, and checking is mostly a non-exploratory and confirmatory process. Machines do a better job of checking compared to humans, but only humans can do testing.
The Idea of Testing on Weekends
The weekend testers are a group of people who wanted to do more testing and learn to do it better. After spending the work week as specialist checkers, we wanted to focus on testing. Having met other checkers who also wanted breaks from checking, we thought we should open this up to the world after our initial experiments provided satisfactory results. We wanted to test, but what to test? Microsoft Word? Gmail? Why not an open source product that also helps the community? Should we close doors to testing commercial software? What better time than weekends to do all of this? That’s how the idea of weekend testing was born.
Typical weekend testing includes registration, facilitation, a testing session, and a discussion session. Announcements about upcoming sessions are published on weekendtesting.com, Twitter, testing forums, and testing groups. Testers assemble on a Skype group chat at a specified time. The facilitator for that session provides the product download details and mission to test and sets a time limit of one hour. The facilitator is available for queries during that hour, just in case testers get stuck. The facilitator may have set some traps without the testers’ knowledge. Once the testers begin testing, the facilitator reminds them to stick to the mission and avoid traps and diversions. At the end of the hour, testers stop testing and participate in the discussion session for the next hour. This is a debriefing session in which testers share their experiences, challenges, bugs found, traps that they failed to clear, and many other items. This time also includes discussing the product, mission, test strategies, tools used, etc. Many times, testers learn from other testers about new test ideas, tools, and strategies.
Test, Learn, Contribute
In a work environment where we are watched very closely—and where making a mistake can affect our performance reviews or even cost us our jobs—most testers are not interested in exploring new approaches to testing. In many cases, someone has labeled a technique as a “best practice,” and we follow it—no matter how long the idea has been around, how ineffective it is, or how expensive it is for the client.
Weekend testing offers individuals freedom and allows them to try new things and to make and learn from mistakes. Weekend testing also helps teach the responsibility associated with freedom. Our experience is that the value testers can contribute when provided with freedom is much more than what they do under strict supervision. Testers learn about their own skills and set out to do better the next time. They also appreciate and try to copy others’ skills, ideas, and approaches.
From experience, the weekend testers have learned to:
Fail faster and safer: All of us want to do things that make us look good to the management or the client. It is human nature to do things based on what we are evaluated on. Testers participating in weekend testing are not rated on anything; they make mistakes that they wouldn’t otherwise. This is a safe place to experiment with ideas and take them back to work.
Appreciate diversity: At work, hiring often happens without valuing diversity. As an example, everyone must be proficient with Quick Test Professional otherwise, there is no place on the team. Weekend testers discover the value of having different opinions. We hope this will improve how test managers think about testing.
Uncover hidden talent: Sometimes, an idea that we thought was stupid actually gets appreciation from our peers. This surprises us, and we start discovering new strengths in ourselves. What one tester does often surprises another, and when they communicate about it during the retrospective, it helps a lot.
Become aware of traps: Quite often, we fall into traps and are unable to recover from them. During retrospection, when one tester describes her experience of falling into a trap and how she recovered, it becomes educational for the rest. Sometimes, facilitators intentionally set traps to help others grow.
Vary experience: In our opinion, the idea of a Web-application-only tester, telecom-only tester, etc. is bad. There is often knowledge from testing other products that we can carry over to testing the product we are currently testing. In weekend testing, we choose to test a variety of products from various business, functional, and technology segments. This has proven to be a valuable learning experience for everyone.
Contribute to open source: In 2004, SourceForge called for testers to work for them and no one was interested. Today, through weekend testing, we service a number of open source projects at no charge. Some of the project owners have approached us directly, too, which equates to value for others for the time we spend learning. Programmers working on three different open source projects—WireMaster, FreeMind, and TuxPaint—applauded our passion for testing and the number of bugs we have found in their products. They paid us back by promising to fix some bugs, if not all of them.
Build unity in our field: Separated by schools, certifications, regions, onshore-offshore controversies, technologies, domains, and interests, we are tired of not being united. Here at weekend testing, irrespective of whether you are ISTQB certified or CSTE certified or even self-certified, it’s all the same as long as you test, learn, and contribute.
Some people ask us if weekend testing could be the beginning of the renaissance of the global testing community. We will leave it to them to decide while we continue to enjoy testing.
Want to start a chapter? An email to email@example.com will get the ball rolling or you can register at weekendtesting.com to participate in upcoming weekend testing sessions.