Language as a medium

Software Testing

Communicating is one actor, the sender, trying to get something across to another actor, the receiver using any possible medium.
That “something” is the message, undefined as it is. This complete procedure is completely dependent on both of the actors, not just the sender or receiver.

There are tons of reasons how this can go wrong. I.e. emotional and attitudinal barriers can interfere.
Only a day ago I had to cool down a heated discussion between family members. A discussion that started largely because one person understood a word to mean one thing, while the other party meant the other.

Language and any form it comes in, (spoken, written, body,… language) is a very liable to miscommunication. Think about emoticons. These filled a huge gap in the Instant Messaging mania a decenia ago. Before these small yellow faces reared their expressive heads, kids would lose BFF-status because they couldn’t add a :), and a 😡 was interpreted.

For language to work you need both the sender and the receiver to try their hardest to interpret the message as it was meant by the other party.
Even then, other stimuli and  noise can derail communication between the two.

This became, again, painfully clear this past sprint.
Context: Since deadlines are still king, and teams are ought to focus on “what’s visible for the customer”, other important non-visible tasks are postponed. This included Unit Tests and ‘focus on quality’ in all forms.
My two colleagues and me, who do all of the testing tasks, weren’t all to happy with this decision. We informed management that, if focussing on the deadline and trying to reach it by neglecting quality tasks, risk would go up, quality would go down and more time would have to be investing in righting a product that was built timely, but crooked.
They understood, but stayed on course. Straight ahead but slightly starboard to those rocks on the horizon.
Language had failed.Bugboard

We saw only one thing we could do: If we fear for bad quality, we have to find out just how bad things get and report.
We found bugs by the handful and pinned them on the wall. They did not like that.

Past retrospective, we were asked feedback on why so many bugs were on the wall and if the team could do anything to mitigate the time lost on bugfixing.
We had our answer ready.

Sometimes, we have to hit a wall, or distant sea-rocks, to realize the stars weren’t showing us the right course. Sometimes, we hit that wall together and sometimes we have to let others hit a wall.

It might not be the easiest or most pleasant of the media to be used for communication, but it’s definitely one of the more effective. Be sure to interpret it right and learn a thing or two.

These might solve problems

Software Testing

“A heuristic is a fallible method of solving a problem or making a decision”

– Cem Kaner, James Bach

Heuristics are wonderfull things. They are tools, principles, ideas, practices,… to tackle a problem. When you encounter X problem Y heuristic can be used to try and solve it.

Y heuristic can fail in solving X, then maybe heuristic Z can get it done.

A few examples:

  • A hammer can be used to drive in a nail in a piece of wood. However, when you have to drive a nail into a concrete wall a different approach is advised. A drill can usually make things easier for you, but sometimes the hammer can get the job done anyway.
  • When solving a jigsaw puzzle, starting on the edges is a heuristic. Looking for same-coloured pieces is another
  • Looking for a certain file on a server can be done in quite a few ways:
    • Using the search option
    • Asking someone who might know its whereabouts
    • Manually going through the whole Active Directory

Many testers handle a great many heuristics. They do this intrinsically. Even though they are using these heuristics, they find it very hard to explain them to the non-testing professional.

It hurts the general perception of our profession when we are asked to explain the intelligent choices we make, but can’t. “Well, I just started to randomly click around the application and suddenly the system froze and errors were flying all over”… is better explained as: “I used a click frenzy heuristic (or any other name you wish to give it) in order to find out how the application would react to a click load generated by one user. In my experience I have found that applications tend to have a chance at behaving strangely when doing this.”.

What may seem as an unstructured, randomized process to non-testers, usually makes perfect sense to us. If we could only explain this decently…

A heuristic in use:

The tea test heuristic. I used this to find the first blocking issue in my professional career.

I was testing a mobile device ambulant nurses were using to register their patient visits.

The client was complaining that the device was going into a freeze on a regular basis. This bug wasn’t found during development of the device. However simple it was found.

 What do nurses do when visiting a patient? They bring their device, log in, maybe register that they started the visit and then look at their patient.

 What does the system do? It gets turned on, maybe a few things are registered and is then tossed aside for 15-30 minutes.

 It should go to sleep, or at least stay in the state it was left at. It didn’t. An error message sprung up for 30 seconds, which was unnoticed by the nurses, and then disappeared. The system froze.

I found this bug by logging in and further doing nothing. Went to grab a coffee. (yes, coffee is also viable as beverage when applying a tea test) Returned and found the device in freeze.

Clearly, the system was failing to stay in idle state. My next test timed the whole thing, caught the error message and showed where the problem was.

Heuristics help us to explain our craft in an intelligent way. They are usually explained by metaphors, examples, demo’s or stories from our days at work. Using heuristics to explain the way we think and work shows that we have thought about it. They help us build up our model of testing and how we see the world.