Category Archives: Allgemein

Experience report on a Miagi-Do challenge

I was attending the test automation day in Rotterdam, where I had the chance to meet a few Miagi-Do fellows and took the opportunity to ask for a challenge.

Huib Schoots (@huibschoots), Jean-Paul Varwijk (@Arborosa) and Matt Heusser (@mheusser) gave me the chance and we sat down for it between some sessions.

Huib took the role of the challenger.
And, boy, did I took a learning that day. Sometimes I felt like in Vaders Force Grip. 🙂

I had some time for reflection since then. Here are my learning’s.
Traps. Some I was expecting, some were unknown (to me). 
I try to summarize the traps, as I see them and will mark my comments as well.

Trap: Surroundings (Environment). We had the challenge in a time-boxed environment (since the next conference session was looming ahead) and the noise level and distraction was varying as well.

Maik: This is not unusual in real situations as well; we as testers also have to deal with that.

If you have the chance, setup a quiet, concentrated meeting with your stakeholders. Try to have as few distractions as possible, phone, email, walk-ins, etc. Maybe changing to an alternate place (meeting room, go out for lunch) can provide already some focus.

Nevertheless. Have a checklist, mind map or some guide at hand. Maybe even sketch it out on paper. Having it only in your head can or cannot work.

Trust me, if you sitting with three people all making comments (intentionally or not) and a personality like Huib (:-)), it did really distracted me from my mental checklist and my brain became a distracting factor as well (shame on you, my brain!).

Trap (which I brought on myself): Preparation time.
Maik: After the challenge was given, I didn’t ask for some private preparation time. Even 2-4 minutes might have helped me sharpen my mental checklist to the current context. And nobody “forbid” it. But by not even asking, I lost out on that chance!

Trap: Challenge setup and challenger agenda
Maik: Since it was a challenge, I expected some “rules” and even “hidden rules” of the challenger (here: Huib). Knowing that there were some and actually recognizing them or even actually engaging them is different.

For example: I expected that the challenger would hide or avoid certain information, till I trigger them. But sometimes I felt, I was actively led astray.

Which is okay, since it is a challenge; but it adds an additional layer of difficulty.

In reality I would expect that the stakeholder, who is coming to me, would “play nice” and “play along”. As in, we are on the same side.

Example: Stakeholder has no clue about testing. I would expect that he would play with open cards and acknowledges that fact. Then I can adjust my role and help him better; I need to give him different information as someone who knows about testing.

But that is my assumption. This leads me to…

Trap: Intention of the stakeholder
Maik: One thing I re-learned again is try to find out the intention of the stakeholder coming to you.

Stakeholder can have different kind of motives. They can look for a scape goat, they can be totally clueless to testing, they can really want to help you with all they can contribute, they might have already made up their mind about the product and just want “proof” of their opinion, they might want to help, but have a different understanding of the context.

It is not easy, if at all, to find out the intentions of the person you are talking to; especially if they are unknown to you.

I knew Huib in person from five days at the Agile Testing Days 2012 (@AgileTD), so he was kind of “unknown” to me.

 

Now the last trap, which I brought on myself and which is the hardest to admit:

Trap: Hybris.
Maik: I knew and know, that there are a lot of unknowns to me.

In Testing, there are situations, I haven’t encountered yet or software bugs I haven’t seen or found. I read a lot; I had the chance to apply some of it and I am trying to keep up with information.

So I betrayed myself by believing, I could do the challenge and do it good. I didn’t expect it to be a breeze, but manageable.

Besides the fact, that I love riddles and puzzles, I also wanted to show to my fellow Miagi-Do’s, that I know my game and can step up to the plate.

If you are a tester with experience or a consultant with a lot of exposure, you should treat each stakeholder with your whole focus and concentration and take their request or questions seriously.

Serious in the sense, that to really think about what their request is, what their questions mean (to them) and not brush to fast over it, cause you have done it many times before. Maybe you are right, but sometimes you might be wrong and doing not a good service to your stakeholder as you could have done.

 

Conclusion

For me it was absolutely great to take on a challenge and get feedback from peers I respect. I wish we all could open one big company and work together on a daily base.

Even if I busted on that challenge, my takeaways made this experience worthwhile.

2. PotsLightning announcement

The second PotsLightning peer workshop will be held on 27th of October 2013.
It is lined up on the sunday before the Agile Testing Days 2013 conference.

Some people are arriving the weekend before and now they have the chance to attend also a workshop with peers in a relaxed atmosphere.

This year we will do an Open Space format as not to restrict the flow via setting a strict theme upfront.

If you are interested to attend, please contact us via email.
Should you already know a topic you want to talk about, feel free to sent it in the email  and we make a rough idea collection on the website.

Twitter Hashtag: #PotsLightning

Here are the information in short:

Date: 27.10.2013
City: Potsdam, Germany
Venue: Dorint Hotel

Blogging again..

What happened in the last year since I last wrote on this blog?

Well, I was in a stage of being unhappy in my last job and that also distracted me from many other things.
Now I a few months into my new job and found the inner peace again to write some blog posts.

I joined a consultancy which has a good setup for agile testing.

This brings along some new aspects for me.

First is being a Consultant.
I did not have that field in my focus, but some peers recommended it to me, so I pondered about it.
The biggest reason to leave the old work was the feeling, that I couldn’t bring the improvements I wanted to bring for the company.
Well, I still believe the improvements would have benefitted the company and that I was not biased and wanted to bring my ideas for the sake of them being mine.

This has been rubbing off on me for quite some time.. Winter 2010 roughly.

The consultant job might help me with that factor. At least I can leave the client, when the project is over and he hasn’t listened to my advice. 🙂
I hope it plays out in practice as well as in theory. 🙂

Currently I am in a “traditional” project; assisting the test management in a migration from Hosts to SAP IS-U environment.
Very cool. First I learn SAP, second I learn working in a “big” company (coming from middle size firm is a *huge* difference) and third, my help and expertise is really acknowledged and sought after.
That’s a double cool and feels *really* nice.

Second aspect is shaping and sharpening the agile setup of our company.
I work on defining workshop formats and content, on long term new business areas, marketing material and what now.
Since I was always a “Jack-of-all-Trades”, this is also a big benefit for me.
Plus it challenges me also in a good way to think up content and ideas.

Third: I have tester collegues!!!
How cool is that? Working for 3+ years as the Army of One was more exhausting than I recognized before.
Even with the now and then Weekend Testing exchange or user group meetings, I rarely had the chance to discuss testing stuff and bounce ideas.
Or get corrected, when I forgot an important factor in my approach. So YAY for tester buddies.

Fourth I meet so many interesting people.
I did some workshops and testing dojos in a medical device company. Quite some stuff they have and do there.
I also met global testers in the trainings I attended (did I tell already, that my company is big on education their employees..) and got a lot of exposures to different industries, approaches and live experiences from them.

So yeah, 2012 started well. And I hope the Mayans were wrong, otherwise it would *really* suck.

To keep my promise I made (when I find a good job..) I got myself a tribal Ganapathi.
So I also found a new tattoo artist, which I might consult again. 🙂

Thanks for reading along,
Maik

German Agile Testing and Exloratory (GATE) Workshop

Ab gestern ist es offiziell:

Markus Gärtner und ich organisieren den ersten deutschen Workshop zum Agilen und Explorativen Testen am ersten Oktoberwochenende 2011 (01 – 02.10.2011).
Der Workshop wird unter dem Namen “GATE – German Agile Testing and Exloratory Workshop” veranstaltet und findet erstmalig in Hamburg, Deutschland statt.
Ab heute können Einsendungen für Beiträge und Themen eingereicht werden.

GATE ist eine Low Budget, Non-Profit Veranstaltung und kostet keinen Eintritt.
Zudem versuchen wir die Kosten niedrig zu halten und wollen auch keinen Gewinn machen.

Für die Teilnehmer bedeutet das eine Kostenbeteiligung nur an den wirklichen Kosten (Raum, Projektor, Strom, Pausengetränke, etc.).
Die sonstigen Kosten (Unterkunft, Anreise, Verpflegung) tragen die Teilnehmer selber.

Momentan rechnen wir mit deutlich unter 100,- EURO pro Teilnehmer.

GATE soll eine gleichberechtigte Plattform zum Erfahrungsaustausch sein.
Ambitionierte Tester, welche praktische Ansätze und Konzepte aus der Zunft des Software Testen lernen und sich austauschen möchten, finden hier gleichermassen Interessierte.

GATE will einen Kontrast zu traditionellen Konferenz-Formaten bieten und und eine Veranstaltung sein, die einen gleichberechtigten Raum für Tester ermöglicht.

Kontroverse Diskussionen, Erfahrungen aus der Praxis, rund ums Thema Software Test. Und das als Low Budget angelegt ist, um möglichst vielen die Gelegenheit zu bieten, teilzunehmen.

Eine feste und wichtige Komponente des Workshop ist die Beteiligung der Teilnehmer.
Wir erwarten von jedem Interessierten, das er oder sie ein Thema oder einen Beitrag einreicht und den auf dem Workshop präsentiert oder darstellt.

Als Gedankenanregung kann folgender Ideenblock dienen:

  • Reale Erfarhungsberichte
  • Kontroverse Testing Techniken oder Methoden
  • Testing Übungen, Praxis (z.B.: Testing Dojos, Hands-on testing)
  • Varianten zum Verteilten Testen

Das ist keine exklusive Liste und wir stehen für Rückfragen, Diskussionen und weiteren Ideen offen zur Verfügung.

Die Sprache des Workshops ist abhängig von den angereisten Teilnehmern.
Bei internationaler Beteiligung wird der Workshop in ENGLISCH abgehalten. Es kann aber auch genausogut Deutsch sein.

Dies sollte ggf. auch bei den Beiträgen berücksichtigt werden, wenn zb. Hand-outs oder Handzettel ausgegeben werden.

Wenn Ihr am GATE Workshop teilnehmen wollt, sendet bitte eure Vorschläge bis zum 5. September 2011 ein.

Mehr Details zu den Teilnehmern, dem Programm, Anreise und Unterkunfts Informationen gibt es im Laufe der nächsten Tage.

Wenn Ihr mehr über das Format und die Art dieses Workshops erfahren möchtet, sind hier einige Links.
In der letzten Zeit haben einige Peer Workshops stattgefunden:

Markus und ich freuen uns, Euch in der besten Stadt der Welt willkommen zu heissen.
Wir hoffen, ihr seit so aufgeregt und erfreut wie wir. 🙂

Does Testing have a color?

I was thinking about something today (soon you will know) and then thought “Hm, what would others say?”.

The questions arose: What do I see in my head, if I think “Color + Testing”?

Immediately RED and GREEN springs in my mind.
Probably conditioned from the ominous “PASS/FAIL” visuals (addentum: I should write FAIL/PASS, since RED is mostly connected with FAIL… would fill another book to go into that psychological conditioning).

When I focus on AGILE.. somehow I also see GREEN, maybe a lighter shade.
When I focus on CONTEXT, I see BLUE.

Have I seen somewhere in a blog this connection? Is it, cause James Bach Twitter Icon has a blue background? My Unconsciousness won’t answer me… bugger.

So fellow testers and interested people.. what do you see, when you think about COLOR and TESTING?

Meet PACO for iPad

This heuristic can be used for all devices which makes use of orientation modes.

Do you know PACO? He is the senior brother of PAOLO:

NEW: Introducton of Communication aspect

Portrait, Audio, Communication, Overlay

Portrait:

Orientation is one of the big features of the current device generation.

Portrait, portrait upside-down, landscape left and landscape right are “strongly recommended”:

Important: It is strongly recommended that your application support all orientations. This includes portrait, portrait upside-down, landscape left and landscape right. iPad apps that require an orientation must support both variants of that orientation.

Link: http://developer.apple.com/library/ios/#qa/qa1588/_index.html

 

Does it support different display modes? How does the app (application) handle them?

“The trick is to keep the experience consistent in each view, allowing for a seamless user experience when switching views.” (Quote)

Look at the example given at the website, the color palette looks okay in landscape, but in portrait it takes up a lot of the available space.

Some apps explicitly decide on one kind of mode.

*This has benefits for the developer:

– UI elements are created for one mode, e.g. “Open” is always at the same place.

– The arrangement, field size, font and order of elements don’t need to be checked as how they look in the other mode. Less developing and/or design time is needed.

–    Better overview (“guiding”) of how the user will use the program (paths).

Let’s assume there is a user story which consists of only four action buttons: >>> Open, Change, Save, Close <<<

A)    For one mode (p=portrait), there is one path (regular use, no tester mind involved).

Open (p), Change (p), Save (p), Close (p)

B)    With two modes (p=portrait, l=landscape), there are 16 paths:

Path Open Change Save Close
1 p p p p
2 p p p l
3 p p l p
4 p p l l
5 p l p p
6 p l p l
7 p l l p
8 p l l l
9 l p p p
10 l p p l
11 l p l p
12 l p l l
13 l l p p
14 l l p l
15 l l l p
16 l l l l

– Each single action can be executed while the device is either in landscape or in portrait mode.

– The combination of actions can be done in either mode: “Open” in portrait, turn to landscape, then “Change”, turn back to portrait and “Save”, last turning and “Close”.

*This also has disadvantages:
–    It takes away from the user experience.

Users use the device in any orientation they like. The majority (?) of apps enable this specific user experience, which is a unique selling point of the device.

–    Inefficiency, wasting of potential: Sticking to the “wrong” orientation (depending on the app and its purpose). Example: Sticking to portrait mode might not make use of the “wider” landscape screen.

 

Audio:

Does it support audio? Can it be muted? Can it be adjusted? Can it be adjusted with the device volume sliders? Does it bring its own volume control? If yes, can both be used together? Using the device volume slider moves the app volume slider? Can it be automatically adjusted? E.G. when phone calls come in? When overlays happen? Can it handle headsets or other jacked in audio devices (stereo set, car jack?).

 

Communication:

The communication part of the heuristic is from Tobias Geyer (@the_qa_guy); he mentioned it in a comment, but it is definitely worth to be included; kudos to him.

– How does your application behave if the network connectivity suddenly drops? Will the user loose data; will the app crash or hang?

– Will the app recommend a user to download a 5 MB feature pack when they’ve only got GPRS coverage or will it wait until they’re logged into Wi-Fi?

– What about the server side of things? Will it cause problems if the IP address of your device changes between requests?

– How does the app behave in airplane mode?

– Does the communication have to be secure – and if yes: is it? Think of network sniffers, proxies …

– Is the app using the network connectivity economically? Does it cache data locally or is it requesting everything from the server? Not everybody has unlimited network traffic.

– Is it possible to make your app work with a test system or are all requests hardcoded to your production system? This will affect testability a lot…

 

Overlay:

What is overlay? Overlay is the message pop up of one app, while the user is in another app.

Does it support overlay? What other common apps use overlay, that will *most likely* pop up? Skype? Facebook? Other chat tools?

How does it handle the overlay? Could there be data loss for the user, when the overlay happens? Is there a choice for the user to ignore the overlay? Is there a timeout for the overlay? What happens, when the timeout comes? Will the overlay disappear? Or come back in x minutes?

 

 

Hint: How to make an iPad if you don’t own one: iPad Testing Ideas

Origin: The idea started on twitter (24th September 2010) with a question from @Siggeb: “I am testing a new cool Twitter client for the ipad; give me some test heuristics.” At that time I quickly sketched PAOLO and now I found the time to fill it with some life.

Self-Education: The R.S.W.P. heuristic

In 2010 I read a blog post about it takes like 10.000 hours of practice in a profession to become a master in it. This quote seems to be taken from the Book „Outliers“ from Malcom Gladwell.

This instigated me to form a special kind of New Year resolution for 2011; that is to track my hours which I spent with testing. I also wanted to cover all aspects, which seem related to testing to me.

So in mid January 2011 I started my spreadsheet program and did a post mortem for the last weeks.
Quickly I found a pattern for myself and started to make rows by week and category.

The categories I saw were Reading, Speaking, Writing, Participating.
From that time I tried to find some activity in each of them per week.

Life distracted me quite good since then and I am still not back on track, but that is a personal story.

Recently I found a topic on STC „Self-Education: where to start from which reminded me of the resolution I had (ironic enough, it went the way a lot of New Year resolutions seem to go), which in return motivated me to make a little blog post out of it.

By actively focusing on these categories and trying to find an activity a tester can benefit on many levels.

I believe each tester should extend his skills and abilities; in that sense I am more a Generalist, then a Specialist.

For some that might be a suitable way, others prefer to get good in a few areas.
„Speaking“, especially in public, is probably difficult to get used to and get a „routine“.
But by speaking and actively interacting with people one can hone how to encounter arguments and advocate for his topic.

Since it was fun to jumble the PABLO heuristic together last time, I made a new heuristic for this.

I call it the „R.S.W.P.“ heuristic in the style of „R.S.V.P. = répondez s’il vous plaît  / Please respond“.

R.S.W.P = Reading, Speaking, Writing, Participating
Some activity examples for each part:

Reading = books, blogs, articles
Speaking = user groups, conference, videocast
Writing = blog, article, paper
Participating = communities, WT, conferences,  user groups

And last but not least: Testing (aka practicing) should always be a part of a tester.

PAOLO heuristic for iPad

This heuristic can be used for all devices which makes use of orientation modes.

Do you know PAOLO? He is a nice guy, as long as you don’t interfere with his expectations:

(Update: Also have a look at his brother: PACO)

Portrait, Audio, Objects , Landscape, Overlay


Portrait:

Does it support different display modes? How does the app (application) handle them?

“The trick is to keep the experience consistent in each view, allowing for a seamless user experience when switching views.” (Quote)

Look at the example given at the website, the color palette looks okay in landscape, but in portrait it takes up a lot of the available space.

Some apps explicitly decide on one kind of mode.

*This has benefits for the developer:

– UI elements are created for one mode, e.g. “Open” is always at the same place.

– The arrangement, field size, font and order of elements don’t need to be checked as how they look in the other mode. Less developing and/or design time is needed.

–    Better overview (“guiding”) of how the user will use the program (paths).

Let’s assume there is a user story which consists of only four action buttons: >>> Open, Change, Save, Close <<<

A)    For one mode (p=portrait), there is one path (regular use, no tester mind involved).

Open (p), Change (p), Save (p), Close (p)

B)    With two modes (p=portrait, l=landscape), there are 16 paths:

Path Open Change Save Close
1 p p p p
2 p p p l
3 p p l p
4 p p l l
5 p l p p
6 p l p l
7 p l l p
8 p l l l
9 l p p p
10 l p p l
11 l p l p
12 l p l l
13 l l p p
14 l l p l
15 l l l p
16 l l l l

– Each single action can be executed while the device is either in landscape or in portrait mode.

– The combination of actions can be done in either mode: “Open” in portrait, turn to landscape, then “Change”, turn back to portrait and “Save”, last turning and “Close”.

*This also has disadvantages:
–    It takes away from the user experience.

Users use the device in any orientation they like. The majority (?) of apps enable this specific user experience, which is a unique selling point of the device.

–    Inefficiency, wasting of potential: Sticking to the “wrong” orientation (depending on the app and its purpose). Example: Sticking to portrait mode might not make use of the “wider” landscape screen.

Audio

Does it support audio? Can it be muted? Can it be adjusted? Can it be adjusted with the device volume sliders? Does it bring its own volume control? If yes, can both be used together? Using the device volume slider moves the app volume slider? Can it be automatically adjusted? E.G. when phone calls come in? When overlays happen? Can it handle headsets or other jacked in audio devices (stereo set, car jack?)

Objects

This is at the moment a kind of placeholder for me. I am thinking of the developed structure, the code, the files it installs on the device, but also new ideas which might come up.

This is an interesting read, where shaped flowerpots are used to draw corresponding leaves on an iPad: Article Video

Landscape

Same as in Portrait, needed the “L” letter to make a nice heuristic word

Overlay

What is overlay? Overlay is the message pop up of one app, while the user is in another app.

Does it support overlay? What other common apps use overlay, that will *most likely* pop up? Skype? Facebook? Other chat tools?

How does it handle the overlay? Could there be data loss for the user, when the overlay happens? Is there a choice for the user to ignore the overlay? Is there a timeout for the overlay? What happens, when the timeout comes? Will the overlay disappear? Or come back in x minutes?


Hint: How to make a iPad if you don’t own one: iPad Testing Ideas

Origin: The idea started on twitter (24th September 2010) with a question from @Siggeb: “I am testing a new cool Twitter client for the ipad;) give me some test heuristics .” At time i quickly sketched PAOLO and now i found the time to fill it with some life.

Overview about Weekend Testing chapter and their timings

JPG image with sorted chapters by activity status

For me, who is always easy to confuse with “global” times, I need an overview in a sorted way. So I created this Excel table for myself and share it here; maybe it could be useful for others as well.

The information are not complete yet, need some time to ask Ajay or Pradeep for more information. OR I take the info from any comment here and incorporate them.

Mental note: Find out how to insert tables properly. Current attempts failed miserable. 🙁

Mental Note: Forget tables for now. Screenshot should be “good enough” for my context. 🙂 Still need to make the text searchable.. at least thats what I like to do.

Todo: Add links to facilitator blogs and twitter IDs. etc.pp => cleanup!

Update 12.01: Added WNT and Activity for WTANZ

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.