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. (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)|zh-CN|problem%0Aquestion%0A
    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.

How to improve a (test) process?

What may happen when you try to improve your "process" in an engineering environment?

Mostly, you may get some resistance because people do not have time for improvement. 
(There is a lot of work to be done here therefore we do not have time for “your” improvement)

Therefore, people do not innovate.
When people don't innovate, they stick to routine and procedures.
In testing, testing gets replaced by checking. see:
If they do innovate, they do not stick to routine (of course)

Because of the routine, the fear of failure (fear of being blamed for failure) increases. 
(OMG: I will not finish all of these obligatory tasks on time!!!

All of this increases the feeling of time pressure. (enter the endless loop)

Usual solution for this situation is: "Introducing Industry Standard Best Practice"  ISBP
(yay hooray!)

But what do ISBPs do?
For what I've seen so far is that they
1.      ask for innovation
2.      ask to follow (pre)defined routines and procedures

Will this work?
(NO! It never has and never will.)

See the model.
We could’ve seen so far that innovation and routine do not go well together. Under the pressure of fear and time and asking at the same time to improve innovation and establish better routine the ISBP will simply be ignored and it will bleed out.


To improve your “process” create your own ISBP by
1.      Seeing your process as a system
2.      Making a choice between innovation and routine (choose innovation if you ask me)
3.      Tackle the fear
4.      Give people enough time (or at least the feeling that they have enough time)