50th Weekend Testing session and „Pairing“

As one of my intentions for 2011, I want to restart with Weekend Testing.
Summer 2010 was not a good time for being indoors at the weekend, so I stopped participating.

I prefer the “Original” WT, which conveniently is around 9.30 AM local German time. Often I am just back from walking the dog and my coffee is fresh and hot. My wife normally is still in bed, so the house is quiet and the daily „busy-ness” hasn’t started.

Coincidentally the “50th WT Session” was coming up.

50 sessions mean 50 weeks of voluntarily testing passion on a weekend day.
Consider some Saturdays, where it doesn’t happen, and we are talking about more than a year of continuous passion and effort on the organizers and participants as well.

The participant list in the Skype chat conference was also impressive by sheer numbers alone. It seems to have grown to a steady core base of testers. I saw some familiar names, but also new starters (or at least new names to me).

Congratulation to the organizers and to us, the participants!

The mission for the 50th session seemed easy enough:
For a given program (FireShot) , go to the website, where the users have posted their problems and bugs and help the programmers by enhancing the “bug reports“ with new information.

We also got a question if we want to pair or work alone.

At my office I work alone, so I never had the question (and option) arise as „to pair or not to pair“.  I heard positive experience reports about it, so I said to myself: „Okay, let’s do this. “

(I am quite shy with “strangers” and that includes online contacts as well).
Luckily Jassi was participating as well and also wanted to try it out.

We went into a separate Skype chat and started.
Very soon we decided to go for a Skype call, since we were too busy reading the other WT chat, downloading the program, opening web links etc.

Lesson 1: Talking keeps both hands free for other stuff (really? what a surprise..)

We established our test environment: Jassi had Chrome and Firefox and Windows XP. I had a Vista x64 bit and FireFox ( I assume we both had IE, but that was a “it-who-must-not-be-named”). This little initial talk also helped with the pacing; at least on my side I needed a few minutes to synchronise myself with the other voice and my hearing.

Lesson 2: Always take some time to establish some groundwork and “Pacing”

With talking enabled, we started to have a lot of questions as we jumped right into the mission.
The mission was shaped in a layered question (“Can you find the root cause and help the fix the issues faster?”). We asked a few questions ourselves; mostly concerning the „find the root cause“.

This seemed to me an obvious trap, since this seems not easy to do (if at all) by a tester. Even considering we would have coding skills, the appearance of a bug can’t be safely linked to a root cause (maybe for typos, but even there it might be just a different (valid) spelling:
Example:
US English = „color“                versus                   UK English= „colour“
Wiki.

We decided to ignore that piece of information and stick to the remaining part of the mission:
Improve existing bug reports from the users to help programmers to solve the bug.

We were given a website called typewith.me, which seem to enable simultaneous typing in a kind of document; where each writer gets a different colour to separate them.

Jassi and I ended up the only one using it with our findings. When someone started a sentence and went on to the second sentence, the first could already extend the initial sentence and rewrite or enhance it. Very nice tool.

We went to the web site and had a look at the “bug report”. I put bug report in parenthesis, since in my understanding, it wasn’t, what I would consider a bug report.

I assume mostly regular users entered their problems in this forum. So it is understandable and totally okay, that it is not up to my expectation.

What made it hard for us to get a understanding of the problem reported, was, that often there were answers and new question or new information in a thread based discussion.

It was also not visible (to me) what the status of the bug was. Was it closed? Solved? In progress?

A lot of time was spent just reading the discussion and trying to figure out important (to us) information.
What version were they are using? What operating system, what browser? What was the exact problem, aka with what function or feature?

We thought, maybe we were just unlucky with the chosen bug, so we took another one.
This time we discovered after reading, that indeed the programmer deemed the case solved and the bug fixed.
We couldn’t reproduce the bug either; since we didn’t know the *exact* circumstances.
Even if we try to approximate, it is just that: An approximation.

We gave it another shot and tried a third bug from the forum, but that went a similar way.

At that moment we decided to de-focus and talk about, what we feel and think.
Both of us were at unease, if proceeding according to the given mission was useful to us or if we would go off charter, define our own mission and help the programmers in a different way.

Lesson 3: If feeling or experience suggest, that the mission is “weird”, follow it up and try to change it, if possible.

We decided to gather information, how the bug reporting system as such could be improved.

If the current bug forum still needs to be used, at least a moderator should gather relevant information from all the posts in a timely manner and write / update them in the initial report.
That way, the newest information would be immediately visible.
Also a better status overview could be incorporated, so that “solved” cases should be closed, hidden or otherwise visible marked as “done.

Of course, we had the freedom in this weekend testing session to decide on our own to change the mission.
This might be not possible in real life work environment.
But it should be possible to inform the stakeholder (who has given the mission) a fast and early feedback, that the time invested in his original mission is not well spent.
And one can make a suggestion, what better benefit can be provided, with a change of mission.

Lesson 4: Even when changing mission, still keep the focus on providing good information to your stakeholders.

For Jassi and me the pairing option worked out quite well.
I learned that there is no need to be shy, if both have the same goal (learning & testing).

Next sessions I want to try it out even more and with diverse people.