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.

Suunnistus1

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.

compass-3072065_1920

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

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.

Robot Framework, wxPython & OSX

May 16, 2017 | Author: Antti Niittyviita

LINK

Robot Framework paired up with RIDE is easy to install on OSX by following the original installation instructions. There is just one problem that has not been documented. wxPython 2.8.12.1 is a component that is a must to run RIDE. New versions won’t do.

Latest OSX does not support old .pkg packages to install the necessary wxPython and the file needs to be repackaged to succeed. You can either download a file I have re-packaged or do it yourself by following these instructions.

DOWNLOAD HERE

This is how you repack a .pkg file on command line with OSX:

#Find your way into a directory of your choosing and follow these steps.
$ mkdir repack_wxpython
$ cd repack_wxpython

#Now you place the original .pkg -file of your choosing into the repack_wxpython directory on your computer.
$ mkdir pkg_root
$ cd pkg_root
$ pax -f ../wxPython2.8-osx-unicode-universal-py2.7.pkg/Contents/Resources/wxPython2.8-osx-unicode-universal-py2.7.pax.gz -z -r
$ cd ..
$ mkdir scripts
$ cp wxPython2.8-osx-unicode-universal-py2.7.pkg/Contents/Resources/preflight scripts/preinstall
$ cp wxPython2.8-osx-unicode-universal-py2.7.pkg/Contents/Resources/postflight scripts/postinstall
$ rm -r wxPython2.8-osx-unicode-universal-py2.7.pkg
$ pkgbuild –root ./pkg_root –scripts ./scripts –identifier com.wxwidgets.wxpython wxPython2.8-osx-unicode-universal-py2.7.pkg

#And this is what you should see as an output from the terminal.
pkgbuild: Inferring bundle components from contents of ./pkg_root
pkgbuild: Adding top-level preinstall script
pkgbuild: Adding top-level postinstall script
pkgbuild: Wrote package to wxPython2.8-osx-unicode-universal-py2.7.pkg

The Professional of Love

May 9, 2017 | Author: Antti Niittyviita

Have you ever visited dating pages? Or read dating classifieds in a magazine? I might have, but maybe I have not. So not?

In these kind of ads, they usually start with requirements specification. One has to be a teetotaller, with a sense of humor, go in for the same kinds of things. The height and age are important numbers, and so on. Whatever these properties were, the end result is always a pile of requirements for the future companion. Some of these properties are listed, but some may have not been brought up in the ad.

In the next phase they trade messages. If they do. Maybe even early one they will figure out that it is just not going to work. At some point what happens is that they agree on a date. People become familiar with one another. We collect more information of the other person. We scan for flaws. Whatever it is that each and every one of us does. Sooner or later, it is certain to encounter properties which are deemed less than ideal. These either form an obstacle for continuing the relationship-building, or people learn how to live with them. On the other hand, one might notice that the original requirement was not as important after all. I am sure you know how this progresses. Ultimately it is about testing.

The question is, how many would be interested in forming a relationship based on only the original requirements specification? Is it actually the case that the list of demands is always comprehensive, and no surprises or new perspectives come up later on? I doubt anyone thinks this way. Why would anyone presume that only going through the requirement specification should be enough for testing the software?

It is not necessarily beneficial to announce having been tested by a professional of love. Yet, a professional tester will go through all the surprising factors. Test a lot of other things in addition to requirements specification. You do have a professional tester, don’t you?

On the Dead Bed of an Organization

May 5, 2017 | Author: Antti Niittyviita

Underneath all the thinking we regard as ingenious and special we are still mere animals. As animals we are prone to form communities. It has been our lifeblood since the moment the first light of sentience lit up in the dim eyes of the life form we call our progenitor. As individuals we are lesser beings in the great cycle of nature, but as a whole we create forces which literally change the world around us. Our shared work of creation withholds all the potential what is the potential of our so called creator as well.

Yet, at some point in our journey, we have forgotten it.

Our achievement-centric thinking, the community that strives to reward individuals and which is primed for an eternal climbing of the ladder has along the years begun to erode our environment and especially ourselves. Power games, reaching for certainty, rules, plans, conditions and requirements have begun to define us instead of us defining them. People have become a part of the mechanical machine. A part, which can be easily replaced when required to keep the machinery running. We have given birth to a monster, which siphons our energy to maintain its own world. Because everyone wants to be important in some way and to hold on to their own success and  security, simple things suddenly become very complex.

A significant part of complex things in our societies are actually very simple.

The things that are not simple even after an objective examination are naturally complex. The nature does, however, have its own way of dealing with things the way it is required. In natural organizations every individual will gladly take the place that is most fitting for its real nature. The place, where they can sincerely serve the whole with all of their skill. Others are coders, testers, marketing or leaders… Yet, few however remember during their day to think about what we are first and foremost. We are animals, who depend on one another, who reflect their own image from one another, whose quality of life is in direct relation to the quality of life of other people, with whom they share same beliefs and spend their time.

Managers, bosses, bullyboys and all kinds of made-important titles and positions are a thing of the past.  The traditional organization is lying on its death bed, waiting for its last breath. From its ashes, however, is possible to arise something so much greater and more valuable and more real. The actual recognition and acceptance of the individual and community – an individual’s actions without striving to be more right than the other – provides the soil for growing evermore beautiful flowers. Like the Doctor, the protagonist of the favorite series of Yours Truly, Doctor Who, puts it:

The progress of the humankind is not measured with industriality, but with the respect for life. The unnecessary life. A life without privileges.

The value of an unnecessary life is the same as the value of the most necessary. It defines an era. It defines a species.

Next time you ponder, whose responsibility it is that something succeeds in your software project (or in whatever area of your life), you can stay worry free since I will tell you the biggest secret that our society would not allow anyone to share: It is your responsibility, dear friend. Do the right thing, the thing which serves the whole without evaluating anyone’s worth, the necessary thing. Do it by your own permission, without needing to ask anyone else for it. Instead of how you have been led to believe, no other person is in a position of power in relation to you, and neither are you in relation to them. You may experience forceful gales blowing against you as you do whatever it is that you will do, but at the same time you can experience the freshening wind on your face of something that is called life.

Responsibility is a Difficult Thing?

April 28, 2017 | Author: Antti Niittyviita

I have been pondering for a bit about people and responsibility. What kind of people take responsibilities and why? How does taking responsibility affect the surrounding people and why does the overwhelming majority of people try to avoid responsibilities.

Some time ago I read texts of Søren Kierkegaard, the father of existentialism, and in his mind, the illusion of becoming communal is what makes a person irresponsible. For example, religious communities are based on some higher power taking responsibility of their actions, and in business organizations the final responsibility lies on the shoulders of the CEO, whereas in a team one can work quietly without actually doing anything. When you are responsible, you are also responsible of mistakes and that is scary.

The one who takes responsibility is easily given power as well, and there is a lot of responsibility to go around. It is not in people’s nature to desire for responsibility, as it is unnatural and easy to relinquish. Everyone is ultimately responsible of only themselves, isn’t that how it goes? In many bigger organizations the responsibility is moved around, and for example a single tester does not really feel significant or being responsible of anything. What if you were to be?

I am responsible of bugs being discovered on time and that the client is satisfied!

Testers! Let us come together, except not quite, and let us assume the responsibility of breaking the illusion of a bugless software! When you show that you have actual responsibilities, maybe the developer will also believe that the bug you discovered is valid!