SECURE: Mindset Framework for Software Tester
Introduction
Testing is a challenging task that requires practice and experience to do well. It is also an activity that some people seem to be better at than others — some people just seem to have a “tester mindset”.
For effective testing to be successful, you must approach it with a mindset that is focused on proving that software doesn’t work. This means thinking like a tester and acting like one in your day-to-day work. A tester is someone who believes that software can fail and should therefore be tested as often as possible.
What are the mindsets that testers must have?
For this sole purpose, I want to introduce the SECURE framework. SECURE stand for SKEPTIC, EXPLORATIVE, CURIOUS, URGE TO BREAK THINGS, RISK ORIENTED, and EMPATHY.
If you are interested in my other writing about software tester skill, you could read 10 Must-Have Skills for Software Testers or Soft skill for Testers: Keys to Effective Communication.
Do you know that we have a different mindset and approach to the work we are doing as testers?
As a tester, you have to understand the difference between a developer’s mindset and yours. Developers are more focused on writing code while testers are more focused on testing the code.
When we test software, we want to make sure it works as expected and meets customer requirements. We check that all functionalities are working correctly before delivering them to customers or stakeholders who will use them in real-world scenarios.
SECURE framework.
You may not have heard of the SECURE framework. that is a new framework that I propose from a summary of several mindsets that a software tester must have. It is a model that describes the mindset of a tester, and it’s something that I think every software tester should know about.
The SECURE framework consists of four characteristics: SKEPTIC, EXPLORATIVE, CURIOUS, URGE TO BREAK THINGS, RISK ORIENTED, and EMPATHY. These traits are not unique to testers but they are particularly important in testers because they help us when we are trying to find bugs in our products or services (or at least this is how I see it).
Being skeptical of all things, programs, processes, services, services integration, etc.
The first step to becoming a secure software tester is to develop a skeptical mindset. Always assume that the bug exists somewhere in the corner of the codes and question everything you see, hear, and do.
“Anything that can go wrong will go wrong.”
This means that we should be always looking at things from different perspectives, questioning our assumptions, being skeptical of things we do not understand, and thinking of ways in which the software may break or fail unexpectedly.
An explorative nature and instinct which prompts us to try out things to see how they behave
Exploration is the key to creativity, problem-solving, and curiosity. Exploratory is all about asking questions, trying things out, and seeing what happens. It’s about being curious about your software and its behavior so you can find new bugs.
The best way to understand the mindset of an exploratory tester is by looking at their actions:
- Ask lots of questions about the product we’re testing (what does it do? What are its features? How does it work?).
- Play around with it until we know enough about its behavior so that we can start using deductive reasoning skills to find bugs (what might happen if I do this?).
Curious and questioning mind in general, including other how things work or ways of doing things
You should be curious about the software and how it works. You should be curious about how the service interacts with another service, whether that’s through an API or a user interface.
You should also be curious about why the software works the way it does, and if there are any limitations or assumptions made by developers that could lead to problems later on in development.
Finally, you need to think critically about what could happen if your assumptions are wrong: what would happen if users didn’t like this feature? How would we handle X scenario?
Having the urge to break or do things unconventionally which is also born out of curiosity
In a sense, you’re like a little kid who wants to see what happens if he pulls the plug off his TV or pokes it with a fork. You want to know how far you can go with your testing and whether you can break something.
The urge to break things is also born out of curiosity: “What will happen if I do this?” In other words, it’s an expression of our desire for understanding by trying different things until we have an answer.
Risk-oriented behavior is where we tend to think about the risks
We’re risk-oriented people. You think about the risks and try to minimize them, which is a good thing because it helps find bugs early in the development cycle.
But this can also lead to some problems: you may find yourself focusing too much on how things could go wrong instead of focusing on finding ways for them to go right!
When we focus too much on what might go wrong, it can lead us down rabbit holes that distract us from our actual goal —assure that our software is good enough before they get into the production environment.
Empathy for the users of the systems we develop
Empathy for the users of the systems we develop is an important part of our job. It helps us understand their needs and wants, which can help make our products better.
Empathy is also important because it helps testers understand their business context better, which means they can give feedback on what’s needed by the business in terms of testing services or tools. This can be especially valuable when working with new projects or teams where there isn’t much knowledge yet about how things work (or don’t).
SECURE may be not the best framework or even the best way to represent the software tester mindset. But in my opinion, it summarizes my experience of how I think as a software tester.
Conclusion
When you think about it, SECURE is about always Skeptical bugs exist and living in the corner of the codes. Explore the software to find those bugs. Be curious about everything. Find how to break things in as creative ways as possible. Always think about the risk in the software, it may during implementing a new framework/library, building new architecture, or implementing new ideas. And think using a user’s hat. What the user wants, how the user will use the end product, and will the product bring benefit to the user?
