Monthly Archives: August 2010

While the competition of TeamSTAR 2010 has just opened and is still going on, i already can lean back and reflect, what i learned from this lesson:

I am impressed with most of the finalists. I like their approach as much as their professional videocut.
Makes me wish in hindsight to have spent some more time on preparation and technical setup… Anyways.

I had fun, liked my idea (if i can say so myself) and it was a nice team event.

What else?
Had to cope with a kind of jealous and dispirited emotions.. not nice as such, but at least a lesson to learn how to cope with it.. 🙂

Another thing, which was also mentioned on TesterTested blog and which might have come true here as well: The voting system.

I understand, that setting up a system needs to balance between ease of use (less people would use it, if the hassle factor is too high) and exploit-proof on the other hand.

The team from EuroSTAR (thanks to Kevin for all the patience he showed) did a good job, compared to the VideoSTAR voting earlier to use. That voting was way too easy to fool and misuse.

Now the only thing left to consider, in my very personal eyes, is how to implement a kind of “fairness” factor.

(Here we can safely leave the area of EuroSTAR).

This of course is true with most (all?) kind of public voting/elections.

While it is legit to rally friends, collegues plus people who actually like your topic, it always has the risk, that numbers matter most.

Its a double-edged sword.. one has to respect the majority, but should numbers really be the only legitimate factor..

Last week i saw the TeamSTAR news on the EuroSTAR website. A Team of four people could make a small (2 min) video entry, upload it to Youtube and get the chance to win the team tickets for the testing conference. With a price tag from 850 to 2200 Euro, i thought to myself to give it a shot. While in between some tests and waiting for the machines to process i scribbled down the rough idea, which came to mind.

Our company is quite global. We have production centers ranging from USA via Romania to India and Cambodia. Our production managers are working near-shore in Brighton and Bucarest.

Our headquarter is in Hamburg; which by itself is an old maritime city with trade roots dating back a millenium and first mentioned in the 7th century. Global and weltoffen1 by definition.

Anyhoodles, back to the topic. My idea for the video clip was based on the “global” idea. Even in the company we have a wide range of nationalities and languages; as is in the Test department.

How to show that and relate it to testing in the same?

My idea was to let the colleagues speak a few sentences in their own languages (basically a “Hello World, my name is Maik and i like to go to EuroSTAR 2010..etc.).

This gives the unsuspecting viewer of the clip a Babylonian language mix.

At the end of the clip i connect these single parts with the diversity of testing.

Each person brings in their very own experience.. influenced by there culture, gender and profession background.

Testing is as diverse as language.

We got black, white and grey box testing, we got functional and non-functional testing, we got unit, system and integration testing, we got ISTQB, ET and Agile Testing2 etc. pp.

Well, not a new breakthrough idea, but i just wanted to point it out; which i did in this clip:

Today i used BBTestAssistant to record some sessions.
I put my notes directly into the tool to make best use of the integrated timestamp and the option to jump directly to the scene in the movie. (HINT: Move mouse to bottom of screen and the notes window pops up and pauses the recording).

At the end of the day i went through my recordings and the observations and sorted them; mostly transferring them into the bug tracking system (TFS) , made nice screenshots with markers, etc.pp.

One of the observations i had already (mentally) put as “bug” and written some notes accordingly.

Now.. with some hours distance i saw that i missed another reason, why the behaviour could have happened as it was.

So i kept the entry on hold and made a task for myself to retest and verify with my new finding/assumption.

Next day i retested the observation with my new information at hand and – vòila – it wasn’t a bug, but a misunderstanding on my side.

Long story short:
Another example, where focusing — defocusing was helpful.

But.. Do i have the time for this in the daily treadmill? Mh, not always.
How many bugs were reported, where i could have provided more details? Or where it wasnt a bug at all?

LESSON LEARNED:

Take the time if schedule allows to gather observations and review them at a later stage.