Testers come from many backgrounds. They are a diverse bunch, but they think differently. Testers complain they like to break things, they take a special thrill in delivering bad news. This is a common view.
However, contrary to the popular view, they don’t complain but offer evidence. Testers oust the illusion that things work all the time. Testers don’t enjoy giving bad news; they enjoy freeing their clients from the thrall of false belief. This is why thinking like a tester means practising epistemology. In this article, we mention ten such lessons that would help you think like a tester.
- Testing is applied epistemology that helps you test better
Epistemology is the study of knowing what you know. It’s the study based on evidence and reasoning and is a useful tool to establish the foundation of scientific practice. It is studied by educators, scientists and philosophers, as well as software testers who wish to succeed in their professional careers. Students of epistemology usually have one goal- learning how we all can improve our thinking. Applied to software testing, epistemology asks questions like the following:
- How do you know the software is good enough?
- How would you know if it wasn’t good enough?
- How do you know you’ve tested enough?
Studying epistemology will help you devise effective testing strategies, better recognize mistakes in your work, know what your testing does and does not prove, and construct defensible test reports.
- Testing requires inference, not just comparison of output to expected results
There’s a popular view that testers just execute test cases and compare what happens against expected results. This view makes testing seems like a straightforward comparison activity and ignores the fact that some clever person must design the tests and determine the expectations.
A test designer almost never has access to an authoritative guide to what should be tested, let alone what should be expected. And what guides are available are subject to interpretation. In real life, most test design is based on inferences or taken from experience that the tester infers is relevant. Moreover, these inferences change over time. To think like a tester is to be adept at the art of exploratory inference.
- Good testers think technically, creatively, critically, and practically
Technical thinking-The ability to model technology and understand causes and effects. This includes things like knowledge of relevant technical facts and the ability to use tools and predict the behaviour of systems.
Creative thinking– It is the ability to see possibilities and generate ideas. A tester will test only in ways that he can imagine testing. You will look only for problems that you imagine can exist.
Critical thinking-The ability to evaluate ideas and make inferences. This includes the ability to detect and eliminate errors from your thinking, to relate product observations to quality criteria, and to build a compelling case for a particular belief or suggested course of action.
Practical thinking-It is the ability to put ideas into practice. It includes skills such as making test techniques, applying test tools and effort and fitting it within the scope of the project.
Overall, thinking like a tester leads you to believe that things may not be as they seem.
- Black Box Testing is not ignorance-based testing
Black box testing means that knowledge of the internals of the product doesn’t play a significant part in your testing. The major benefit of black box testing is that a tester can think in a different way than the programmer, and thus, is likely to anticipate risks that the programmer may have missed. Black box testing is often referred to as ignorance-based testing because the tester is and stays ignorant of the underlying code. However, if your primary focus is on the source code and tests you can derive from the source code, you will be covering ground the programmer has probably covered already, and with less knowledge of that code than a programmer has. Thus, it is not an ignorance-based testing.
- Use heuristics to quickly generate ideas for tests
A heuristic is a rule of thumb; a way of making an educated guess. Because the number of possible test cases is infinite, we are stuck making guesses about what small population of test cases will be effective under the time and budget constraints we face. An experienced tester always collects and share testing heuristics in order to improve the quality of their guesses. Generally, a good set of heuristics helps us generate tests very quickly.
- Use implicit as well as explicit specifications
Not all references that contain important information on which to base your tests are explicitly presented to you. When a product violates an explicit spec, you have a relatively easy reporting task: “It violates the spec, therefore the product is probably wrong.” When an implicit spec is violated, you have to make more of a case.
While an explicit specification is a useful source of requirements information, acknowledged as authoritative by your clients, an implicit specification is a useful source of requirements information that is not acknowledged as authoritative by your clients.
- Use the logic of conjecture and refutation to evaluate a product
This method is based on the premise that a scientist can never be absolutely certain of any particular factor theory about nature. The method of making conjectures and trying to refute them applies to test in two important ways:
- It’s more powerful to test for the purpose of showing that the product fails than it is to show that it works.
- A well-formed belief about the software (how it behaves, how good it is, and so on) should be falsifiable. That means we should be able to imagine new information that would contradict our belief.