^(testing yet)(!|?)$

The machine is wrong

nospam@example.com (Markus Deibel) — Fri, 04 Nov 2011 12:07:37 +0100

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?

Is quality really dead?

nospam@example.com (Markus Deibel) — Sat, 08 Oct 2011 10:33:10 +0200

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 - Takeaways for a part time tester

nospam@example.com (Markus Deibel) — Sat, 30 Apr 2011 11:13:59 +0200

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.

Book Review - Perfect Software

nospam@example.com (Markus Deibel) — Thu, 24 Feb 2011 21:15:54 +0100

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.

WTA07 - Following the thoughts

nospam@example.com (Markus Deibel) — Tue, 22 Feb 2011 20:16:45 +0100

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:

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
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
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.

WT53 - Digging into eBay

nospam@example.com (Markus Deibel) — Sat, 19 Feb 2011 19:26:33 +0100

It's been a week since WT53 took place. I wouldn't wait that long to write a test report, but reflecting a bit on the experience is good for a write up like this, I guess.

I hadn't taken part in a WT session for about nine months, and was anxious to get back into full testing mode and even more so, since the session was lead by Jon Bach- Currently working as lead in eBay's test team.

A side effect was that I got the chance to check out, how working on a 9" netbook would influence my effectiveness, but more to that in the summary.

The missions for the hour of testing which revolved around the search functionality of ebay were small but plenty.

a) Which search string returns the most items?
b) What is the most bizzare thing that you can find? - Highly subjective!
c) What's the most expensive item on ebay?
d) Can you find a "Whack", a search string that returns one item?

I started out with mission a) thinking along the terms of strings, (mis-)leading to use text values only.
My thinking sprang to using as small a number of characters as possible, covering the most words at the same time. Thus the starting point was the letter e, which directly gave me the following message:

Your query matches a large number of items. Please try searching within one of our categories.

This was also found by several other people, using different strings. The combined investigation drew out the idea that the limit might be somwhere around 21.000.000 results

Since after ten minutes I hadn't reached a value higher than 2.000.000 probably I switched to mission c).
That mission turned out to be an eyeopener on what people are actually selling on eBay.
Here is a small assortment of what I found along with the search term I used:
- most expensive
- A quite expensive T-Shirt
- ship
- A tanker ship
- plane
- A DC-6B plane (that is NOT a model )

Further more I had, cranes, houses and even an X-Ray telescope.

I continued with mission b). SInce bizarre is a highly subjective description I started with the search word 'bizarre' taking into account the sellers own impression of the object. Amongst others I got real human x-rays and even though I didn't find a real shrink-head the next best thing were dried apple head dolls.

At this point I had about ten minutes left to go for a "whack" but gave up after a few minutes, taking the time to follow what was going on in the chat.

The hour of discussion was quite interesting. Discussing the approach for finding the most items turned out be be quite interesting. One tester used the search term '00*' since the basic search also includes a check against the auction ID. That showed a blind spot in my approach. Sure I had used the search for an item ID myself before, but just didn't remember it.

For the other approaches, everyone seemed to work along their lines of thought, refining the search strings based on some idea derived from the previous one.

Short before the end Jon described this technique with using several small mission, giving each a timeframe of about five to ten minutes as "Open Book Testing" (I don't have the transcript yet but I think he mentioned a blog post on it). In addition to his use, two testers saw this is a good way to assess testers in job interviews.

As for myself, it felt good to get back into testing mode again and be reminded that there is always a second, third or fourth point of view on the work that I deliver as developer. Working with a 9" netook for twon straight, however is not fun. Straining for the eyes and also typing is not easy. I'd not reccomend it for professional use.

The conference I missed

nospam@example.com (Markus Deibel) — Wed, 08 Dec 2010 11:57:37 +0100

Unfortunately I couldn't make it to this year EUROStar conference in Copenhagen, but with lots of work at hand I couldn't have possibly sold this to my boss.

However, by means of twitter and blogs from the great people who not only gather knowledge but also share it willingly with the community I was able to at least follow some parts of the conference as it progressed.

In the aftermath I'm also happy that lots of people are writing about what happend, what they learned and taught.

If you haven't seen any of these check the sidebars on http://www.softwaretestingclub.com/.

One exceptional post was put up by Shmuel Gershon on his Testing Thoughts Blog. Check it out for some videos of the Danish Alliance.

Team up, you can't do without!

nospam@example.com (Markus Deibel) — Tue, 07 Sep 2010 09:25:49 +0200

I just read the following beatiful sentence in Trish Kooh's blog:

Maybe the world is full of people who like to create things and people who like to improve on existing things, and two of these people working in tandem can create truly extraordinary things.

That's what you should answer when anyone asks you why programmers and testers should work together more closely.

Talk to other mindsets not just other people

nospam@example.com (Markus Deibel) — Fri, 03 Sep 2010 13:27:46 +0200

Yesterday I overheard part of a conversation of two egineers in cafeteria.

Engineer Tim had a problem with the software running on one of his production lines. "... it fails sometimes when reading the tags. It doesn't seem to be connected to any particular set of tags, or time. I don't know what else I could try." Egineer Todd asked about five to eight questions "have you tried x, y or z" and Tim's answer was always "yes, been there, done that".

That made me think about who he was talking to. Todd was basically doing the same job, with the same background and roughly the same amount of time of experience on the job. Their thinking seemed to be aligned.

In a situation like this a colleague sometimes turns out to be a "rubber duck", but in cases like the one above it might not lead anywhere. If you find yourself in that position try talking to someone with a different mindset, a programmer, some who tests another part of the system, a hardware guy - chose from who is available.

This way you can keep the focus on your problem but get unfocused input.

Punishment of testers fostering bad testing?

nospam@example.com (Markus Deibel) — Tue, 06 Jul 2010 13:18:04 +0200

I just watched Clay Shitky's TED talk on cognitive surplus and was really surprised by the second part (from about 06:50) where he describes a research done in daycare centers.

It showed that introducing a (small) fine for picking up your child late, was followed by an increase (double) in the rate of late pickups during a 12 week period. What is also interesting is, that after the fine was discontinued, the numbers of late pick ups stayed high.

Putting on the tester-hat, could this mean that regular punishment will grow a feeling that doing bad work is acceptable because you will get punished for it? Is it possible that this feeling grows when some kind of metric is used to present "hard facts for bad testing"?

By presenting metrics and dealing out punishment based on it, we might take away the little social pressure that might exist between prorgammers and testers which normally leads to small, well-meant and encouraging teases pushing us to do better work.

The same might of course be relevant for developers and other parts of an organization, I just wanted to limit the scope a bit.