Tester job is to make things work, not the opposite!

Tester job is to make things work, not the opposite!

In my last post I forgot to mention the main idea I'd like to retain, which is, the tester Mission is to make the software work.

What we want, in the End, is to have working and satisfying software, with few relevant bugs. Let's not forget it. The more I get the software to work, the more complex scenarios I will build, and eventually the more interesting and relevant defects I will find.

If a tester gets stuck with basic defects, often superficial, often interface, but sometimes really blocking ones, he won't be able to advance in its mission, wich is to have working software. That's why I advised in my last post to start with simple and common, expected scenarios.

Corner cases are often interesting and exciting from an academic point of view, but in the long term will not yield so efficiently to working software. Although usually testing is seen as a way to find defects, I found out that on complex systems, our mindset should be focused on software success, not on software failures.

What should first tests address?

When planning a testing effort, or if you wish, when designing a Test Plan, some considerations may turn out very useful.

First tests on a given area are decisive. If we consider testing is Learning, or asking valuable questions to the product, then first questions are the most important ones, because we are getting a first contact with the product (first impressions tend to stick in our mind more easily).

When addressing these questions, we should expect answers like: "Yes, this feature is working exactly as I expected", or "Not at all, there is no way this could work". Answers like "in this particular situations, this might not work", or "I think this is working, but I am not sure if this is very useful" are discardable at an early stage, because we are trying to gather basic information, not exploring detailed scenarios.

We should seek the most common scenario, the main functionality, and try to setup ideal conditions so the software succeeds. At this point, we may say if the feature is working, or on the other hand, if it is not working at all.

Even after pass the very first test, after we say the feature is working, we will increase complexity of testing, but always trying to go for the next simpler and most common scenario that someone might want. This way we achieve:

-Continuous and steady knowledge growth, easier and logical learning. Our mental model of the product is built from the basis to the upper
structure, not the other way.

-Efficient Testing effort, every results are probably matched to our mental model, which is growing continuously, thus minimizing gaps in the complexity levels of our knowledge. Suppose we go for a complex scenario at a very early stage, and we find it is not working. My experience tells me that the test is often discarded, or at least it will have to be repeated later, after do some more simple tests. Often what we see as a product failure, is a (tester) knowledge failue, because we are exploring conditions and scenarios for which it was not built.

Because our knowledge in this early stage is extremely dynamic, Exploratory Testing (ET) may be very efficient, due to itts adaptability and dynamism (see literature on ET)

Status vs State

Ok, I'll tell you my two cents: a state is any condition which is durable or lasting (Zustand, Istzustand) whereas a status is a classification of state among several well-defined possibilities. An immigrant's status is either legal or illegal, and if he is the latter, he may be in an anxious emotional state.