Testing Dimensions

To understand testing on a high level, we must see that there are five dimensions
I have centered my blog around these. Each blog-post is referenced to one or more of these dimensions.

Some explanation might be necessary.
There is a lot of depth into these dimensions but a basic understanding will help you categorize many more information found in the testing world. You’ll be able to connect the dimensions and appreciate the complexity that we face every day.




As testers, we search for information. Important information. But how do we know which information is important and important to whom?

We seek answers to the questions:

  • Why are we testing?
  • Who are we testing for?
  • Does this mission change over time?
  • What influences this mission?
  • Do we pursue multiple missions and is one more important than the other?



We know that complete coverage is impossible to achieve. We can achieve complete coverage of some specific kind, sure, but we can never truly do all possible tests.
This is something we know but still need to work with.

We seek answers to the questions:

  • What are the important tests to run?
  • What are the high-risk areas in our product?
  • What tests could possibly hold important information?
  • Is there anything we might skip?



Anyone can test. Not everyone can test as well as any other, but everyone can bring a special point of view to the challenge. Testers crave diversity and versatility. We’re especially scared of getting stuck in a rut. That’s why we should constantly search for new people with diverse skills and new interesting inputs.

The team are the people who test. This includes just about everyone involved with the project. Programmers test each others code, analysts test their ideas, business tests the team.

We seek answers to the questions:

  • Do we have the people available to do good testing?
  • How can we improve?
  • What are the learning needs?
  • Can we recruit people from outside of the test team to assist us? Can we assist them?
  • Who do we report to and what information do they need of us?



Oracles can be anything. They are models, tools, bodies of knowledge, reference programs, requirements,… anything.

They help you find the answer to the question: “Is there a problem here?”.
As we know, Quality is value to some person (who matters). But value to one person can be different or downright opposing to perceived value by another person.
Quality is subjective.
Therefore, all Oracles have the possibility to fail.

We need oracles to be able to make decisions, but we can’t trust in our oracles too much either.

We seek answers to the questions:

  • Is there a problem here?
  • Is this feature important?
  • Is this product consistent with various external factors?
  • Which oracle is more trustworthy than the others?
  • Which oracles are we forgetting?



Strategy combines many different pieces of the testing puzzle.
The more answers you have found to the above questions, the clearer your strategy can become.
As more information becomes apparent your strategy will evolve over time, constantly. That’s why up front Master Test Plans are either so high-level that they can be interpreted any way over the course of the project or in so much detail that they become outdated quickly.

Your Strategy addresses each of the four other dimensions and puts it to practice. It adds logistics, a plan, what is of higher importance and who you need to keep in the loop.

We seek answers to the questions:

  • How can we be as effective as possible, as soon as possible?
  • Do we have enough information of the project to be able to start?
  • Can we improve testability of the product?
  • Are we forgetting important aspects?