I’m Abdulrozaq, and I recently transitioned into the fascinating world of testing. With a degree in Economics and a background in software development, i have worked on various projects with amazing people. While these experiences were rewarding, I found myself searching for more fulfillment. Out of curiosity, I explored the testing field and have been captivated ever since.
Like every beginner, I immersed myself in everything I could find about testing. Testing is one of the most challenging tasks in the Software development life cycle.
Testing is a challenging skill to develop, requiring practice and experience. Despite common misconceptions of it being repetitive and boring, I love the variety it offers.
Testing involves mindset, questioning, analysis, and risk assessment, which goes beyond what is visible on the surface.
One of the hardest things to explain is the way the mind works, as many components influence its direction. We all know how to listen, read, and speak, we have been doing all these our lives yet we possess more of this skill than each other. This is why you need the tester “mindset” to be a tester.
What is the mindset and how do you learn and develop it within yourself?
Here are the five things I found that set Great Testers apart:
Inverted Thinking and the Burden of Proof
My first introduction to testing was from James Bach, who said “ A tester’s job is to gather evidence and draw inference, not believe what they’ve been told. Testing is detective work-like solving multiple murder cases where everyone is a suspect.”
This short phase encapsulates the idea of the “Inverted burden of proof” Developers build software and believe it works perfectly. Your focus as a tester is to believe otherwise. Testing the software as a tester you are thinking of ways the software will fail. Testers help to educate the developers about how their software works. Just like a detective believes everyone is a suspect until proven innocent, likewise, every software is considered buggy until tested.
Adopting this mindset constitutes a paradigm shift. Testers must seek the underlying complexity behind the software's apparent simplicity and cannot conclude its functionality by mere observation. Instead, you look for issues to be exploited and vulnerable components for possible failure.
Great testers approach testing with an inverted mindset by testing the actual software against the imagined, through imagination, questioning, rapid learning about the software and constantly reanalyzing risk to provide evidence to developers that their software is not functional and confirm bugs that sneaked passed them.
A quote from the popular TV series Better Call Saul “We don’t prove innocence, we expose flaws in the assumption of guilt”. This mindset of seeking out and exposing potential flaws, rather than just confirming that everything works, helps good testers to test effectively.
Empathy and Roleplaying
“The significant problems we face cannot be solved at the same level of thinking we were when we created them”. — Albert Einstein
If developers write code to build software for people to use and testers test software to meet requirements, it is only right for testers to think like end users when testing, analyze their interaction with the product, and predict their responses and reactions. Understanding user objectives and emulating their behavior helps to identify real-life issues.
User empathy is the ability to imagine and predict what the user might do through inquisitive questioning like what would the user do? how would the user deal? mirroring their state of mind.
Roleplaying is a valuable mindset skill that great testers use when testing, it gives room for multiple real-life scenarios and usability experiences.
Challenging Assumptions
This is one of the most commonly used to characterize the thinking of a tester. Challenging assumptions is about effective questioning. The software development life cycle entails a lot of assumptions regarding how code will run, system will interact, users will interact with the interface.
Challenging assumptions is much like solving a mystery uncovering the hidden truth behind the software. A good tester, is like a detective who doesn’t just look for what is expected they challenge assumptions, question everything, and consider all possibilities. This mindset leads to discovering issues that might otherwise go unnoticed.
Sonar helps dolphins see; questions help testers find bugs
Dolphins use sonar to “see” in murky or dark water. They send out a click sound and wait for the echo to return. Once they have enough echo responses, they can navigate, find prey, and avoid obstacles and predators. Questions are the business equivalent of sonar. Asking the right question will help you find your way through a problem, and locate hidden defects.
For example, instead of merely confirming that a feature works as per the requirements, a tester might ask, “What happens if the user does something unexpected?” or “How might this feature break under certain conditions?” These questions push the tester to explore the software more deeply, uncovering potential problems that the developers might not have anticipated.
Intuitive Thinking and Exploratory Behaviour
There’s a common misconception about testing that it is all boring, repetitive task-following steps and automation. If you approach testing as not one of the most challenging tasks then you are doing it wrong, because that’s what it is. Even with some repetition and automation, testing involves exploring clues, applying logic, and engaging in critical thinking. It’s often exploratory — you don’t always know where you’re going when you start, but there are always clues to guide you along the way. Testing is an unpredictable activity that requires intuition and critical thinking.
Many people assume that it’s all about running the same tests over and over again to confirm what we already know. But in reality, testing is far from boring — it’s an intellectually engaging process that requires sharp intuition and exploratory thinking, much like a detective solving a complex case.
Exploratory testing is a crucial mindset that breaks the mold of repetitive testing. Unlike automated testing, where the tester follows a set of predefined steps, exploratory testing is unpredictable and non-linear.
In exploratory testing, you don’t always know where you’re going when you start. Instead, you are constantly learning about the product, assessing risk, exploring the functionality, and gathering approaches to use along with exploration. It is like solving a jigsaw puzzle each new finding is a clue that guides the next step. This approach is critical in uncovering issues that wouldn’t be found through traditional, repetitive testing methods.
Exploratory testing is a solid part of a tester’s arsenal. I recommend checking out James Bach’s blog Exploratory Testing Archives — Satisfice, Inc. for more understanding of this approach.
As a tester, you need to be comfortable with starting your journey without a full roadmap. The unpredictable and uncertain nature of testing can be unsettling for some, but the best testers thrive in such environments.
Recognition of Human Nature
Testing is a phase in the software development lifecycle, a testers should have in mind that the software they are testing is a product of human collaboration from the initial stage to the testing stage.
Understanding the Human nature in testing makes you a better tester. Yes, since software is built by people for people to use. This will also help you to see that defects don’t just appear in the software they grow with them and get bigger as the software grows.
Approach testing with this mindset helps to make room for human error and unexpected user behavior when testing. Error range from all stages of the software development that involve people from the planning to deployment stage
With this firmly in mind, make you understand that bugs are created by human behavior when the Project Manager plans, business analysts analyze, system architects design systems, and developers write code. The bug you are looking to find will be the error from the activities of people involved in the software development lifecycle.
Top comments (0)