Software And Testing

Swiping on a touch screen

We had already a few months a problem on the machines touchscreen that our interface behaved differently with a finger swipe as with a mouse drag and drop. The problem was that swiping from left to right was navigating to the previous page. And swiping the other way around was taking us to the next page.

Because a customer does not need to know that our interface is in fact a html page, this is unwanted behavior from user testings point of view. In the options of Chrome itself I could not find any options that could explain this behavior.

But there is a solution. Just start chrome or chromium with a command line switch.

--overscroll-history-navigation
Did you know that chrome has a lot of command line parameters? Look at Peter Beverloo’s page for an overview.

You see, as a tester you also need to think how we can solve bugs, because not all bugs are code related.


License To Kill

During the process of setting up a protractor test framework, I had some problems about our system. It was again the same problem as I had before. The intension of the test framework is that the testing framework can run on our integration server. So this means after each build or maybe only at night, because this contains end to end tests and running them can take a lot of time in the future.

To run on the GUI, the protractor tests need to start up a backend. That seems logical, isn’t it? Then the tests are running. Afterwards, the backend needs to be shut down. This is where the problems begin. Our system is not setup with automated testing in mind. This means that there is no way of shutting down the backend. How do I shut down or kill that process then?

There seems to be a solution. In windows, there might be a command that is called taskkill. This program acts like the kill command in unix environments. It is not that good, but it can kill the cronos.exe backend from a batch file when the tests are done.

The command I placed in my scripts are like this:

taskkill /F /IM cronos.exe
After that I can run my test script again and again without worrying about remaining processes.


Test Reports are Dead

At the testnet conference, I attended to a talk of Gerlof Hoekstra. According to him our test documentation is not readed by anyone, or maybe even misinterpreted. This because they only contains figures and no real story. It looks that he has remembered the previous talk, but he has a point. Should a Tester give an advice to our developers to release or should the content of a report be so clear that everyone can decide for himself if the product can be released?

To have documentation that does matter, that is usefull, we should act like we are the reader. What does the reader wants to know? Take for example a weather forecast. What does the recipient want to know? He wants to know if it is going to rain tomorrow or if the sun is shining. So a prediction of the future. The weather report is short and visible, with maps and symbols.

Why should we not use that kind of things?

So instead of a report, it is better to have a stream of information. So Why not make information available at any time. But how detailed we want to have our reporting? Depends on the reader. Some of them wants to know if a requirement or user story is ready. Others want to know more detailed. This can also be put in a kind of daily blog post that we can share across our organisations.

This idea is a nice one I think. Why not blog more in the company to share ideas or forecasts of the project?


The Art Of Storytelling

The opening keynote was a very interesting one. In fact the complete event was a great day. Vipul started with a quote of Joseph Campel. "Everything begins with a story". Is it? Maybe it is. That is why in agile projects we use user stories. We create a little story about what we are going to do the next days. It is written in a kind of story so that it is more easy to remember. Stories stick more to our minds, isn't it?

A few stories came into his talk. For example the story about blind men and an elephant can be used in a testing context. We must see the complete system or we can interpret the things we test wrongly.

But most of all, the story must be adapted to the recepient. He told a story about acrobat and fonts. One guy wanted to have acrobat on his palm pilot, or was it a palm phone? This man wanted to show shome fonts that was not supported, and the person of the helpdesk explained in detail why it should not work. He even gave an example of a font that the recepient wanted to use. But he did not ask that in first place. How did the helpdesk did know that the person wanted to use that font? Because his name was a common name of the sikh people and these fonts are commonly used by those persons.

So you must use in your story the viewpoint of your recepient. In that case, you have a better communication.

He also told a story about regression testing. But in the form of going to the dokter. He had some lever problems and each time he went to the dokter, he did a scan. But also his heart and so where investigated. Suddenly after a time, his heart was not good anymore, but he did not see that until it was too late. What he missed was that during the previous scans, the values where raising. Is this also not in our real testing world like this? If we do regression testing, we do not see that for example the system is slowing down until it reaches a threshold and then we ask to ourselfs, why is that now, but what we did not see is that the problem occurs many monts ago.

So story telling is needed and can be usefull to remember somethings. It is also that stories give other knowledge than scientific knowledge. And for that they are remembered better.

I should have to think now how I can apply this story telling in my daily work. Maybe by creating bugs or by explaining why the bug is relevant? I really want to try this the next weeks.


Testnet Conference April 2015

Yesterday, 30 april there was a conference in Nieuwegein, Netherlands. This event was organised by Testnet, an organisation for Testers in the Netherlands. I attended there several very interesting talks. The conferences organised by Testnet are always having a theme. This time, the theme was documentation.

In the morning, I attended a workshop about Visual Modeling for test idea generation. The workshop was given by Vipul Kocher. A very interesting talk. He began with explaining that a model is a simplification of the reality and does not have to be perfect. A model is never the end goal. The real product is. Because most people remember images better than text, it is better to have an image as model. To create models, it is a good idea to ask Context Free Questions, like Michael Bolton already explained many times.

In a second part he asked a question that kept me thinking and I should really ask the question to myself to solve it. The question is simple: "How did we learn to write testcases"? According to hem the best way to learn is by looking at examples. "SHOW IT", is the key word here. But showing it is a very intense way of learning. It is also very time consuming. So he asked the next question. How can we make this process much simpler? The answer is very simple, Just use the nouns and verbs test idea that Elisabeth Hendrickson explained in her book "Explore It!".

In the second part he mentioned that Joris Meert has written a fantastic paper that we can use to create models. Of course he explained an example of how he create test ideas. Not all test ideas ends in a test case, because then we end in hundres of tests.

It was an amazing workshop and I got some ideas on how I can generate test ideas when I am planning my test cases.

In my next posts, I will give some impressions of the talks I attended.


Pycon 2015

The python video's for pycon 2015 are online on youtube. The Link to the videos is here. Pycon 2015 is even not finished yet, and a lot of videos are already online. They are faster and faster each year. Let's hope the topics are as interesting as each year.

I do not have a lot of time left, but I definitely want to see a lot of them so I can learn again new things. Last year I learned a lot about asyncio and generators. Maybe I learn again some new features that are present in python 3.

Happy watching.



How to show the current revision?

Sometimes I want to know which is the current revision in a repository that I am on. I always did just git log and watched the output. But log has some nice features, it can almost output everything you like it in the way you want. To show the short revision number, just running

  git log --pretty=foramt:'%h' -n 1 
is enough. Of course you can create an alias for it:
  git config --global alias.revision "log --pretty=format:'%h' -n 1"
I hope this is a usefull tip.


Explore It

I am at the moment reading some books. One of them is the book Explore It! written by Elisabeth Hendrickson. The book is divided into three parts. At the moment I have finished part 1 and I must say that I did have found a lot of new ideas for my daily testing job. Specially the charter chapter is very usefull, because now I can place a charter as a scrum task on our scrum board. Very pleasant to see that now our developers know what part of the system I am testing at.

I also created a sketch note of the first part of the book. I place the figure of that sketch note into the public domain because I think it can help some other testers too. Note that this is not a summary of the book, but it is my view on what I need at this moment in my current job.