What Should/Could Be Running Inside a Tester’s Mind?

Let us first tear off those fancy wrappers that bedazzle the meaning of testing, and strip back to its simplest form. According to the Cambridge dictionary, testing is…

“the process of using or ‘trying’ something ‘to see if it works, is suitable, obeys the rules, etc.'”

Generally, testing is a practice that is exercised in different facets of life. Now let us lock on Software Testing, according to Wikipedia…

“Software testing is an ‘investigation’ conducted to provide ‘stakeholders’ with information about the quality of the software of the product or service under test. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the ‘risks of software implementation.'”

If we think about these two definitions, and try to forge the context, we would come up with…

“Software testing is a recurring activity (‘trying’) that needs critical thinking (‘investigation’) to understand the subject matter (‘…to see if it works, is suitable, obeys the rules’) necessary to unearth hidden anomalies (‘risks of software implementation’), and then framing the findings in a clear and concise manner suitable for the target audience (‘stakeholders’) to make sound decisions.”

Having said these, we’ll now share some points where we believe every tester should or could embody:


What works before may not work now, what tools you used before may not be applicable now and what process you have embraced so badly may not fit the current setup. Tech is always evolving and so should our way of handling it. However, we should always look back to its original definition and understand its essence.

    • Suggested Action: Be more flexible and open to other ideas. Breakthroughs happen outside our comfort zone. Learn from these and do not simply dismiss one idea from another.


Planning doesn’t automatically equate to overwhelming text on thick papers, intended to tell a novel about how you will test a product or service. The planning I’m referring to here is simply the act of preparing all the necessary items to make your test execution bear fruit.

    • Suggested Action: Have a think, “do I fully understand what the expected outcome of thing I am testing is?”, “Am I in the correct environment?”, “Do I need these scenarios for this activity?” – the list goes on!


Approximately 90% of the organisations that I have worked at, or have visited, resides in them a complex regression pack which keeps on getting bigger as time passes by. I strongly believe that an effective regression pack is a necessity, however it has to be lightweight. I believe the reason why regression packs become so complex is because the confidence in earlier stages of testing (pre-regression) is not great.

    • Suggested Action: Get more involved in the earlier phase of the development, strategise and cover all your bases and challenge teammates if necessary. A good and effective amount of testing in this phase will lighten the load on the regression phase. Smoke and Regression tests are great candidates for automation testing.


As obvious as it may seem, there are still bottlenecks that we may overlook where we should get quick wins. You will be able to discern these areas once you immerse in a squad/project.

    • Suggested Action: Be proactive in removing these dependencies early on as it will help you free up more time with what you are supposed to do (e.g. pushing test builds in an environment, fetching test data access to logs).


This may be neglected in some areas, such as putting key information in tickets, or putting key information tickets but those that can only be understood by you at the time (not good with succession), or putting too much information that is not necessary for the audience (bug reports / test reports), or verbal communication.

    • Suggested Action: If writing information, always think of the target audience and assess the important information that needs to be communicated, frame it in a way where the reader will understand its urgency. If communicating verbally, think of ways to take note of valuable information and put it into writing (e.g. place it in tickets, email or other means of communicaiton). Be more visual, people usually get lost with huge amounts of text.


Not physically executing or planning tests does not automatically mean you are not productive. Apart from a much-needed rest, investing your time in learning skills and current industry practices helps you become a better tester holistically. As mentioned, tech is constantly evolving so not only is our organisation trying to keep up but our neighbours as well. As a result, testing practice is also affected.

    • Suggested Action: Take a break once in a while throughout the day and Google testing topics or groups. Read articles, imagine, get creative and then reflect on the tasks you are currently doing and wonder if it makes much sense. Reach out to the community, not necessarily just a community of testers. You may even ask your developer/business analyst/product owner/designer how they may test a certain functionality. The goal is to challenge your own mindset and be able to think outside the box.