Orienteering for Software Testers – The Cunning Planner

June 11, 2018 | Author: Jani Haikala

What do you know about orienteering? If you are not familiar with the sport here is a Wikipedia definition for you: “Orienteering is a group of sports that requires navigational skills using a map and compass to navigate from point to point in diverse and usually unfamiliar terrain whilst moving at speed.” If you haven’t tried it I highly recommend it! In this blog series I talk about orienteering from amateur’s point of view and link these observations to professional software testing.


The map above is from a local orienteering event in my hometown of Oulu, Finland. We discussed about the map in previous article. Now I’d like to draw your attention to the controls. They are marked with a circle and a number and there is a total of 19 of them. These controls form a course. A route from which the orienteer is expected to find all the controls in predetermined order and preferably as fast as possible.

The planner is the person who plans the courses. Controls are often put in places that are not the easiest to find. In addition, the order of the controls is thoroughly thought of to give the orienteer extra challenge. For example, the terrain between two controls might be difficult to advance and the direction you are closing in to a control does not help finding it.

Consider that these controls are the features that needs to be tested. Places you have to visit in the software during the testing session. In this context, are the controls challenging enough and in what order does the tester visit them? I am quite sure that often testers do not set additional challenges for themselves. Suddenly the planner is the tester’s best friend giving the tester the opportunity to cut corners.

Orienteering lesson 2: Testers need to form a challenging course for themselves. A friendly planner gets caught sooner or later.

Orienteering for Software Testers series:

  1. A Map Full of Nothing
  2. The Cunning Planner
  3. Are You a Racing Snake? 18.6.2018
  4. An Army of Donkeys 25.6.2018
  5. More Coverage from a Relay 2.7.2018
  6. Bulletin of a Champion 9.7.2018

Orienteering for Software Testers – A Map Full of Nothing

June 4, 2018 | Author: Jani Haikala

What do you know about orienteering? If you are not familiar with the sport here is a Wikipedia definition for you: “Orienteering is a group of sports that requires navigational skills using a map and compass to navigate from point to point in diverse and usually unfamiliar terrain whilst moving at speed.” If you haven’t tried it I highly recommend it! In this blog series I talk about orienteering from amateur’s point of view and link these observations to professional software testing.


The most important tool for an orienteer is the map. It describes the terrain using various symbols. This includes landforms, rocks, water, vegetation and so on. No reason to list every symbol here. I think I don’t even know all of them. You get the idea.

Depending on the orienteering event you will see many kinds of maps. In smaller events you might get a map that hasn’t been updated for at least couple of years. Most likely the terrain has changed during that time somehow.

Bigger competitions obviously put in more effort. For example, in the world’s biggest orienteering relay Jukola – held in Finland – the mappers work couple of years to produce a map worthy of the event. A good map is both accurate and readable. Two requirements that don’t always go hand in hand.

To sum it all up, the degree to which the map matches the terrain varies. When the orienteer gets lost the map often gets the blame. Sometimes it’s justified, sometimes it’s not. Does this sound familiar to you as a user of multitude of different apps?

Now consider that the terrain is a software you are about to test for the very first time. How good is the map you are provided with? Sure, usually there’s a bunch of requirements to give you an idea of the software and it’s features. Is it certain that the specifications are actually flawless? Do they cover every imaginable situation? For majority of software out there I can state with certainty that the answer to both of those questions is “no”. Sometimes the tester is even sent in the woods with a blank map!

Orienteering lesson 1: The tester has to act as a mapper. Explore and build a more detailed picture. Produce information of the software that wasn’t yet known.

Orienteering for Software Testers series:

  1. A Map Full of Nothing
  2. The Cunning Planner
  3. Are You a Racing Snake? 18.6.2018
  4. An Army of Donkeys 25.6.2018
  5. More Coverage from a Relay 2.7.2018
  6. Bulletin of a Champion 9.7.2018

Habituality has a Destructive Influence

October 5, 2017 | Author: Antti Niittyviita

The boss throws the ball to Leena. “Can you remember how this problem was previously solved?” Leena remembers. “By piecing the problem like so, and focusing on details instead of the big picture.”

One year later Leena is already an executive, and shares the solution she remembers along to the firm’s new boss man Jarkko.

Jarkko, unbeknownst to him, gets a taste of the firm’s culture. After he has seen enough mornings in the firm he realizes: Big firm, Big turning circle. The culture needs to stay constant, without creating new memory traces.

It is true that routine is not a bad thing. It provides a sense of security and in wise hands, also higher quality results. The danger lies in gathering dust and building routines to wrong places. Even smoking is half habit, half addiction.

From experience, I can say that a new pair of eyes find bugs without exception in locations where habit has started to run testing.

Testing for results requires discarding the traced routines that keep emerging from your memory. Habituality has a destructive influence, since blind spots are very good at hiding the best bugs.

Which is why  I ask if it would be useful to re-organize the dynamics of your team? Even if a red alert was not upon you?

Break up routines. Refine your memory traces with the right kind of thinking. Combine familiar things together with fresh methods and later on you might be able to provide a wiser answer to this.

Is Pavlov’s dog the work horse of your team, or the CEO?

The Dating Game Trip with a System Provider?

September 26, 2017 | Author: Antti Niittyviita

The familiar theme and the familiar host. Priceless.

In the seat of A sits a reliable and assured IT-systems provider, who avoids tailoring. In B’s seat, is a very confident king of interfacing, for which nothing seems to be impossible. As for C, his middle name is ERP.

Behind the curtain is the buyer X, who is sweating in suspense. His dream a joined venture involving only jumping in joy. Gladness brought about by success. No shy looks or awkward fumbling of a first timer. Who would want that, when you could have someone ready to get to the second base?!

Testing and running a prototype is both hard work and expensive.

A, B and C are each professionals of their field, and each one of them a good choice for someone walking their path. But does X’s choice always land on the best option out there? Can you know, before you have experienced living together, eating lunches and gone to the irrevocable Dating Game trip?

  1. The salary system renewal in Canada anywhere from 3 million to 126 millions.
  2. The IT-project of the city of Kajaani anywhere from 1 million to 3,5 millions.
  3. Oriola: SAP failure, price tag unknown for now.

Is it so, that we already have so many interfaces and pieces that it is impossible to have a package that can actually server the business? Wiseguy could already point fingers at culprits. But could it be, that the fault lies somewhere else but the providers and requesters of IT-projects? Along the years, the system has had layers upon layers added onto them. Each actor does their best in an impossible situation.

It is no accident that I increasingly come across development teams, who have decided to toss decades of baggage behind and recode their products again. It is not only the cheapest, but also the fastest solution.

Fitting and taking up a new system demands a lot. It demands in-depth learning, and a solid grasp from especially the buyer.

What if a tester would be X’s saving straw on their trip to becoming millionaires? 50-50, and phone a friend :D

The French Bouncer

September 20, 2017 | Author: Antti Niittyviita

I was sitting in a café in London last spring, and observed a restaurant’s bouncer working on the other side of the street. I gathered him to be French. A jovial fellow, I think, and quite observant in his work.

A woman one step ahead: Accompanied by a real gentleman. Or a mitten. It is difficult to say. But the bouncer was on top of the situation. He took one step ahead of the couple and threw some comment over his left shoulder to the woman, which made everyone laugh. Two steps and a stop. The couple checks the menu and agrees to go inside. The game is on!

A family of three: The father was walking on the side of the road, the mother on the side of the shop windows, and the child dictated the pace walking between the two. The glib bouncer knelt in front of the child. He must have dropped a ball in his pocket to playfully start a conversation with the little boss. And he scores once more!

Grande finale: The last one was quite tough. The woman looked like she had just eaten a lemon. The man fed up with barkers. They both kept fiddling with their phones as they walked forward in pace. Yet, an unfailing eye and an icebreaker drew in the couple to ‘just take a look’ at the nice-looking menu on the street.

My mouth fell open in amazement as the observant expert also dug up his phone and joined the couple. TripAdvisor must have done its mission. Three goals in three minutes. I was impressed.

The French bouncer is successful, because he does not play the game to get to make his own sales speech. He concentrates on two things past himself. The result, and the person he is facing.

Who do you serve? Do you know your client and your goal, like the French bouncer did?

The Egg of Columbus

June 29, 2017 | Author: Antti Niittyviita

Show me how to set an egg upright on this table.

So the story tells us of Columbus having uttered those same words when he had brought an egg to a funding event. The funders had not believed in the man’s vision of finding new worlds. They thought it was impossible.

Each funder had their turn to try and set the egg on the table. But for naught. The egg fell over to its side each time.

Finally, it was Columbus’s turn. The man snapped the egg solidly against the table’s surface. And there it stood. Upright, just like Columbus had promised. In hindsight, it is naturally quite obvious how the trick was done. Columbus showed the trick to the funders by demonstrating with one flick of the wrist.

It is easy and riskless to follow an example. But it is difficult to create an impression by hiding in someone else’s shadow.

A real guru has to traverse the path, which no one has yet traversed before. His mission is to trailblaze past the thicket, so that others may follow. But what would it require for you to be the one next time to walk ahead of others?

Find your own egg.

Response-based Testing

June 22, 2017 | Author: Antti Niittyviita

Of course testing is a work that is based on responses.

Testing is a continuous dance of clever exploration and the responses it gets. To us testers, it is merely natural, since we indeed are technically oriented people.

The bugs we discover and the information we produce are responses which we are mostly in search for. It is what we direct our attention the most, if at all possible.

But, what if no one cares? What if, the results of our work are spectacular, but no one bats an eye when presented with them?

Our results ought to be junked, if no one is ready to change their thoughts or actions based on them?

The are two likely reasons for that painful result.

  1. The results of the work are so useless, that no one actually gives a damn.
  2. The results of the work are important, but we just do not know how to tell about them in a sexy manner.

In both cases we should first stop and then look at what or how we start getting responses from our work. Response-based testing does not focus on response in the product, but in the response in people, who we get to serve. Be curious. Pay attention to the response that is around you, not the one that is in front of you.

Your work is only as good as the response it produces in your colleagues, clients and bosses.

Is Automation Not Your Thing?

June 1, 2017 | Author: Antti Niittyviita

I begin my day by wishing Siri good morning. Siri knows when it is the time to shine the wake up light in the bedroom, and when to light up the bright ones in the kitchen. Siri also knows how to start playing the energetic morning songs on the TV.

I feel like I am Tony Stark, even though Jarvis is still slightly smarter a sidekick in those Avengers-movies.

The television irrevocably beat radio in ads investments already by 1950. The print media has been in trouble for already 10 years, thanks to digitalization. Worshipping petrified statues of tradition have never really been a key to success. It has led to breaking apart.

I regularly meet testers in conferences and training sessions, who let it be known how that automation thing just does not seem to be their own thing.

I get a bit sad. They have jumped the train. Left to work at a field of sunset. They are on a guaranteed road to uselessness in the very same way the brands romantically hanging on to radio ads were already in the 50s.

I am not saying that the risk would realize itself already by tomorrow. Yet, in five years’ time one question remains.

Who gets picked up first? A thinking tester who knows the tools OR a thinking tester to whom automation does not really feel good?

Performance Indicators and Testing

May 25, 2017 | Author: Antti Niittyviita

I recently came across an interesting Twitter-conversation. Two leading testgurus pondered how to organize testing-related performance indicators (KPI) for an organization, since the organization demanded for some.

First, a question arose in my mind. If an organization demands them, what actually is going on is that one or a couple of people in the organization demand them. I would be very interested in meeting them. Who are they?

People who wish for KPI-meters have quite often already an understanding of what they would want to measure and why. The easiest thing would be to ask them.

If there is nothing else to be done but to build a presentation about the subject, I would recommend something simple and concrete. For example, I could start by making a tally of things that consume most of my time. Hourly resolution would be quite decent for this end.

  • Prepare: I prime environments, produce data and document
  • Test: I hunt bugs using methods that work for this end
  • Explore: According to my discoveries, I explore and report defects
  • Braindeath: I sit at a meeting. They might need me in some of them, but often not really. I collect KPI-data from here and there and data mine it in Excel to a more spectacular form etc.

In one weekend the picture starts to form. In which area of work I spend most of my time and whre should I be spending it instead, so that my colleagues, managers and clients would get the most out of my testing?

If what I do is mostly prepare and tune, it can mean that the developers ought to put mre effort in testability. If I mostly explore and report bugs, it can mean that the software is not at a mature level. If I mostly sit at meetings and gather KPI-data, it can mean that the requirements of the organization are no longer in line with its real goals.

Gathering data can feel useless at first. But let’s imagine a scenario where you have to give basis for your findings for your boss? What would be better than plain facts as metrics?

I challenge you. What were you working on this week?

The Wanking Schedule of Processes

May 18, 2017 | Author: Antti Niittyviita

I always miss a beat when I see a process diagram of testing. Especially when the diagram has first been created, and after that ought to be implemented.

This should now be implemented.

No can do. Often, the diagram has been created through thinking that is estranged from  reality, or from the restrictions of the testing tool bought for the testing. The priming of the working methods for testing happens dangerously often via the top-down method.

I scripted a more functional way.

  1. Choose a project
  2. Form a hypothesis, with the project in question, of better working methods
  3. Perform a short test. Prove the theory in practice.
  4. If it works, add it to other projects as well.
  5. If it does not work, tune it and re-test it.

Bottom-up model works better almost all the time, and the gang is also participating in the changes.

Wanking is always better, when you roll up your sleeves and start working. Visualizing is just a modest replacement.