It is not always what it seems

While reading this book from Oliver Sacks: "The man who mistook his wife for a hat: and other clinical tales" I was triggered by the chapters who are dealing with losses. In those chapters stories are told about people who have to feeling they are loosing some parts of their mind or body. or they even don't know they are missing capabilities.

What I learned from those stories was that obvious simple identified losses can lead to different judgements. It is obvious to say when a person is not able to use an arm the arm is not functioning. When looking more in detail you can learn more from it. There might be other symptoms who can help to create the proper judgement.

I noticed in software testing we also make judgements. Sometimes under time pressure wrong judgements. I can imagine that those conclusions are drawn based on experience and learned methods/tricks. This is a pitfall we all live in. We should be aware when making judgements and exposing them to others that we question ourselves if the conclusion is based on the symptoms, symptoms combined with experience or s our experience leading.

There can be more reasons why things are failing. There might be other directions we have to look at. I think it is human nature combined with experience that we are tending to look at complex situations. In the mentioned book a quote was used to remember us that we are missing the obvious things.

In chapter three Oliver Sacks quotes the philosopher Ludwig Wittgenstein: "The aspects of things that are most important for us are hidden because of their simplicity and familiarity. (One is unable to notice something - because it is always before one's eyes.) The real foundations of his enquiry do not strike a man at all. Unless that fact has at some time struck him. - And this means: we fail to be struck by what, once seen, it most striking and most powerful. "

While reading this book I noticed that things can be different then they are. We can learn and should learn also from other disciplines. I would recommend this book to all other testers not to become a neuropsychology specialist, but to reshape your vision. It might help you when you make judgements to rethink them before you expose them. I believe that looking at other disciplines and combining/ translating them to software testing can help you (re-)define you borders of testing.

Is finding defects earlier cheaper?

Most of us are aware of the Boehm-curve which explains that finding defects in an earlier stage is cheaper to solve.
I'm sure there are lots of arguments available to stick to this statement. Unfortunately I noticed that a lot of testers are using this argument to test almost everything. They are extending the test phases. They are giving advice not to ship the software to productive systems as there are lots of risks.

There might be a slight difference between newly build software and software under maintenance. The major thing is that software becomes bad not because the number of issues which are in the code, it becomes bad because the functions, framework which comes with the code is not providing enough service to make the business using it.

Even with bad software people can work. As long as the benefits of earning money with that code is more then it would cost to solve issues immediately it might be worth to ship and use the software.

For example: to withhold software to use, you are not able to gain money which supports the business case. If you delay the system with a few months, are you not loosing you competitive strength or loosing the money you intended to make? If you are able to identify the strong and the weak points in the software, if you are able to explain what and how to use it and you are still able to make the money based on the services you are able to deliver now, why not ship it?

Finding issues might be cheaper to solve in earlier stages, only you need first the ability to make money before you can extend the project to find and solve everything. I can imagine that is the system is mandatory to continue the business you are also willing to accept the risk of having issues in the system. It is more important to be able to act promptly when issues becomes problems.

I would rather suggest instead of claiming it is cheaper to find issues earlier and therefore continue testing, be honest and ask yourselves if you are able to provide information on which clients can make there decisions. Don't fall in the pitfall to claim that this can only be told based on coverage. If you are able to explain what you have done and how you see the system and what you didn't do and you have faith in you and your team. You already made a huger step then speaking about coverage. If you are able to tell what functions might possible cause risk and how you are tending to monitor it and you are able to help fixing it within time you are more capable then telling you tested well and give negative advice as there are issues which might bother some people.

It might depend on the development method you choose and the organization who stands behind you if this can be successful. I noticed situations were it was cheaper to ship products with some issues or some risk. Money was made immediately instead a few months later and the issues which were found in the first days were faster solved and tested then during the normal test project.

So it finding defect earlier cheaper to solve? Yes, is it cheaper to withhold the system to go production? I think most of the times we have to rethink the verdicts before making our statements.