Month: June 2011

The quality? Oh, we test it in! (part 2)

Who is actually responsible for the quality? To answer that question, I ask myself two questions: what is quality? And what is responsible?

Quality is a difficult concept. In training on software testing I often ask the question: “is the coffee any good?” I get the most diverse answers. Some answer: “for coffee from a machine, it is doable”. If someone says, “horrible!” my response would be: “Why do you drink the coffee anyway?”. A nice discussion about the concept of quality. Quality is value to someone (who matters), at a given time. So the coffee, even if it is not really good, can still have value: for example, to wake up/stay awake! So the coffee has some quality for someone who wants to stay awake.

The other topic is responsibility. Who is responsible for the software? Anyone who ever worked with a RACI matrix, knows that there are different “types” of responsibility. Responsible and Accountable, which in Dutch both can be transleted in “verantwoordelijk” (responsible). In this context, I look at the question: who is responsible for the quality? The project (or project board) for its production. But what about the rest of the team?

Andreas says: “A nurse in hospital is still partly responsible for welfare of patients? Not just the doctor. An inspection department at Unilever is responsible aren’t they? Not only the people behind the machines?”. The example of the doctor and nurse is a good example. Of course the nurse has responsibilities. To nurse the patient as directed by the doctor who suggests a diagnosis and treatment. Each profession has task and are jointly accountable. Not responsible for the health of the patient! They should do the best possible in their profession. But if a patient decides to leave the hospital during treatment, it is his choice! Similar to: if the customer decides to ship the software. In spite or because of the results of testing.

I totally agree with Jan Jaap saying: “many testers are limited ….” and “testers of all companies: broaden your horizons!”. Testing is definitely not just a plan, case writing, execution, reporting. It can and should be much more. Only the purpose of testing, I would like to formulate it differently. Not “contribute to the project objectives with a focus on quality“. I’d rather go for the definition of Cem Kaner, “Software testing is a technical investigation for the purpose of revealing the quality of a software product on behalf of stakeholders.” or the shorter definition of Jerry Weinberg: “Testing is gathering information with the intention of informing a decision”. The goal is to provide information! And thus helps the tester actually contribute to the project goal.

In early quality measures, I also recognise quality reviews, inspections, etc. But here is much more than just working on documentation. I think of: pair programming, help unit testing (improvement), improve testability by asking for logging, acceptance criteria drawn up by acceptance tests (even before fully written requirements and specifications). And there’s so much more testers can do.

The quality? Oh, we test it in!

Friday I saw a tweet by Andreas Prins. Since they are in Dutch, I will translate them here.

His tweet: Question: is this statement correct? # The quality? We will #test that in!

My reaction: Can I have a bucket? RT @ andreasprins: Question: is this statement correct? # The quality? We will #test that in!

After replying, I saw that Jan Jaap Cannegieter also replied with this tweet: @andreasprins statement: “quality, we will test it in” is true, it’s just awfully expensive and time consuming.

I couldn’t believe my eyes. So I replied: @jjcannegieter @AndreasPrins No, never true …. You can’t test quality in, you /build/ it in!

After a while Andreas replied: @huibschoots @jeroenro Thanks clear responses, I share your opinion, you’re really together responsible, but how do you do that?

I replied: By working together! Testers help developers to improve quality. Too long for a tweet. Want a blog?

Andreas asked his questions because he was preparing a column for TestNieuws, a Dutch website on testing. In his post he sums up the reactions and he concludes:

Having thought about this, we can conclude the following:
– The quality of testing afterwards is not possible because the product is there already
– Early involvement can prevent deterioration
– We need a new way of thinking where we not only feel responsible for providing insight into the quality but we also feel responsible for the quality itself. The moment we as testers also feel responsible for the quality, and we are a team, so testers are actually responsible for the quality, then we will also be asked to work to together to achieve this quality.

No, no and no again! Testers can test as much they want, the /tester/ will not improve the quality. The developer does, to the software, at least. Perhaps a semantic discussion as Jan Jaap calls it, but still very interesting! Because the statement is fundamentally wrong! And with these statements perceptions and fallacies are born. The perception of the organization is often that testers will test the quality in. Or even worse: the regression test will find the major bugs, so why test early?

Making testers responsible for quality is also fundamentally wrong. Even as part of a team, testers are still not responsible for quality. Testers are there to help others, with their service of testing. Which is a sapient activity, questioning the product. Helping the team (or our client) to make informed decisions about software by critical thinking (see: RST by James Bach and Michael Bolton).
To be continued!

First DEWT peer conference

Pre-conference drinks

After a long and instructive week of RST, I picked up Michael at his hotel on Friday evening and we drove to Driebergen for the first DEWT peer conference (#DEWT1). We checked in and went to our rooms for a small powernap waiting for the others to arrive. Since the conference would only start the next day, we had the inevidiable drinks and fun. You can imagine that putting 7 testgeeks in the same room will end up in enjoyable stories about our craft. The bar closed at 23:00, but we found the night porter happy to bring us more drinks. Somewhere around 2 a.m. we went to bed after a very entertaining evening/night.

Opening by morning chair Ruud Cox

On Saturday Michel and Jeanne joined us after breakfast and our DEWT conference could finally start. Ruud being the chairman in the morning kicked off thanking everybody for being there.

Artful Testing
Zeger did his “Artful Testing” talk. A very well done talk using a amazingly beautiful prezi. Although he had 15 minutes according to the program he managed to keep us facinated for triple the amount of time. He must have paid Ruud to get his extra time 🙂 Or was it because his talk kept us all from looking at the clock?

Zeger Artfully in action

Zeger’s talk was about (without giving away too much) the connection between testing and art. The ingredients were:

  • how testers can benefit from arts
  • some good comparisons between art and software, testers and art critics
  • some nice “artful testing” heuristics, too bad they are still without a nice mnemonic, but Zeger might change that over time.
  • a good testing challenge
  • nice photo’s and other pieces of art
  • Ambiguities, mystification and anagrams (nope no Da Vinci Code here)

I don’t know what Zeger loves more: art or testing, but he sure did a good job combining them. This talk is on the program of the Belgium Testing Days and I suggest you go and see this talk! I hope Zeger will also send in his talk for the TestNet fall event as well.


Michael Bolton on Transpection

Michael Bolton was up next on the topic transpection. We asked Michael to help us explore the intruiging “tool” of transpection. After a short introduction, referring to several post by James Bach and himself we started an exercise. We did the exercise in pair, where we were to collect information on the subject. Michel and I searched some articles and then tried a little transpection of our own. In the round up we collected all information in a nice mindmap.

BTW: See Zeger’s blog for more information on how we studied transpection.

Lighting Talks

After lunch Jeanne took over as conference chair and lighting talks were on the program.

Jeroen Rosink

Jeroen Rosink: Testing Pyramid, about testers in the classic career path (test analyst – test coordinator – test manager) getting more senior in their job and there are only a few places at the top of the pyramid.

Me: The power of knowing nothing, about people without knowlegde asking lots of good questions, not being biased. And the usefulness of telling people why instead of how. Inspired by my first days in a new job and this video of Simon Sinek.

Zeger van Hesse: Bader Meinhoff-phenomenon, about the advantage of knowing a lot. Since the phenomenon says that when you have seen it once, you start recognizing it more often. A powerfull thing for testers.


Introducing RST in Dutch projects
Ray talked about his experience on how he tried to introduce his take aways form the RST training in his projects. An interesting discussion followed Ray’s short talk and we made a mindmap on how to make the case for Rapid Testing. At the end a discussion from the RST class in the week before the conference about giving release advices popped up again.


The last talk was done by Ruud on Credibility. Ruud referred to a presentation on this subject by Randy Rice which inspired him. Credibility is build on trust and is one the most valuable assests a tester has. If you lose your credibility you will have a though time doing your job. Ruud showed a cool heuristic he uses to keep reminding himself on the key factors of credibility. He also made a nice design he can put on his monitor so he is reminded whole day.


STYLE by Ruud Cox


  • Safety language
  • Two ears one mouth
  • Yes but
  • Lighten up a little
  • Empathy

After this topic the conference was officially over and we had some drinks (with nice testing games), dinner together (with some yes/no question mysteries and lifting my parrot jokes to perfection) and we left for home. This conference was excellent!! Why? It was great fun, I learned a lot, got to explore some really interesting topics with cool colleagues and went home with a lot of new ideas. Thanks guys!

Ray Oei, our technician, at work

This conference was attended by: Jeroen Rosink, Ray Oei, Jeanne Hofmans, Michel Kraaij, Huib Schoots, Jean-Paul Varwijk, Ruud Cox, Zeger Van Hese, Michael Bolton. Peter “Simon” Schrijver and Anna Danchenko could not attend.
Ray filmed the whole day, I’m curious about the movies he made….

RST – Rapid Software Testing

Via Twitter I read the post by Brian Osman blogging his experience with the RST by James Bach, which triggered me to finish the first post on RST today.

8, 9 and 10 June I attended the Rapid Sofwtare Testing training in Utrecht. Michael Bolton was invited by my employer to train almost 50 testers and test managers in one week. This great course got me thinking and my mind is overflowing with ideas! This post is to capture some interesting topics from the course from the notes I took.


It was cool to see how Michael really knows how to inspire his audience. The first day gave me a nice view on testing vs. checking. This wasn’t new for me since I have seen Michael speak on several occasions. The part about “It works really means: it works, to some degree, on my machine, it appears to fulfill some requirement in some point of time.” made me think about the meaning of testing and how others look at it. Also the view that testability is important and the great use of heuristics inspired me to start using this in my daily work.

Asking questions

Michael is brilliant in asking questions and demonstrating “good” and “bad” behaviour by testers and stakeholders. The value of credibility and the use of safety language was discussed. It was interesting to see that the whole classs agreed with Michael without much discussion about this. I can imagine that lots of testers agree, but in our daily work we do not use it very often. We should train ourselves more in using safety language and carefully formulating our testing story. Testers also should be asking more questions! A great sentence I heard Michael use a couple of times could help us: “Hmmm, interesting, let’s talk about that!”.

Great testing questions

During the course we made a list of Great Testing Questions on a flip-over. This is the list from our class, but there are a million more questions testers can ask.

  • Who is my client?
  • Can I ask questions?
  • Are there more rules?
  • What is the budget?
  • Are there more like this?
  • Are there more of these?
  • What is the risk?

But more about safety language and questions later.

How RST can work

The best take away from the first day were my thoughts on how RST can work. During one of the exercises we were making mind maps while listing product elements. After this 15 minute exercise it became clear to me how powerful using a mindmap and heuristics can be creating test ideas rapidly. Me and my RST buddy Matthias worked together inspiring each other after every new idea. Imagine what our list could become when we would ask a designer or programmer to review it. Two-way inspiration in a split second! And how many more new ideas could we retrieve from the requirements or the client?

The best quotes from the first day could be (because we were served many): “Testers responsibility is to remain unsure when everybody is sure!” and “Testing is about questioning and learning under conditions of fundamental uncertainty”.

Context-driven tester?

Since I did the Rapid Software Testing course I know: I am (or at least want to become) a context-driven tester! Although I often praticed the Basic Principles of the context-driven school in the past and “Lessons learned in software testing” has been my favorite testing book for years now, the course made it perfectly clear to me that testing should be context-driven. RST: a must do for every tester who takes his/her job seriously.

More to follow later!

A blog about testing? Magnifiant!

This is my blog on software testing. I always say that out of the 1000 ideas I have (and believe me, I produce lots), only 5 have the potention to become any good. The rest are great or even brilliant but totally unrealistic, unfeasible or misunderstood. I want to use this medium to share my ideas and thoughts on software testing with the testing community out there. So feel free to comment. And if you do not agree (at all) with me, just let me know. In that case you might have encountered one of those brilliant ideas I thought I had. Your feedback is highly appreciated and will be used to sharpen my own ideas while exploring yours.

In Dutch, the name of my blog would be “Grandiaal” which is a mixture of the words “Grandioos” (Grandiose or magnificent) and “Geniaal” (genius of brilliant). In English this could be translated to: Magnifiant, a word linking magnificent and brilliant. This name is great because there is also the word Magnifier in it, a tool which is used to investigate and enlarge subjects. To explore and learn from the subject.