PDHC - Plan, Delegate, Hope, Celebrate

Thank you mr. GM Weinberg for inspiring me to write this post.

PDHC - Plan, Delegate, Hope, Celebrate

Dear reader,

I started my career as a Software Tester back in 1999. I was quite interested in quality. That's why I was reading around, looking for lessons where I could learn how to achieve 'the' quality.

One of the most important and very simple lessons was the Deming circle or PDCA.
It basically says Plan, Do, Check, Act. And basically this is all I needed to know. All the blanks could be filled with some creativity and common sense. No rocket science here. (basically there is rocket science here because PDCA is an example of a closed loop control system which is used a lot in rocket science.) Ok...no neurosurgery here.

Still, in real life I have encountered many projects/managers/controles/VIP's who are very familiar with PDCA but are not using it in practice.

I guess that, what they are using in practice, is probably the 'best practice' since I have encountered it so many, many times.

The 'best practice' that I am writing here about is what I like to call:

PDHC or Plan, Delegate, Hope, Celebrate.

This practice follows these four steps:

  1. Plan: Isolate yourself, or few other men or women or however you want people to identify you, from the rest of the world and make a plan. Use Excel as a tool of your choice. Spend weeks, or preferably months in making this plan look good. Use colours. A lot of colours. This plan does not have to have any relation to reality. As long as it looks good and the numbers reside coherently inside the budget.
  2. Delegate: Once the plan is done, find people, call them resources and assigin the tasks from the plan to those people. It is really not important if those people are able to complete those tasks. By the way, they will also not warn you if it is not possible because it will make them look stupid. Anyone who dares to criticise the plan can be fired because of his incompetence or at least made look bad and unmotivated. So, no worries here neither.
  3. Hope. This is a phase where you can hope that the actual work is getting done. It takes place right after the meeting where the tasks were delegated. No actions are needed here. Just hope. Nothing else. During hoping you can go walk around and talk to people. If you do not know what to say here are some links for inspiration:
  4. Celebrate. Once the deadline has approached it is time to celebrate. Of course, the deadline will be moved many times further in the future. If not for months then for years. Anyway, once the last deadline has been reached, it is time to celebrate. The results are not important. Join all the people together, throw in some cake and celebrate. You are done and that is all that matter. After this you can start all over with a new project which will probably be based on the one you are celebrating. 
This is it.
With this 'best practice' you can run multimillion cash projects and become a star.

There is one soft skills needed here and that is blaming. Learn to blame anyone for anything. Once you master this skill you will also learn how to protect yourself from blame.

So, once you start a project (or anything that has to be done), sharpen your blaming teeth and go: Plan, Delegate, Hope, Celebrate.

Acceptance Test is an oxymoron


"Acceptance Test" is an oxymoronic term. Furthermore, it contains two verbs (only).

Let me refer to some definitions found on Wikipedia:
Acceptance in human psychology is a person's assent to the reality of a situation, recognizing a process or condition (often a negative or uncomfortable situation) without attempting to change it, protest, or exit.
Software testing is an investigation conducted to provide stakeholders with information about the quality of the product or service under test. A primary purpose of testing is to detect software failures so that defects may be discovered and corrected.

In those two definitions I recognize the oxymoronity of the “Acceptance Test”: Investigating reality of software without attempting to change it, with a primary purpose to detect failures so that defects may be discovered and corrected.

I have experienced several situations where this conflict has occurred. The project management saw de the acceptance testing as a part of an acceptance process where the customers had to declare the product (unconditionally) acceptable. The same time, when we, the testers, organize an acceptance test, we are leading the customers to look for problems (risks) to declare the product rejectable -unless the problems are resolved.

The question remains: is an “acceptance test” an acceptance or a test process?
I do agree that the “Acceptance testing” as described in your post is very important accept is should be called something like “customer testing” or “user testing” or whatever. As long there is a noun and a verb and not two verbs.

empirical testing

What are the differences between context-driven-testing and the empirical research?
What are the differences between exploratory testing and the empirical cycle?
What do these things have in common?

Context driven testing is an applied empirical research on quality of a system or a service.
Exploratiry testing is an applied empirical cycle in research of quality of a system or a service.

Bugs in Time

Testing as a system conclusion

The amount of remaining bugs related to testing time.

Testing == Art

“Art is never finished, only abandoned.”  - Leonardo da Vinci
“Testing is never finished, only abandoned.”  - Tester

Therefore: Testing == Art

Best Presentation Award @ the Dutch Testing Conference 2011

I wasn't expecting it and was really surprised to hear that the first place for the best presentation at the Dutch Testing Conference 2011 went to me.


http://www.testnieuws.nl/2011/04/14/lees-het-verslag-van-de-dtc-2011/ (Google translation)

 The presentation was about seeing the test process as a living system.
Last year February I wrote something about this idea in this blog.

From that time on I was working on this idea, slowly adapting and improving it.
Now I've got a recognition for it which I appreciate.

I really hope someone will get an inspiration from it.

Thanks to everyone.

Problem Question

This post was inspired by a conversation with James Bach on his blog:
"What testers find"

  1. Asmir Babaca Says:
    Few years ago I was preparing my trip to China and I took a short course mandarin language.
    What I’ve found very curious was that the words “question” and “problem” in mandarin are one the same word.
    Meaning that, if someone says in mandarin that he has a problem, he is actually saying that he has a question.
    To me it signifies that we as testers are looking for questions.
    [James' Reply: How do you know that question and problem are one and the same word? Maybe the first people who learned both languages just misunderstood that, and they've been telling people the wrong thing ever since.
    Seriously though, language translation is not the same as mapping one word onto another word. Indeed, in English, when I say that a practice is "questionable" I generally mean that it has a problem. And a "problem" on a test is really just a question you are being asked. So, it's ambiguous even for native English speakers speaking only in English.]
  2. Asmir Babaca Says:
    I’m afraid that I was misunderstood.
    Please forgive me if I am wrong.
    I will try to clarify that I’ve meant.
    In my previous comment, I wasn’t talking about translating (mapping) words between languages but showing how people see and express ideas differently and how they put things in perspective.

    [James' Reply: I know you are talking about that. What I was talking about is mis-translation. Let's consider a simple example: Can you translate the English word "problem" into the English word "problem"? My answer is "not necessarily." I might use the word "problem" in a way that you don't understand. But since you speak English, you might believe that you understand it.

    The idea of mapping words is an oversimplification, of course, but even without oversimplifying the problem is still there. I just don't know what it means to say that in Chinese problem and question are the same thing. For me, it's incomprehensible that they could be the same thing, in some contexts. But maybe in those contexts the Chinese don't use their word "problem/question" but rather some other word.]
    I think that “putting things in perspective” is what we testers do.

    [James' Reply: Yes.]

    Here is another example:
    An English expression “to land (a plane)” is “landing”.
    In French, “landing” depends where you are landing on:
    Landing on the ground is “atterrir”. “Atterrir” contains a word “terres” which means “land”
    Landing on the sea is “amerrir”. “Amerrir” contains a word “mer” which means “sea”.
    Landing on the moon is “alunir”. “Alunir” contains a word “lune” which means “moon”.
    To a french it is unthinkable to say “landing” if you are landing on the sea, moon or anything but land because there is no land to land on. In english, it makes no difference where you are landing on.

    [James' Reply: Isn't that just a matter of lexical trivia? You could as easily say that "Apple" is unthinkable to a French person, because it doesn't mean anything in their language. But of course, they can translate into French. Landing can also be translated into French. And it could be translated in many ways, including "Coming down from the sky" or "ending the flight."]

    English make a differentiation between “problem” and a “question” while for Chinese it is unthinkable to differentiate those ideas.
    (And what do I mean here by “english” and “chinese”? People or a language?)
    I’ve learned that there are at least approx. 900 million persons that are seeing problem and a question as the same thing.
    (66% mandarin speakers of china)
    What can I learn from that fact?

    [James' Reply: I don't see how you can judge whether a Chinese person would find it unthinkable to distinguish between a question and a problem. Just looking at language seems not enough to carry that case. Furthermore, it may be that English speaking people also don't distinguish between question and problem, but only think that they do because the words are different.]

    As a tester, I used to seek problems. (bugs)
    Learning that a problem can be seen as a question I am now consciously seeking questions for which there are no clear answers.
    (If there is an answer, then there is no question left, isn’t there?)

    [James' Reply: Again that seems like an illusion. An answer is the illusion of settling a question. Questions of fact cannot be settled with certainty.]

    And after all, it is much easier to me to present a question to a customer than a problem.
    They start to feel involved, less defensive and appreciative.
    Now, I am not a native English, French nor Chinese speaker so I hope that I could express my thoughts understandably.