Nordic Testing Days 2014 – Day Two

The second conference day started with a Lean Coffee session. The discussed topics included – How do you report/measure exploratory testing?, At what point do you accept context and don’t try to improve it?, What the future will bring to testing?. Two notes for myself: Immediately after the conference you might have a decline in performance, the increase can happen later; Are shiny eyes and being inspired enough of a reason for a company to fund going to conferences?.

The first track of the day was by Rikard Edgren “Good Testers Are Often Lucky – Using Serendipity in Software Testing”. Notes from the track:

• Serendipity – finding something valuable, when looking for something else
• Create opportunities for good luck
• Background Complexity heuristics
• Do One More Thing heuristics
• Notepad heuristics
• Galumphing
• Apply diverse half-measures. Lesson 283 from “Lessons Learned in Software Testing”

The first track after the lunch was by Erik Boelen “Mobile Test Strategy Made Successful”. One recommendation we want to try at work is creating a generic list of test cases applicable to ‘each’ mobile application. Two nice notes for me to remember:

• Before you act, LISTEN!
• Before you react, THINK!

The last track of the day was by Pete Walen – Test Leadership Lessons. Some notes from there:

• Leadership != Management
• Good testing isn’t magic, it just looks like it
• Sometimes the cool technical solution is not the right one.

Then it was time to catch the train back home. Two conferences in two weeks was quite intense. I got to talk to a lot of interesting people. Changes to come from the learnings I cannot yet fully predict.

Advertisement

Nordic Testing Days 2014 – Tutorial and Day One

In the beginning of June the Nordic Testing Days conference (http://nordictestingdays.eu/) was taking place in Tallinn. The program was so good that sometimes I had a really difficult time in deciding where to go to. For the second time a tutorial day was included, and for the first time I participated in it. There were five tutorials to choose from and there were four that I would have liked to participate in, but I could only choose one. I participated in the ‘A Day Of Lean Software Testing’ (by Matt Heusser and Pete Walen) tutorial. Before the tutorial there was a Lean Coffee (http://leancoffee.org/) session as well, but I didn’t participate. I had read very little about lean prior to the tutorial. I looked at it as ‘something new to get a glimpse of’. We did some group exercises and tried to be as effective as possible. After the first round we tried to describe the wastes, and in the second round tried to minimize the wastes as much as possible. What also became quite clear, was, that when someone ‘sees’ the product in their head, then it’s really hard to describe that to other people, so that they would see it in the same way.

Some thoughts that stood out for me:

• Do small changes continually
• Don’t load up to 100% efficiency
• Think of effectiveness (get the most products out the door with as good quality as possible)
• Maximize throughput
• Think of touch time
• One story as work in progress
• If your predictions are based on average, you’re wrong half the time

The first conference day started for me with a lean coffee session (having missed the first one the previous day, I made sure not to miss the other two). We discussed lean, improvements and end-user testing. What stood most out for me – Reflect on how much improvements you use. Then came the official opening of the conference and the first keynote – Testing in the Automation Age (by Jevgeni Kabanov). We were told the story of testing in ZeroTurnaround. One thing that was mentioned, the CEO testing (testing by someone (not a tester) who doesn’t use the product regularly), I want to try at the company I work for. Then came the ‘Exploratory Testing Dojo’ by Huib Schoots. I could practice note taking among other things. I got reminded to – Take notes to improve yourself. We did group exercises and I was fortunate enough to be part of a really smart group. After lunch I went to listen to Ruud Cox, who did a track on ‘Drawing to learn’. I want to get better at note taking and I think visualization could help me with it. Some thoughts from the track (notes for myself):

• Start sketching, try to ‘see’ the image in your mind
• Focus-defocus, experiment
• Come up with a good model of the system
• Be aware that mental models are inconsistent
• Why use sketching? To clarify, to create new ideas
• Models expire
• Start with different elements, then bind them into one

Then came Stephen Janaway’s track – Testing Your Emotions – and how you can apply some personal leadership to keep them under control. Some notes for myself:

• Emotions are not feelings, moods, affects
• Feelings – manifestation of emotions
• Emotions can have a powerful impact on memory
• Be aware of emotional bias
• Emotional models – Robert Plutchik, Hugo Lövheim
• Think about what the customer could feel.

The last track of the day was by Gitte Ottosen who talked about ‘The life of a pragmatic tester – the best of two worlds’. I realized I’m not a pragmatic tester. Should I become one? Would it be easier to be one or not to be one? Is pragmatism relevant for me? The first conference day ended with a keynote by Matt Heusser and Pete Walen – On Complete Testing. I guess I’ve been quite fortunate to never having been asked to test a product completely.

My PEST 4.5 – Focused Problem Solving – “Visualizing Testing”

PEST 4.5 was my first PEST participation. I liked the theme a lot. I like using mind maps for writing down ideas for testing. I hoped to get inspiration to continue using visualization in my work. There were five participants there (Kristjan Uba, Helena Jeret-Mäe, Oliver Vilson, Rudolf Elbrecht and me).

There were four topics to choose from:

• How to display current situation – Feature/Area vs. Bugs/Severity
• How to display current situation – Test Coverage
• How to display current situation – New Feature/Area vs. Risks/State of bugs
• How to display current situation – Current State of the Product/Project

For each topic we needed to consider two aspects:

• Current state,
• Iterative (trends, history, etc.)

There were four bug categories described:

• Major,
• to be fixed for next release (Next),
• hard to reproduce (HtR),
• Small.

The task was to create a visualization (as easy to grasp as possible) that showed what was OK, what was not OK, which features were new, etc. We were given an electric bicycle, to choose any part of, as our product. I chose the tracking of cycling. We didn’t need to concentrate on specifics of the example (electric bicycle), we could use abstraction. I created three representations for my topic – Current state of the Product/Project.

First Representation

My first representation was a list really. I tried playing with different colors.

I used:

• gray for project name
• purple for new features,
• black for old features,
• red for major bugs,
• orange for the bugs to be fixed for next release (Next),
• pink for hard to reproduce bugs (HtR),
• brown for small bugs,
• green for when the feature was OK.

For each feature I added information about the number of bugs of certain category (Major, Next, HtR, Small) that were not yet fixed. I also added information about the bugs (what the bug was about). I realized early on that a list would be too much written words at once (so not easy to grasp), but it helped me to figure out which information to display and as it turned out, also which colors to use.

This is how it looked:

Second Representation

I then thought: what about drawing something, e.g. rectangles. I divided the features between two columns – new features in one and old features in the other. I used the same colors as in the first representation. Under each feature name I added the number of bugs found during testing. The number of bugs would expand to give a short description of the bug(s).

Each feature had a rectangle around it. The color of the rectangle represented whether the feature was a ‘go’, a ‘no go’ or a ‘so-so’:

• only green – go,
• only red – no go,
• a mixture of green and red – so-so (green as the top side of the rectangle – a bit more towards ‘go’; red as the top side of the rectangle – a bit more towards ‘no go’)

This is how it looked:

Third Representation

Then I thought I would do another representation and use a mind map for that. I used the same colors as in the first and second representation. The idea was, that you have the features visible at first (i.e. only the first level bubbles). When you want to see bugs related to the features, you need to open corresponding sub-level bubbles. After looking at the image for a while I decided to add smileys to have a more ‘apparent’ visual sign (J – go, L – no go, K­ – so-so). I got the smiley idea when I remembered Sami Söderblom’s track from 2012 Nordic Testing Days.

This is how it looked:

 After the presentation

… the questions time arrived. During that Kristjan Uba pointed out that I only have features on one level and suggested that features could be partitioned and their state displayed like this (red indicates ‘no go’, green indicates ‘go’ and yellow ‘so-so’):

 So, did I get inspired? Yes, I did.

The post that was supposed to be about Let’s Test 2013

In May I had the chance to participate in Let’s Test. Now it’s September and I’ll take a little time to reflect on the experience. I’ve found it challenging to write about it, as it was a lot more than I hoped it would be, and for some reason it feels a bit like lessening it’s awesomeness by writing about it (or maybe I really just don’t want to share it via the WWW and want to keep it to myself (and amongst my colleagues)).

Let’s Test 2013 was the second conference that I participated in. Unlike the first one, where my notes consisted of two sentences, my Let’s Test notes filled 15 pages in my notebook. One thing I have realized while re-reading them, is, that I need to improve my note-taking skills.

So, what and how do I write about my experience?

• Should I list the keynotes, workshops and tracks I participated in? (and what I learned from them?)
• Should I write about my personal gain?
• Should I write about the changes that have happened since (and speculate what else will change)?
• Is another blog post necessary when there are multiple excellent ones already out there (you can just Google)? (I guess when I want to practice writing it could be necessary (for me).)
• What can I say that hasn’t been said already? (Should I say what has been said already?)

I actually thought I had it figured out (this here was my fourth draft), and I could finally write about it, but I was wrong. I still don’t know how to write about it. So, until I do, this here will be it.