Category Archives: Test automation

Being Sidetracked – Part 3

“At the moment I am writing a serie of blog posts about Test Driven Development.”
I looked to the recruiter. “You can understand it.”
I moved my view to the manager: “You can also understand it.”

Sticky note: let’s stick to the DevOps engineer.

Vegetable As a Service

The DevOps engineer wrote the unit test in Gherkin. The main advantage is that this language is easy to read. Have a try.
Given the version number is 15
When the file is read
Then the file will be processed

It is also easy to write. This example is in English, but it is also possible to use plain Dutch.
Gegeven een versienummer is 15
Als de file wordt gelezen
Dan wordt de file verwerkt

This is easy for people in Dutch companies. Nothing is lost in translation. It is easy to digest. No mindreading skills are needed.
The tool Cucumber provides a way to translate these sentences to a programming language like Java. A programmer has to code, how the sentences are translated.

When this little story is used by the computer, Java is used to execute this test. Yes, it is time for another cup of coffee. Which is the symbol of this language.

There are of course some people, who want to add some details to it. And yes, this is necessary.
Feature:
As an administrator I only want to process the right file list_20180525.txt, so that marketing managers can still process the data and generate reliable reports.

Background: file A

Scenario: 15 right version number
Given file A has version number 15
When file A is read
Then the file will be processed

Scenario: 16 wrong version number
Given file A has version number 16
When file A is read
Then the file will not be processed

All the text is put in 1 file, so all tests are nicely organised. A very important detail is, that file A is a complete valid file. This takes some time and some byte shuffling, but it is worthwhile.
So after 2 cycles of Red Green Refactor two scenarios were added in a feature file. These scenarios could be executed individually or in a group.

Then the cycle continued. The latest test was used frequently to assure, that the code was modified in the right way. The previous tests were used to assure, that the quality was the same. This led to a massive set of tests.

What’s next?

The DevOps engineer looked for the next feature to program. I saw an impressive table of valid values and validation rules.
“Do we have to test all this?”
“No”, he answered.
I could not believe my ears. There were so many places where things could go wrong.
“We will only test things, which can cause problems in our software. [The postman] will check the data.”

I visualised the data flow in my mind. There was a sender, which gave a file to the postman. This program would check every byte of the file. After a successful check the postman would deliver the
file to the receiver or the program under development. In the past I heard, that sometimes some things were not properly checked by the postman. With the speed of computers today extra checks can be done very fast.

The DevOps engineer continued:
“If data can cause problems in the software, these are checked.”
Version number is a good one. And of course begin date and end date of a period are also important.

Another cycle to start

This looked so easy.
It was like the junior DevOps engineer had some mindreading skills.
“Now you try.”
I was silent for a moment.
I repositioned myself after the keyboard and the mouse.
Pair programming. The real stuff.

Okay, let me start.

Read mindfultester[dot]com
My answer in a job interview

To be continued

Being Sidetracked – Part 1

Every story has an expiry date.

So I have to hurry up.

While the junior DevOps engineer was programming aloud, I paid attention to all the steps he took. He used Test Driven Development. It is a cycle of Red, Green, and Refactor.

A small recap: he first made a tiny test, which failed. Red is a favourite colour for failing. Then he made code to let this failing test succeed. Green is that other favourite colour for DevOps, testers, and especially managers.

Then he refactored the code. The code became more maintainable and readable. Even for a tester not fluent in Java.

The first test was to check, whether a business rule failed. He wrote only code to let the test succeed.
Before I could think, the method was ready. It had only one return statement with 1 fixed value.

But this would only be the case for very specific situations. I showed my disbelief and he answered that the code had to pass the new test. Right, you are right.

This was a strange situation for me as a tester with a traditional background. Tests should be executed after the implementation and not before. Somehow my brain had pushed the theory about TDD aside. It felt so unnatural to me that I unconsciously switched back to Program First Test Next.

Anyways, the DevOps had a quick look to the code. I did not think that this could be refactored. One line single statement cannot be refactored.
Yes right again. The first cycle was finished. Red Green Refactor.

A return value from a method is like an answer from a human being. What the DevOps basically asked, was: “Is this value right?”
And the method would always answer with “Yes.”

This was strange to me. Now I realised, that this was the most minimal addition to the program.
Without a method the code would have be repeated multiple times and maintained at the same number of places. A recipe for disaster.

Aw I forgot to look in the right low box in the left corner in the room under the stairs.

Now programmers have a small heuristic for this one:
DRY. Don’t Repeat Yourself.

The fact that the answer was always “Yes”, bothered me. While blogging I remembered asking a restaurant in China, whether they could speak English. The answer was “Yes.” My wife and I were delighted until I ordered. O no.

To be continued

Does it fit?

Fancy restaurants have little delicious dishes and standard spoons, which might not fit.

Take that

“We cannot combine the automated test and the performance test.”, Scott stated. “They don’t fit. It’s a waste of time.”
Alice looked hopeful.
George brushed it away:
“Instead of testing you are talking. You’re the one, who wastes time.”
Scott was a man, who did not mind a good discussion:
“We’ll lose a lot of time, if we do not split the tests. ”
“My decision is definite.” George answered.
“Don’t you understand?” Scott shouted.
Alice started to look white.

“You can leave the room NOW.”
“You cannot run away from decisions.”
George stood up:
“You bet. I will have a little talk with HR right now.”
He went out the room and slammed the door.
Alice looked miserable.

The door opened slowly. George looked inside and said:
“That did not go quite right.”

Take Me To St Louis

“Scott, do you know a person you never shout at and who knows as much about automated tests and performance tests as your manager?” George asked.
Scott was silent for a few moments.
“My mother. ….!? Wait a sec. You are not involving my mom in this discussion!”

“Hi mom”, Scott began.
“What is the matter, son?”, George answered.
“I want to thank for the apple pie you made for me.”
George raised an eye brow, Alice smiled.
“Did you come to talk only about the apple pie? ”
“No, for my work I have to combine automated tests and performance test.”
“I am sorry, son, but I cannot help you with this. Just do, what they told you.”

Scott was shifting gears in his head.
“A performance test for a car is to look, whether it can handle the load.”
Alice put a thumb up.
“I understand: if I can put all ingredients for an apple pie in the car, then it can handle the load.”
“No mom, that is the purpose of an automated test. That one is focused on the functionality of the car: can I open the door, put the ingredients in the car, close the door, and drive away?”
George looked puzzled:
“What kind of load do you mean?”

George nodded.
Scott made another attempt:
“A load for car software are heavy conditions. Does the car ride well with four adults, luggage for long holiday on slippery roads in a dark rainy night?”
“I only fetch my apple pie ingredients in my car during daylight, when the weather is good. ” George explained.
Scott threw his arms up in the air.
A frown appeared on Alice’s forehead.

Take 5

“You are close.”, George assured Scott.

“You know, mom, that a car has a lot of software.”, Scott stated.
“You say so, son.”, George answered. Scott continued with:
“The dashboard must show the right information at the right moment, if I am speeding on the highway. In this case the computers in the car must work very hard. That is the purpose of the performance test.

An automated test can be used to check, whether all buttons and displays of the dashboard work properly. If I drive fast, I am not using every button on the dashboard. So the automated test and performance test cannot be combined. It does not fit.”
Alice put her right hand on her chin.

“Thank you for the explanation, son. You definitely earned an apple pie.”
Alice started laughing merrily. Scott joined in.

After Alice had stopped with laughing, Scott looked at Alice:
“Do you need more arguments, Boss?”

Alice sobered up. She got a focused look:
“You know, that there is a lot of pressure. So I tried to take a shortcut. I notice, that you have a lot of anger. I assume, that you have a need to be understood. Am I right?”
Scott just nodded.
“This basically means, that a choice must be made between quality and functionality. “, Alice continued.
“At the moment Quality has the best chances.”

Alice turned away from Scott.
“George, I really want to thank you for ..”
George’s chair was empty. He had left the room.