Last week I took Rapid Software Testing from Michael Bolton. The three days of stuffing my brain in the beautiful downtown campus of the University of Toronto was loads of fun. Points I especially remember:
I had already experienced one of the exercises at a previous meetup with Michael. Thus when he asked for a volunteer this time he told me I was not eligible. I had assumed as much and so did not think anything of it. I wondered whether anybody else had caught the exchange - our exchange was not secretive but neither was it ostentatious.
The point of the exercise was to test a certain object. At one point the brave soul who volunteered asked Michael whether anyone else had ever tested the object. Michael replied that many people had. I expected him to say "In fact, someone in this room has", but he didn't.
Moral: Even people who seem to be in charge, to know everything that is going on, do not think to give us every piece of information they could provide.
For my part, I never let on that I had been through the exercise either. Initially this was due to an assumption on my part that Michael would want the other students to work through the experience on their own, just like I had. I never checked out that assumption though.
Moral: People with useful information may not provide it because they think they should not.
There was likely a point in the exercise at which Michael would have welcomed my offering assistance to the others, but I was still working under my original - unverified - assumption.
Moral: Mind reading does not work.
Moral: Explicitly ask other people on your team whether they have information they think might be helpful to you.
Another time Michael did magic tricks. I was pretty sure this was a prelude to some point about testing and so I ignored his patter and instead paid close attention to what he was doing with his hands. The longer he continued the more bits I identified, but I only ever almost figured out each trick when he stopped and moved on to the next one.
Moral: Additional observation time tends to increase the chances of solving a problem.
Moral: Problems are often only almost solved, or described, or identified, before you have to move on.
As part of a discussion about observation Michael showed the famous gorilla movie. I have seen this more times than I can count, and so rather than following what Michael told us to follow I paid close attention to other parts of the scene. I noticed things I had never seen before.
Moral: Additional viewings of something (like a test, or a bug) tend to produce new insights.
After checking the results of what he asked us to follow, and asking whether we had seen the gorilla, he queried us on other aspects of the movie. "How many elevators were there?" Michael asked. Two! I answered with assurance. Wrong! There were three. "How many people were in black?" Two! I again said with assurance. Wrong again! There were three. "How many people had on long sleeves?" I had no idea.
Moral: It is pretty much impossible to pay attention to everything all the time.
During many of the exercises Michael encouraged us to break the rules of the exercise. He maintains that, for testers, cheating is competent, ethical, and correct behavior. For example, many of us have been taught throughout our schooling not to look for answers on our neighbors' papers. For testers, though, asking "Has anyone else tested this?" - looking for answers from our neighbors - is all goodness. We might be able to avoid testing something altogether! At the very least we are likely to learn helpful information. As he says, if we don't have the freedom and independence to think the way we want - if we are forced to think like everyone else - we will miss the same things they do.
Moral: Breaking the rules is our job!
Has testing ever bored you out of your mind? Michael maintains that when something is boring you are likely going about it wrong. So if a test is boring, or tedious, or a chore, look for a different way to execute or approach the test that eliminates the boredom and tedium and drudgery.
Moral: Testing should be play, not work!
If you don't go to play each day, or you don't think you can break the rules, or you simply want to become a better tester, give Rapid Software Testing a try. I think you will find, as I did, that it is three days well spent!