The tester doesn’t just compare what happens against the results you expect. This makes testing seem like it is straightforward and mindless. However, this ignores the fact that a person has to design the tests and determine for themselves what the expected results are. This would be a simple method if the tester has access to a person that will confirm the expectations 24/7. What happens in reality? The tester creates tests based from experience and include things that are relevant. What gets more interesting is that, similar to life, our perceptions and how we think change based on what we experience. To understand this truly, we must understand how to think like a software tester described below.
The ability to create a model of the workflow of the business and the system being tested, understand what the implications are for bug fixes and new features. The tester is a technically minded individual has the capability to use certain tools or equipments to their fullest to see their mission through.
- What tools do you need?
- Are your tools up-to-date?
- Are your test scripts up-to-date?
- Is your local update with master?
- Are the requirements document up-to-date?
- Is the business rules document up-to-date?
Remember my first post, your mission is what drives you and you aim to complete your mission in the shortest time possible.
A tester can come up with solutions to problems but an excellent testers come up with brilliant ideas that can change the way people look at things.
The tester is a creative individual, the tester has ideas that can be executed in such a way that it fulfills the objectives to achieve your goals. The tester has the ability to generate ideas and see possibilities that others cannot see. The design of the test will look for problems that can be imagined and actively look for problems that can exist.
How is a tester creative? Like a painter, the tester has a vision, a mental picture in their mind when you design tests. A tester creates models on what the tests are, why choose those tests, critique his own tests, explicitly mention limitations, and come up with a way to show how this model can be shown to non-technical people.
Critical thinking is a way of thinking in which the thinker improves the quality of his or her own thinking using analysis, assessing, and reconstruction of thoughts. In testing terms, it is the ability to evaluate idea and make decisions on what to test. This includes the ability to detect and eliminate errors from your thinking, to relate product observations. The tester has high standards - he does not accept anything less than the best use of his knowledge. He effectively communicates his ideas and his problem solving abilities. Do not forget, it is the tester’s commitment to be the light in the dark for the team, he makes himself responsible to make the best use of the resources he was given.
Here are a few ways in which a tester does critical thinking
Tunnel vision - This is one of the tester’s biggest enemies. Imagine you ran 10 tests and you should have ran 20 tests. This means that the the tester has failed to imagine an entire category of test; testing we wouldn’t have performed even if we had twice the time and resources. What can the tester do to reduce tunnel vision? Talk to your developers, your product manager, your marketing team, your customer success team. You serve the user, so why not ask the user themselves on their thoughts and feedback?
Forward Thinking - The tester works from their pool of knowledge and what they don’t know. How does a tester utilise this type of thinking? Imagine a submit button for a retail website after having selected products to purchase. These questions need to be answered - What should happen when I click on the button? Am I in the right URL? Have I been redirected to the correct page? Once I have clicked on this, what are my next steps?
Backward Thinking - The tester again works from their pool of knowledge and knows what he expects whether it’s from his mind, requirements document, specifications document, or his test plans. Visualise the “Contact Us” page of a website you know about and you are testing - Does it satisfy the specifications? What about browser compatibility? Is it also working for mobile operating systems? The tester works from he suspects and confirms his suspects with valid documents.
All tests are performed to answer a question about the relationship of the product and how it should be. Bugs do not show a giant sign saying “I AM HERE” - They like to play hide and seek. In any test activity, ask yourself what questions drive your evaluation strategy - Am I testing within scope? What am I not testing? Have I consulted others about the tests I’ve written?
The tester not only thinks technically, creatively, and analytically. The tester is also a practical thinker, he puts idea into practice.
Picture yourself as the test manager, you have 2 testers alongside you. The business needs to have tested a release by a certain time so the project is in schedule - What do you do? One thing that can be done is identify the issues that can happen, prioritise them by their likelihood of happening and their impact, and emphasise the highest priority tests during execution.
Apply the tools techniques and make it fit within the agreed deliverables. Found a bug that is detrimental to the release? Notify your stakeholders, you’ve done your job - You have allowed the stakeholders in your business to make decisions based on how the product has performed with your tests. You serve the users - If you are not satisfied with the product then do not release. Now with the bug, you must work with the team to ensure that you get to the bottom of why it happened. If you find that there is nothing to improve upon, you are wrong.
Testing based on not knowing the internals of the product. This type of testing is learning about the user, their expectations, their needs, the technology, the configurations the software will run on. This is an advantageous position as the tester thinks fundamentally different to the programmer and are more likely to anticipate the risks that the programmer missed.
Black box thinking is not ignorance based testing. Some critics states a few disadvantages to black box thinking like redundancy of testing when the developer has already completed the testing. This way of thinking also undermines what testing is about, a different perspective, the excellent tester with more knowledge about the user, the needs of the business, and how the product works will bring more to the table than the average tester.
How do you improve how you think?
Gather More Data
So you want to improve the way you think? Gather more data and use this data to back-up what you say. Abductive reasoning, in its simplest term it is just evidence to your reasoning. Imagine going to your medical practitioner, you sat down on the chair and then he suddenly gives you a medical prescription without asking questions - How would you feel? I certainly hope that this has never happened to you and wish for it to never happen.
What do you need to do to improve your reasoning?
- Research Information
- Look for more information
- Choose the best conclusion
This is the basis of science. Looking back to the doctor example earlier. Here is a more ideal scenario - You go to your doctor, tell him the medical issues that you are experiencing. The doctor then makes a mental representation as to what the problems could be. The doctor then asks you a series of questions to confirm and ignore certain illnesses that he has thought of. The doctor will then choose the most coherent explanation that accounts from all the data you have given and with his or her experience, makes a decision.
Testing, you have to test the login form for this new site. What are you going to do?
Research Information - What are the specifications, have the user acceptance criteria been written? Did this ticket go through the whole testing process? What are the implications with this ticket?
Analyse - Why am I testing this? Is this feature really needed? Is there a workaround?
Look for more information - Talk to your programmers what do they expect? How about the product manager, how about the customer success team? Do we have actual users in the building right now?
Choose the best conclusion - Now that you’ve gathered your data, choose the one that has the best evidence. Now you can now create a test strategy, write test scripts, now you can start testing.
The difference between average testers and excellent testers is how they think: Why do they chose that test strategy? How does he explain his thinking in a clear and concise manner? If you want to be an excellent tester,learn your role , learn to be effective, and learn to think like one.
This piece of writing was inspired by this book: