Category Archives: Test automation

Find The Button In The Room

Introduction

This is my second blog post in the Find In The Room blog post serie. In order to avoid any legal issues I sanitised my story. It is about software testing and IT: test automation.

For this story I will use the Cinema Hype VIP website.

Voice commercial:
“Are you tired to buy drinks and snacks for a child birthday party in a cinema?
Cinema Hype VIP website is here to rescue you.”
Author – that’s me: “Let me turn down the volume.”
[Presses a button]
Commercial [Loud voice] “Now you can order everything before setting a foot in the cinema.”
Me: “Excuse me. Let me mute the volume.”
[Presses a button]
Commercial: [Loud voice] “What are you waiting for?”

Me: [Surprised]
[Presses a button]
Commercial: [Silent]
Me: [Silently smiling]
[Presses a button]
Commercial: [Silent]
Me: “Test. 1 2 3. ”

Commercial: [Silent]
Me [Remains a few seconds silent.]
Commercial: [Silent]
Me [Looks a few lines up and down.]
Me [Remains a few seconds silent.]
Commercial: [Silent]
Me: “Ahum.”
Commercial: [Silent]
Me: “Someone is watching me from a few lines above.
Oh, I watched myself.”

The moment of approval

In my introduction I wrote several times about the button. It took me some effort to find the right button.

Now it is time for a real world test automation example. For my first big test automation experience I programmed the steps in Java. Selenium was used for the interaction with the website.

One of the most important steps of a website is pushing a button. These days a lot of deals are closed with a press of a button. Also online transactions need some key presses to pay. So I must be able to find a button on the web page.

Let me return to the Cinema hype VIP website.
My kid has a birthday party and all tickets, snacks, and drinks are listed. The only thing I have to do is to press a button.

The quickest way

Years ago I thought that there was one way to find a button.

  • Right click the button and select Inspect in the Option menu.
    An option  menu is shown above the OK button. The last menu option is Inspecteren or inspect in English!
  • Select the HTML code of the button and copy XPath.
    In DevTools  menu is shown above the HTML text for the OK button. This menu contains the sub menu Copy containing the option Copy XPath!
  • Give XPath to Selenium to find the button.
  • Pat myself on my shoulder.

Then my attention was drawn to the free online course of Andrew Knight, Web Element Locator Strategies, on Test Automation University.
So what did I actually use?

An XPath is basically a route description through the web page. And it can look a bit scary:
/html/body/div[2]/div/div[2]/button
This is of course automatically followed by Selenium. That is something programs tend to do. There is 1 huge problem. If signs change, then Selenium cannot find its way.

Let me use an arbitrary text on a letter and transform it to a more computer notation.

/Surrey / Little Whinging / Privet Drive 4 \/The Cupboard under the Stairs / Mr. H. Potter.

If his uncle would move Mr. Potter to a bed room, then the postman had still no problem with delivery. Same address and a decent room this time.

Would it a bit more convenient to address the letter to a mister called H. Potter? A muggle postman would have serious problems, if this Mr. is evacuated to an island before his 12th anniversary. But finding him is a Half Giant job for a bloke like Hagrid.

This would lead to:
//Mr. H. Potter

But computers need more details:
//Human[contains(text() = 'Mr. H. Potter`]

Find a button with text OK.In that case I would get something like
//button[text()='OK']

The HTML code of the OK is hightlighted, while the search bar contains the text “//button[text()='OK']” followed by the text “1 of 1”!

Let me give you a more precise translation:

  • “//” means “Find somewhere on the page”
  • “button” means “the first button you encounter”
  • “[text()= ‘OK’]” means with the condition, that the text is equal to ‘OK’

No idea

But this does not completely explains:
/html/body/div[2]/div/div[2]/button

  • “/” means “search directly under”
    “body/div” means “search the first div under the body”
  • “[2]” means the second, so
    “div[2]” is the second div.
  • The rectangular brackes, “[” and “]”, are useful, if I do not need the first , but another one in the row.

The website I was testing was created with a low code tool. This tool can be compared with an advanced presentation tool, which also builds a fully functional website.

With great power comes great creativity. This basically means, that certain things were not fully under control of the developers. As a tester I had to solve these problems.

Placing a button on a web page led to an explosion of actions. Lots of code were automatically added, but this led to names like 1_saveFiles.

So I used ‘1_saveFiles’. A fellow tester pointed out, that the low code tool could change the button name to ‘2_saveFiles’ at will.

So I focused on the last part of the string.
//Button[contains(@name, 'saveFiles')]
This means such much as
“Search a button with the name containing saveFiles”
Of course there is a faster way to address an element using the attribute id. There is no magic needed to find Mr. Potter, if we were on the same page.
//Human[contains(@id, 'Mr. H. Potter`]

By the way id is pronounced as at Eye Dee instead of it. If you want to surprise your big sister or brother test automator, then use a sentence like “That element had probably no id.” Don’t forget a little sigh.

TODO add picture.

In my case id was not always set. To make things a little more challenging for me a single condition was not enough.

This is an exaggerated situation:
//input[contains(@name, 'drink')]
This might lead to some drink

//input[@value = 'two')]
could lead to the second drink, second size of the drink, or second snack.

So I chose for two conditions:
//input[contains(@name, 'drink')][@value = 'two']

There were other cool tricks in the course of Andrew Knight. The described ones in this blog post were big time savers.

To be extended

Escape The Consultant Trap

During a talk at a test conference a consultant told smilingly to stick to customers. The woman next to me was bristling. Her company hired consultants.

Is there a way to make this situation more painful for me?
You bet.

As a test consultant I had given her a ticket for the conference.
Ouch.

A good consultant makes herself or himself dispensable.

Definition obliged

Looking at the Dutch job market there is a cry for test automation experts. Even testers with a few months of experience have a distinct advantage over the inexperienced testers. They have a proof that they can use the demanded tool. And they are hired.

So if a company really needs test automation and no candidates have been found, then a test automation expert is flown in. This gives the company a real advantage. Or wings for the intended pun.

What is the consultant trap? After a while there is a test framework and lots of scripts and impressive heaps of test data which must be executed, updated, and maintained. In good order.

It is like buying a car which needs intensive care. If it is neglected for too long, then the car will not ride.

All the test automation stuff can be compared with a car. The mechanic is the test consultant.

No consultant means no working test automation, which means no edge, less revenue, and stronger competition. The company is trapped. This also hurts the revenue.

Path obliged

There are some managers who would object with

  • “This is a proof of concept.”
  • “The product is at the end of the life cycle.”
  • “The consultant is only hired during the holiday of one of my employees.”

These sound like sound arguments.

In this blog post I want to focus on test automation experts who are the only ones to operate the test automation in a company.
That’s bad.

Suppose you are a manager and you have the task to improve test automation. Now you have to avoid the consultant trap.

But you still need a consultant to teach test automation to your team member.
Hummm.

According to me a good teacher doesn’t make the homework of a pupil. In terms of test automation a consultant is helping your team member with learning instead of putting all test automation in place.

Don’t touch everything.

Is there a way to determine whether a consultant is a good teacher?
Sure.

Ask to explain how to set up test automation in plain language. Or ask for possible first steps in your company. Other useful resources are recommendations of other customers, talks, or blog posts.

My suggestion is to keep the number of hours of the consultant low and the number of hours spent by your team member high.

My favourite way to learn something new is pairing. As a pupil I like to share the same computer with an expert while figuring out what is happening. The teacher (she or he) demonstrates things to me and then let me struggle.

Pairing is an activity for 2 persons. I do not like searching the right note with fast scribbled words on it because of the high pace of demonstration. And then interrupting my teacher who is teaching someone else in the meantime.

Attention!

While I was learning Test Driven Development, a junior DevOps engineer was watching every step I took.

Once in a while he made remark. Then I told my thoughts aloud and he would gently lead me to the right solution. He had an educational degree and earned my respect.

In short it is about finding the right balance between demonstrating and experimenting.

Another way for me to learn is exploring. Elisabeth Hendrickson made a nice concise format for this:
Explore < target > with < resources > to discover < information>.

I personally like exploring because of the hidden treasures I might find. Dungeons and diamonds.

OK. Back to the Example.
(No DeLorean included.)

A consultant could suggest something like
“Explore data driven testing with Postman to discover a concise way to maintain test scripts.”
A bit vague.

I tend to ask questions.
“What is data driven testing?”

A good teacher will give some examples:
“Suppose you buy 2 items costing 1 Euro each. What will be the total cost?”
“2 Euro.”

“And if you buy 4 items costing 1 Euro each. What will be the total cost?”
“4 Euro.”

“6 items for the same price?”
“6 Euro.”

“23 items.”
“23 Euro.”

“What did you notice?”
“The question became shorter. And you only changed the number every time.”

“So the numbers are data. What I described were 4 simple tests. In Data driven testing a tester or developer extracts data from the tests. So you only need 1 test with a set of data.”

“What would be a good to store the data?”
“A table like in spreadsheet program.”

And this conversation and experimentation could continue for hours.

After the session a debriefing can take place to reflect and determine new points of interest.

After a while I could explore on my own. If I get stuck, then I could contact the consultant.

Let me write about exploration of data driven testing on my own.
“What is the first place to look for?
I don’t like manuals.

Wait. This is cool:
TestAutomationU offers a free online course from Amber Race about Postman.

It contains a section about data driven testing.”

For the video I used sketchnotes for note taking. When I did some experimentation in this course, I used a word processor for notes.

Also now a debriefing is the way to reflect and to determine new steps. A consultant or colleague can be a person to speak with.

Proposal obliged

If there is a company where I would like to work, then it is the one with experimentation and growth mind set. It will earn my loyalty.
Hold my engineer degree.

As a manager you might complain about the time spent. As an Agile practitioner I would answer that competitors might outperform your company by learning and teaching.

In summary hire people with ability to learn and ability to teach test automation.
Thank you for your attention.

Okay time for the legal stuff.

Disclaimer: I have no experience with this approach to escape the consultant trap. I did not do any research. But I do welcome feedback.

According to me this proposal is agile. You learn and adapt. Luckily agile is in high demand.
Say Cheese.

Disclosure: at the moment of publication I wa jobless, so I was biased.

Tricky Driver Dilemma

Ability to learn

Decades ago I had a colleague without a driving license. In case of trouble he would take public traffic or got a ride of his boss. His boss decided to give him driving lessons during office hours. It saved the company time and money.

Suppose you have a delivery firm. Your company picks up packages and delivers them to the right addresses.

It takes about a few months to get a driving license for a car. But sometimes a motorcycle is more convenient. This will take another few months. If a lot of packages must be delivered, then another driving license for a truck is needed.

For super fast and expensive delivery you can use a spacecraft and …

This is the point, that a favourite quote of a project leader is used:
“This is no rocket science. ”

Searching testers

OK time for the real message.

Suppose you are a manager of a Dutch software delivery company.
You look surprised, but you mentioned Continuous Delivery. Let me continue with writing.

You happen to need a tester. On the Dutch tester job market there is a shortage of qualified men and women. The basic requirement is test automation.

A paper with "Qualified" lies on 2 steps "Advanced" and "Expert"

Why is test automation so hot?
My guess is DevOps or competitors.
But you are the manager and you have all the clues.

So you have to hire consultants to get things tested. And that is quite expensive.
At the end of the project or sprints you have less profit and less experience in your own workforce.
A graphs with a vertical axis with "Profit" and a horizonal axis with "Time" containing a red slow rising line with "Consultant" and a green steeper rising line with "Employed tester" above the red line

A graph with vertical axis with "Company expertise" and a horizonal axis with "Time" containing a red slow rising line with "Consultant" and a green steeper rising line with "Employed tester" above the red line

The only solution is to hire and train testers. Just like the driving license story it takes months and probably years to get testers at the right level.

New testers should be hired for their ability to learn. Of course you can wait, until an experienced test automation tester knocks on your door. Maybe you are lucky this year.

Basically you have a vendor lock in. You desperately need a consultant for the test automation.

A piece of paper with a picture of a lock and "Lock" lies on a step with "Expert"

According to me there are more unskilled testers willing to learn than qualified testers looking for a new job.

A tester is just unlucky, if he or she was not able to touch tools like Selenium and Cucumber during project or sprints.

Teaching matters

One of the things I learned is Zone of Proximity. If people are in the same zone, then they can teach each other.

Stairs with steps "Intermediate", "Advanced", and "Expert" on a floor "Beginner". A rubber band lies on the step “Intermediate” and “Beginner”

There are companies which really want qualified or expert testers.  It is too difficult to  teach test automation to testers with beginner level. In this case they are outside the Zone of Proximity. It would cost your company too much time and money.

Stairs with steps "Intermediate", "Advanced", and "Expert" on a floor "Beginner". A rubber band lies only on the step “Intermediate”.

  • A solution is to lower the requirements for testers and invest more time in teaching. This might attract more candidates.
  • The other option is to keep the requirements and hope high to attract the expert tester. Wait a minute. Wait a week. Wait a quarter.

In the ever changing world of software delivery you need a new edge: how well can you teach testers test automation?