Aihe: ‘Software testing’



Habituality has a Destructive Influence

5. Octoberta, 2017 | Kirjoittaja: 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?

26. Septemberta, 2017 | Kirjoittaja: 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

20. Septemberta, 2017 | Kirjoittaja: 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

29. Juneta, 2017 | Kirjoittaja: 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

22. Juneta, 2017 | Kirjoittaja: 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?

1. Juneta, 2017 | Kirjoittaja: 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

25. Mayta, 2017 | Kirjoittaja: 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

18. Mayta, 2017 | Kirjoittaja: 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

16. Mayta, 2017 | Kirjoittaja: 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

9. Mayta, 2017 | Kirjoittaja: 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?