Tester who did not understand if/elsif branching

Reading Time: 1 minute
credit: commons.wikimedia.org

TLDR
Logic is important tool of software developer and tester. In this post I will describe one logical error in if-then-elsif-else branching construct.

Logic is important tool of every tester. One of the first problems related to software testing that I encountered in my work was to understand and properly use if-then-elsif-else branching. I thought that reading about that branching technique from programming text book is enough. But guess what, you need to use logic to properly understand it.

Lets take following gist as example:

We have two variables, destination and returntrip as input variables. Requirement is that back trip doubles the cost, and every planet has different cost. Can you spot logical error in the gist?

In given example, we properly calculated only backtrip to Moon. In if-then-elsif-else branching you must not interchange variables in if and elsif statements because you will make logical error. All variables that are part of business rule must be part of if and elsif statement. So, if you are doing source code inspection of test automation code, if you see in if-then-elsif-else statements different variables or different variable tuples (when business rules takes as input more than one variable), than for sure that code has logical error.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

What high enery physics taught me about testing

Reading Time: 2 minutes

TLDR

One of my passions is to learn about space. In this post I will explain what I learn from astronomers and high-energy physicists about software testing.

I got interested about space by reading Carl Sagan: Cosmos. For me it was great introduction to space. Lately, I am reading Dr.Sc. Dario Hrupec columns in Bug magazine. Dario brings us latest discoveries and developments from astronomy and high energy physics. What I like about his columns is that he explains theory failures and why those failures are actually very valuable discoveries.

“A heuristic is a fallible method for solving a problem or making a decision.” [Bach, Bolton].

In my conversation with other fellow testers, that fallible part of that definition always have troubled us, as something that will not bring value to our testing activities. But with failures, we also learn a lot about product under test. High energy physics is one proof for that. So failure is also very valuable tool in science and software testing.

On hacker news,  I found about book “The Cuckoo’s Egg” [Wikipedia]:  tracking a Spy Through the Maze of Computer Espionage. If you are interested in computer hacking, this is great book for start. Author is high energy physicists who uses ideas from that science to catch the Russian computer

hacker.

“Roy Keith had shown me the high-energy particle detectors attached to the Bevatron: they find jillions of subatomic interactions, and 99.99 percent are explainable by the laws of physics. Spending your time exploring each particle trail will lead you to conclude that all the particles obey known physics, and there’s nothing left to discover. Alternatively, you could throw away all the explainable interactions, and only worry about those that don’t quite satisfy the canonical rules.
Astronomers, distant cousins of high-energy physicists, work along similar lines. Most stars are boring. Advances come from studying the weirdies—the quasars, the pulsars, the gravitational lenses—that don’t seem to fit into the models that you’ve grown up with. Knowing cratering statistics on the planet Mercury tells you how often the planet was bombarded in the early solar system. But study the few craters intersected by scarps and ridges and you’ll learn how the planet shrank as it cooled during its first billion years. Collect raw data and throw away the expected. What remains challenges your theories.”
Here is excerpt from the book that explains how astronomers found out about important facts in planets history.
“You saw that guy typing in the ps -eafg command, right?”
“Dave smiled. “So that leaves us with the f flag. And it’s not in any Berkeley Unix. It’s the AT&T Unix way to list each process’s files. Berkeley Unix does this automatically, and doesn’t need the f flag. Our friend doesn’t know Berkeley Unix. He’s from the school of old-fashioned Unix.”
In this book excerpt hacker revealed his activity by using ps obscured f flag that is used by default in newer version of Unix.
In software testing we often found important bug by investigating and analysing patterns or events that asserts in some way.
Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Zagreb STC #20 Meetup report

Reading Time: 1 minute

Yesterday Zagreb STC had small anniversary, we gathered for 20th time! We started with our usual introductions, but this time in not usual way. Iva’s talk was about Mind Maps, so she suggested that we do our introductions by creating Mind Map. Result is on the left.

I am using mind maps, both for work and other daily activities, but Iva’s presentation though me new important facts about mind maps. Some of those are:

  • always use landscape orientation because this is how our eyes are layouted
  • mind map should fit on one page
Iva brought two friends that are not testers but use mind map in their work: raising a child and organize processes in company not related to IT! Very interesting experiences.
Tony Buzan is creator of mind map, so Google it if you want to know more. We concluded that mind maps are very useful to organize, memorize and learn various topics.
As an exercise, we created a mind map for testing event that we are planing to do this year.
In the end, we had two lightning talks. I talked about Toptal, sponsor of our event, and Zeljko presented juggling.
We continued our discussion in great new place, Potato House. For the first time I tried Borš and It was great. My freind Dejan, who works at Potato House, explained us how to prepare it. As in testing, time is important component of great Borš.

By giving this talk, Iva earned free ticket for WebCampZG 2015. This rule will be applied for all Zagreb STC speakers up to the event schedule.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

When you should restart any server instance?

Reading Time: 2 minutes
image credit: findicons.com

TLDR

In order to know when you should restart your server process (web server, database server, or any other type of server), you need to understand how program works. In this post I will explain basics of program and used libraries and how to detect on linux when you must restart your server.

I am very frustrated with Windows operating system. You need to restart it almost for everything, important security issues, regular updates. Pain is even greater when there is some security product which just pop ups notification: your system will reboot immediately!

And in the beginning, there were stories that unix, and later linux is much better, because you do not need to restart it. As I was learning and using unix/linux, I found that this was true. There were notifications that new updates are installed, but there was no need for machine restart. As I learned about linux, I found out that this was not true.

If you are running linux instances as part of publicly available web application, you must walk extra mile. You will probably set silent automatic updates for you linux instance. But, you will have to do extra check to see do you need to restart your server processes.

Every server process is a program. It consists of executable part and a number of libraries. When you start your server process, executable and all required libraries (on linux those are files with .so extension) are loaded into memory assigned to that process. So if there was an update of libraries used by your server process, and those libraries are loaded into process memory space, you will need to restart your server instance in order to load new version of those libraries.

For linux, there is utility that can help. lsof lists all opened files. It has useful option, DEL, which list all opened files that are marked for deletion.

This example shows that postgres still uses deleted version of libcrypto library.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Metric for BPEL developer productivity

Reading Time: 1 minute
Image credit: thinktheology.org

TLDR

I have got very interesting task. My friend asked me to help him to determine metric that will be used to measure developers productivity in his department. What make this task more interesting is that developers are using rather new tool in their daily work: Oracle BPEL process manager.

This task is hard, because “old school” developer productivity metrics, such as number of classes, number of lines or number of test classes could not be used. Of course, from BBST foundations lecture about metrics, I knew that those metrics are wrong.

As BPEL process manager was new to me, I asked one developer to allow me to sit next to him while he was using that tool. I learned what is output of that tool. It was not code but sheet with elements that describe business process. And that was it!

We agreed that metric that will be used for measuring developer productivity is the area (measured in cm2) of sheet that represents business process created by developer.

I am very proud of this metric. Management accepted it with great enthusiasm. Fact that this metric will be used for the first time to measure developer productivity also helped a lot to sell the idea to the management. Next week we will present this metric to developers. I am very excited to present them an idea that will make them part of the history in software development.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather