^(testing yet)(!|?)$

Yesterday I went to a eye specialist. One of the routine examinations is an "automated" check for basic visual problems, i.e. am I short or far sighted. This check is done with a little machine that displays a hot air balloon, blurs it and then checks the eye's reaction. After completing the test one of the assistants brought me into a room and I had to do the classic "read the numbers on the wall" test. Her conclusion: "Well, your vision is at 100% on both eyes. If the machines numbers had been correct, you wouldn't have seen any of these numbers over there. It's because your eyes try very hard to adjust the blurred picture of the balloon and eyes of young people manage that to a certain degree, which can distort the result."

The questions that remains are: Why is the machine used in the first place? Will the bias coming from the results influence the assistant (and/or doctor) in a positive way or a negative? How would an unexperienced assistant react to the results of the machine?

The assistant had many more parameters to work with and reading numbers of the wall, probably took only half a minute more than the automated test. Could the problem be solved by smartening up the machine? Maybe not, the data the assistant got from just looking at my eyes probably triggered way more information than could be entered into the machine in a reasonable time.

Where have you seen or even used machines that made you double check the results because you couldn't trust it?

Yesterday Trish Khoo wrote a blog post on the death of quality. I read the post and then watched the video she was referring to - Goranka Bjedov's talk at STANZ 2011.

Goranka cites the Weinberg-Bolton-Gärtner definition of quality: "Quality is value to someone that matters at some point in time."

I really am a bit surprised to see and read to this hasn't still fully dawned on testers. Especially when you follow what is going on in the Context Driven School (even if you don't follow the school itself) you should have realized over the past few years that this change has become real.

And my conclusion is not that quality is dead, according to WBG it won't be until you don't meet the someone's expectations. What is dead is perfection. You can strive for it, but you won't be able to proof that you reached it. More important no one really wants it in today's products and no one expects it. True, I will be a bit more picky when it comes to medical equipment, planes and the control software of nuclear powerplants but even those are created by fallible human beings.

Keeping the someones in mind I think Goranka rightly sees light at the end of the tunnel, now sell this to management and tell your testers that perfection is dead!

LEWT09 is almost two weeks in the past now, but I haven't had the time to write about it until now. Having time to reflect on things is quite important, though.

Since I'm getting a bit excited now I

Since I'm only involved in testing activities I saw this workshop as a chance to keep up with what's going on in the world of software testing, exchange with testers and even get a glimpse of what managers of testers/test teams face in there every day work and how they handle it.

Even though some of the talks were a bit too high level to be of immediate use for the work I do, there was nothing presented from which I could not take at least one small bit to think twice about.

Since the main theme was "Large" we talked about

• Large teams
  
• Large Software
  
• Large Test suites
  
• Large time scales
  
• Integrating software in larger systems and so on

I was really amazed that even though all participants came from different companies and backgrounds, all got along quite well and how small contributions triggered further discussion into certain areas.

One fun part was a discussion about risk based testing, which concluded in coining the term "Fear Driven Testing"(tm by Vernon Richards)since it is not really the risk itself that drives the test effort in a certain area, but how afraid a stakeholder is that this might strike.

After a whole day of dicussing testing (and learning that in Finland they serve no doubles when it comes to spirits) I took three things away:

• I learned what Specification by example is (read more)
  
• Managers should trust in the communication between testers/devs
  
• Even teams that don't run smoothly can deliver software that the customer likes

It was a great experience and I'd really like to take part again some time in the future.

A few days ago I finished Gerald Weinberg's Perfect Software. In short it was a good read.

The long story is that I picked up the book even though I'm currently not in a tester's position. The content proved no less valueable, though. Weinberg describes how testing is perceived by testers, developers and manager. He provides possible explanations why this is so often the case and describes ways to mediate between the different parties. Always with an eye on the goal of providing a product that has the quality/qualities that the enduser requires and expects.

For testers there is not much hands-on information that can be used in your daily testing work. However you should know this book, even if only to point it out to "your manager who doesn't know what testing is about". In addition if you read carefully and spend more then one thought on each chapter you will find some invaluable advice on why people react to your testing like they do.

I think with his report on WTA07 Albert Gareev was the first one to tell us how a WT session can evolve from a moderators point of view. How they react and how may even create something very different from the original plan. If you haven't read his report yet go there first.

My personal involvement in this session was rather small. Since I had to finish some stuff in the appartment and also was writing on the report for WT53 I decided to take an observer role on this session and stay in the chat.

Whenever I did take part in a WT session so far it was kind of a hassle (which it is actually meant to be, you should work under pressure). The observer role is way more relaxed and I took the time to see how the lines of thought evolve between the participants in the chat.

I took three things away from WTA07:

1. Becoming aware of how other people, i.e. your teammates, think is crucial to be able to work together. Even more so is to actually make these thoughts known to each other to be able to build on them
   
2. Giving a mission that is to word in a very general way, can lead to a lot of questions. In a situation where the customer is rightly available (like WT) this is not a problem, but if you have to exchange mails probably even between diverse timezone it can take a lot of time and money just to clarify what the customer is looking for
   
3. Question the mission. The actual outcome of this session was that some participants not only rejected the idea of the program to be used as desired but would even hae prefered for the customer to review her hiring process. Thus thinking outside of the little world of testing becomes a must.