How to tie your shoes?

Reading Time: 1 minute


In this blog post I would like to share my excitement how I improved my shoes tying craft and what does this skill have in common with software testing.

Some time ago I bought my new adidas special shoes, and I was very happy. But not for very long time. Shoelaces kept untying on and on. I was very unhappy with that fact. What is going on!?

I Googled: “My shoelaces keep untying” and I found following TED video.

I was taught how to tie shoelaces the easiest way, which was not the right way for shoes with nylon laces.

I was impressed with shoelaces physics, how simple change in one step can significantly change the outcome.


This blog post is a working example how we should always question our software testing skill. If we have been doing software testing in same way as we were taught at the beginning, maybe is time to question our software testing skill.


Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Alternative flow in my neighborhood store

Reading Time: 1 minute


In this post I will explain how I tested alternative business flow in my neighborhood store. No computers, no automation, just human interaction.

Few months ago, my local store put a big sign with a business flow:

“If you find that item price do not match, or it item does not have a price tag, we will charge you only half the price.”

For one of my items I do not remember the exact price, but my heuristic is that this item should never cost more than 6 $. And this time price on the register was more than that amount.

So I reported my issue, and pointed to the big sign on the wall (consistency heuristic with claims). They confirmed me, but immediately started with excuses, why the price did not matched. I did not hesitate, show me my money!

So they put me aside, because that alternative flow required some processing of my invoice through their system. Lady at the cash register did not know how to do that, so they asked for the manager. In the end I got my money back.


When you find an issue in product that you are testing, always report that issue. They will use against you various psychology tricks to persuade you that this is not an issue.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Product moving parts as source for test strategy

Reading Time: 2 minutes

In this post I will explain how I identify product moving parts (what changed in product) as a source for test strategy of product release.

Tools that I am using are Github and Huboard. Everybody knows github, and huboard is application that integrates with Github and creates Kanab board automatically from Github issues. The glue between Kanab and Github are Github labels. Github label assigned to the issue puts that issue in Huboard list.

What are tools if they are not used by humans. Every issue could be an issue or new feature. Their body should contain text that help me to understand what should be implemented. No help of tools if that body is poorly written.

Every huboard issue is connected with Github pull request. Pull request contains all files that are related with that issue. By investigating github pull request, I am identifying product moving parts.

As the application context is Rails application, pull request contains application and data (database migration files) changes. As rails uses MVC pattern, this helps a lot how to direct my testing. For example, if change is in view, controller or model file, I know which feature and scenarios I should test.

If change is in helper file, by searching the codebase for the changed method, I can also identify features that should be tested.

Rails has rake tasks, which are also under github control. If there is change in rake tasks, I know that some scripts should be run in order to prepare environment for the new feature (for example, populate database with static data).

What are the benefits of this ability to identify product moving parts? I do not need to run single browser automation test!

All the testing is done using my brain, eyes, hands and browser.

Browser automation tests are usually developed as part of regression tests. We often hear: “We are running our cucumber tests to be sure that nothing is broken”.

This is not good practice. This is like putting patient again and again through x rays to be sure that he does not have pneumonia. But asking patient questions about his physical conditions can give as quick answer about possible pneumonia.

Instead of putting hours of work in creating scripts for browser automation, try to organize your project  to have:

  • code base under git
  • use kanab boards
  • use branches
  • learn basics how product code is organized (MVC in Rails)
  • learn basic about programming language that is used (Ruby in Rails)


Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Zagreb Software Testing Club #24 report

Reading Time: 2 minutes

Last Tuesday we met on Zagreb Software Testing club for the 24th time at Club MaMa. This is short report about this meetup.

First of all, I would like to acknowledge Irja Straus! We usually met every 2 months, but as Zeljko and I are very busy, we missed one meetup. So Irja was proactive and organized this meetup. Thanks Irja!

And this is important lesson for every meetup. In order to keep meetup going, you need to build local community and delegate work. As on every meetup we already have familiar faces, I think that Zagreb STC have bright future. And important thing is that we had some new faces!

We had two talks. I talked about how to use docker to run headless chrome selenium tests in docker image. This blog post talks about how I successfully configured docker for headless chrome testing, and this post talks about how docker drove me on journey through the rabbit hole.

Irja talked about book by Gojko Adzic: Fifty Quick Ideas to improve your tests. She red the book and presented how she used those ideas to improve her testing.

After the official part, we continued testing discussion in nearby pub. We thank Tentamen for sponsoring two rounds of drinks.

And bonus. If you are thinking about starting up software testing meetup, here are few advices.

Go to, join Software testing Group and ask me to add you as event organizer. This is great group with more that 1700 testers around the world. Name your event with your town name and that is. With that, you will make your event visible to all members of software testing club.

Find local venue. Your company premises are very good starting point.

Start with easy pace. Schedule meetup every 2 months.

Arrange some drinks and food (pizza). If you can not find sponsor, spent your money for the first meetup and let everybody know that you are the sponsor. Contact Rosie Sherry through meetup, because she recently announced that she can help with Software testing club event sponsorship.

Build local software testing community and do not give up!

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

How to prepare cucumber with tables in Ruby

Reading Time: 1 minute


In this post I will explain how to handle cucumber tables in the “Do not repeat yourself [source]” principle.

Data Tables are handy for passing a list of values to a step definition:

Given the following users exist:
 | name | email | twitter |
 | Aslak | | @aslak_hellesoy |
 | Julien | | @jbpros |
 | Matt | | @mattwynne |

Here is my first take how to index that data that was not DRY:

class UserListPage
 include PageObject
  data_map = {'name => 1, 'email' => 2, 'twitter' => 3}
  div(:name, :id => 'name')
  div(:email, :id => 'email')
  div(:twitter, :id => 'twitter')

And using that data_map in step definition:

Given /^the following users exist:$/ do |table|
data = table.raw[1]
on UserListPage do |page|
  data.each {|row|
    expect( eq row[page.data_map['name']]
    expect( eq row[page.data_map['email']]
    expect(page.twitter).to eq row[page.data_map['twitter']]

There is no need for data_map attribute, because table object already has this data. Dry version:

Given /^the following users exist:$/ do |table|
data = table.raw[1]
header = table.raw[0]
on UserListPage do |page|
  data.each {|row|
    expect( eq row[header.index('name')]
    expect( eq row[header.index('email')]
    expect(page.twitter).to eq row[header.index('twitter')]

And do not forget to remove data_map attribute from page object class.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather