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 practicing epistemology. In this article, we mention ten such lessons that would help you think like a tester.
1. Testing is applied epistemology that helps you test better
The study of epistemology is all about realizing what you know. This study is based on reasoning and evidence. It is a very useful tool for establishing a strong foundation in scientific practice. This subject is taken up by scientists, educators, and philosophers. It is also studied by the testers who want to achieve success in their careers. The students of epistemology study with the aim of learning how to improve their thinking. Regarding software testing, this subject asks the following types of questions:
- What makes you feel the software product is good?
- How can you recognize if it was not good?
- How can you evaluate you’ve tested enough?
Having good knowledge about epistemology can help you in devising an effective testing strategy, recognizing errors in the work more efficiently, knowing what the testing does and doesn’t prove, and constructing rational test reports.
2. 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.
3. A Good tester thinks technically, creatively and practically
Technical thinking-The capability of modeling technology and understanding the causes and consequences. This involves things such as the capability of using tools and predicting the system behavior, and possessing an idea about the necessary technical facts.
Creative thinking– It is the capability of seeing possibilities and generating ideas. Testers can only test in how they can imagine testing. You can only look for the issues which you imagine may exist.
Critical thinking- The capability of evaluating ideas and making inferences. This involves the capability of detecting and eliminating bugs from your thought, relating the product appearance to its quality, and building convincing criteria for a specific belief or 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, if you think like testers, you will start believing that things necessarily aren’t like they seem to be.
4. 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 you primarily aim at the source code of the tests that you can extract from that source code, then you will cover the ground that the coder has already covered, and probably with a lesser idea of that particular code than a programmer has. Thus, it is not an ignorance-based testing.
5. Make Use of heuristics for generating ideas quickly for tests
A heuristic is a thumb rule; a method to make an effective 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. Experienced testers collect and share the testing heuristics, which lead to improved guesses. A good heuristics set helps us in generating quick tests.
6. 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.
7. 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.
Connect with KiwiQA to leverage focused capability for QA and Testing services.
