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 #68: Testing should be fun so remain positive and get everyone within the team enthused about the merits of testing - Steven Cross
Many people don't realize that they test all the time. They think that testing is something that other people do, or that a person needs to have a job description that involves testing. While it's true that most people are not trained in testing, that shouldn't preclude people from all parts of the organization to take part in testing. I've recommended setting up pairing sessions with a variety of people to get their insights, and to test with people from all areas of the organization. There's one more thing that we can do to drive home the importance of testing and, more important, that anyone can participate in it and provide unique insights.
Workshop #68: Think about how to get people involved in testing with you, especially someone who has never considered themselves to be testers in the past. Lead a bug-fest with a bunch of co-workers, preferably those who are not career testers. Make a party, bring food, and set "bounties" for interesting bugs.
These events are called a number of different things. Test-a-Palooza, Bug Bash, Espionage Night, Hammer-Fest, etc.. Regardless of the name, the effect is the same:
- set a date and time, preferable several hours
- gather a bunch of people from different parts of the organization and sit them together
- get food, beverages, candy, etc. and have it available
- make it an event that is meant to be fun, but with a purpose
The idea for one of these events is that we want to focus on a broad range of features. This is often the "last chance" for a feature or release that has been internal to an organization before it receives a wider distribution. Giving everyone free reign to dive in and see what they can find tends to energize a group, especially if it's done with a sense of fun.
Make sure to have a facilitator that keeps track of a board as issues are found (file the issues in the tracking system or method that you use, but make sure that any issue found is put on the board for people to see. This has two effects. First, it focuses people on areas to look more closely, and it also shows that people who don't necessarily consider themselves to be testers can find important issues and be recognized for them, too.
Take the issues that are posted and let the participants consider them, think about the severity or the priority, and let them rank them based on their collective perception. This is often done to set a "bug bounty" and collectively determine which issues deserve the "prizes" (which can range anywhere from gift cards to actual cash prizes).
The benefit of doing this prioritization and ranking is that it gets everyone that participates to think about what issues matter most to them, and potentially, would matter most to their customers. This ranking need not be set in stone (the product management and development teams will very likely have a different priority list) but for this purpose, let the process flow naturally. Who knows... the participant's collective wisdom may actually coincide with the development teams perception of the severity and priority of the issues found.
I've presided over several of these bug parties, and I've usually been the Boardmaster. We typically have had the testers be exempt from these events, but we often offer our efforts as team advisors, or to sit with others in the organization to help them test (we act as navigators in a pair session, and encourage the other participants drive). As such, often we get some terrific bugs from logical contributors (the customer support reps, the sales people, etc.). Several times, the top bug bounty has gone to the office manger, because they were the one that knew the system inside and out from daily use.
Bottom Line:
Running a bug party with your organization is a great way to expose actual testing to those who would not typically participate in the process. They realize that they have something to contribute and that, often, they discover what it takes to chase down a problem, bound it and explain it in a way that a programmer could work to fix it. The net effect of these interactions is that a lot of fun is had, the software gets a thorough workout from a large group of people, and every once in awhile, a little more respect is given to the testers who do this kind of thing every day.
No comments:
Post a Comment