“Testing is something that we do with the motivation of finding new information.” – Michael Bolton^[1]

Damn old picture of team testing

When we talk about team testing, I guess many of you will image a picture in your mind:

• People are sitting around a table.

• Everyone gets a paper in front of them. This paper could be a checklist full of test steps, could be a sheet full of test scenarios…

• When testing starts, people follow same test cases on the paper, step by step “testing” product.

• Soon, People look like a robot: they look at paper and write down the answer “yes”, “expected result”, “pass”, “no”… Someone will collect paper and check pass/fail…

Well, pretty like:

^[2]

I’m always asking myself. If I’m one of these guys participating this the kind of team testing, would I be bored to die? What’s the problem here?

Why not make team testing like taking a challenge, playing a game, exploring around?

^[3]

Let’s have some fun!

“People are sitting around a table.” Nope! 🙅

Instead of limiting people to focus on his own stuff, I really like to make people pair together and let them share a “test challenge”. They can do testing together no matter where they want. Pairing together in team testing is a good test strategy for:

1. Making comparison: when it needs to know if different platforms, different versions have different behaviors…

2. Exchanging idea: when someone comes to an idea, (s)he can immediately try with her/his testing partner…

3. Remembering findings: when something found, (s)he can show to her/his partner how to reproduce…

4. Training newcomer: when a new team member is joining, (s)he is not quite familiar with product…

“Everyone gets a paper in front of them. This paper could be a checklist full of test steps, could be a sheet full of test scenarios…” Nope! 🙅

In my team testing, there is no checklist, no test scenarios. I call them mission and challenge. My thought here: Do exploring, not checking, because exploring is more exciting. I prefer to describe simply a challenge in one sentence using CAR model (it’s the first name comes to my mind…). CAR stands for Condition, Action and Result. A simple example:

Condition: GPS on

Action: open app

Result: my current location was shown

Then the challenge is: When phone GPS turned on, I open app, should I see my current location shown correctly?

For a 30min testing session, in a mission, 10-15 challenges are recommended. Above 15 is too much, because when people are getting tired, no fun :(

“When testing starts, people follow same test cases on the paper, step by step…” Nope! 🙅

Using CAR model, it’s easy to remove useless test steps and to modify them dynamically according to tests.

For example, we’re focusing on a new feature to reserve vehicle from vehicle list. Then the challenge is: When my test account is logged in, I pick a vehicle in list, should I be able to reserve vehicle?

If next time, we want to test general reservation function. Then the challenge is: When my test account is logged in, I pick a vehicle in list or on map, should I be able to reserve vehicle?

Or it can be separated into 2 challenges:

When my test account is logged in, I pick a vehicle in list, should I be able to reserve vehicle?

When my test account is logged in, I pick a vehicle on map, should I be able to reserve vehicle?

And I will put them to the different missions for different participants.

“Soon, People look like a robot: they look at paper and write down the answer… Someone will collect paper and check pass/fail” Nope! 🙅

Usually I set up a simple finding-wall, like blow:

             iOS     |    Android
Major                |
Minor                |
?                    |

Column: platform

Row: major findings, minor findings and unclear findings (needs to discuss)

All participants will put findings on the wall during team testing. After testing, they will be taken down one by one and fixed one by one.

If you ask me how about that mission-paper? I will destroy them immediately after testing and let it be a secret mission.

Expected result

After participating this team exploratory testing, you will probably think “I’d like to test more next time!”.

[1] Michael Bolton: Testing vs. Checking
[2] Damn round table team testing
[3] Children play around