Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Enhance Your Testing Skills with Mindset Tools

Enhance Your Testing Skills with Mindset Tools

Key Takeaways

  • Mindset Tools are a cheaper and effective way to develop a test mindset and enhance testing skills.
  • Mindset Tools are developed from test stories, therefore it’s easy to visualize yourself in the scenarios being described and easy to learn and apply.
  • They inspire you to be innovative and creative towards your observations and reflections.
  • Mindset Tools can help enhance your skills in both the technical and human aspect of testing and the releasing of a quality product.
  • You can develop your own Mindset Tools and become more valuable in your role as a tester, programmer, test or project manager. 


Quite a lot of testers often miss out on the mindset necessary for the testing and delivery of quality products. Sometimes it seems that quality consciousness is missing. Little wonder that some testers only find obvious bugs and why quality is far-fetched from the PUT (Program under test), despite the presence of testers on the project. Adding on to this is the overwhelming and unnecessary challenges that awaits a project, where individuals in each role (programmer, project manager, test lead, testers) lack proper understanding and appropriation of the level of test mindset that is needed for each role, in order to enhance the successful release of quality products. This article is about how I discovered a way to grow my test mindset, and how my discovery has been useful in enhancing my testing skills.

The realization that had me thinking:
What kind of tester am I, and what kind of tester do I want to be?

I started out as a "finder of obvious bugs". Well, this is what I call my start-up days as a tester. I believe many testers have been or are going through this stage, where they seem to be finding only obvious bugs.  I found myself in situations where other testers whom I eventually started to refer to as “good testers”, scooped out important bugs from a piece of software that I had already tested. I used to ask myself, “how did they find those bugs?” and “why am I not like them?”

I initially comforted myself with the thought that it was because they had more experience than me and that over time, I would hopefully become like them. But not too long after that, I observed that some inexperienced testers were also finding important bugs on a piece of software that I or another team member had already tested. There were also some testers who had years of experience but only found “obvious bugs”. Then I realized, oh..., hem..., Ok... it seems like it’s not a-b-o-u-t years of experience!

 So, I said to myself, maybe they have completed some certifications. I did the same, but it didn’t help much. I remember going in for an interview during this period, and the interviewer asked how I would test a particular program. I started to tell him how I would write test plans and test cases the way I was taught in the certification that I did. He said to me, “…you know what; I don’t want testers like you! I want a tester who will not have to write long test plans before testing and a tester who can test with just one line of a test case.” That interview made me realize that my certification had not taught me much.

Then it occurred to me that maybe the “good testers” have been reading books about testing. So, I started to read books. This proved to be quite helpful, but not speedy enough to get me to where I thought I should be.

I also observed that the “good testers” were given more recognition on the project. The test lead will usually assign more critical and important features to them, while the “finders of obvious bugs” are assigned to work on less important and less critical features/tasks.

It didn’t feel good to be a “finder of obvious bugs” and a tester whose only tool was a certification. I desired to be a valuable tester, who helps provide important information that can help improve the quality of products.

One thought that struck me often, and which became a question that I asked myself from time to time as I thought about how to make my desire a reality, was “why do those testers, whom I refer to as “good testers”, see and find things that I don’t see and find?”  If I could find this out, then I might have a clue on what makes this difference between "good testers" and myself and how to grow. So, the way forward was to embark on finding out!

The discovery that changed the way I test: the Tester’s Mindset and Mindset tools!

The Mindset Tools

As I thought about what makes the difference, it occurred to me that maybe I could learn something from what was happening around me. So, I started to observe, analyze and reflect on occasions when I or other people in my team discover important bugs: how did I/they find them? What were my/their thought processes at the time?

My reflections drew my attention to test stories resulting from bug findings, and my day-to-day encounters as I tested and interacted with individuals in different roles on the project. I discovered that:

  • My mindset played a major role in how I found bugs and how good my testing was

As I continued to observe, analyze and reflect, I came to the conclusion that testing requires that I:

  • Keep my mindset flexible when I test
  • View different test task/features, from different angles, with different lenses and different mindsets

Therefore, I need to vary my mindset/reasoning towards the PUT whenever I test.

To keep my mindset flexible and help me look at things from different angles:

  • I identify mindset approaches that I find useful in test stories resulting from bug finding or interaction occurrences on the project
  • I put a label on the identified mindset approach. I call each labeled mindset a Mindset Tool
  • I come up with a name that makes it easy for me to remember or connect with each identified Mindset Tool
  • I itemize lessons learned from the test stories, which I call Mindset Tweaks
  • I use the Mindset Tweaks to initiate the use of each Mindset Tool by tweaking or adapting my mindset according to the Mindset Tweaks whenever I test

Examples of Mindset Tools that I Identified and labeled from test stories include

  •  “User” Mindset Tool
  • ‘‘Already tested’’ Mindset Tool
  • “Lazy Tester” Mindset Tool
  • Analytical Mindset Tool
  • Critical Thinking Mindset Tool
  • Curiosity Mindset Tool
  • Bug Conviction Mindset Tool
  • Communicator Mindset Tool
  • Trust, Business Mindset Tool
  • Team leading Mindset Tool
  • Criticism &  Accusation Handling Mindset Tool
  • Embarrassment Handling Mindset Tool

BAM! I tell you, this was the beginning of an explosion into the world of better and effective testing, as well as rapid growth!

So I thought to myself, this is what makes the difference! The inability to vary our mindset means we can only see the obvious! No wonder some testers only find obvious bugs, and why quality is far-fetched from the PUT, despite the presence of testers on the project!                                    

The Tester’s Mindset:

As a sequel to these experiences, I came up with the definition for the tester’s mindset. I defined the tester’s mindset, or the test mindset, as:

  • A way of reasoning that determines behavior, outlook or mental attitude of a tester, programmer or project manager towards the testing of a PUT
  • The reasoning that is needed in questioning and investigating the PUT. This is inspired from the definition of testing, as questioning a PUT or investigating a PUT to gain useful information about the product’s quality (James Bach)
  • A behavior that defines how a tester, programmer or project manager adapts his/her mindset or reasoning in relating with the PUT and everything that is connected to its existence e.g. test activities, fellow programmers, project managers, team members etc

The Tester’s mindset requires:

  •  The tester to consistently answer the question, "how do I want to relate to the PUT and everything connected to its existence (including humans) in order to effectively provide valuable information that’s needed for making decisions about the quality of the PUT?"
  • The programmers, test lead and project managers to consistently answer the question “how do I want to support testing, thereby enhancing the development and release of a quality product?”

Mindset Tools: How does it work?

To explain how I use the Mindset Tools, I will give three examples.

The first example is the “User” Mindset Tool:

Background test story: During my early days as a tester, I experienced times when I discovered certain bugs, and after evaluation, the programmer or head of software team would say “the user will not use the product that way!”. So the bug does not get fixed. On one occasion, the product was released and a defect to which the programmers said, “the users will not use the product that way”, was among the first set of defects that were reported from the field.  And guess what? After investigation, we discovered that the users actually used the product the way the programmers said they wouldn't use it!

To believe that users will not use the product in certain ways that we do not expect, is a fallacy! Hence the need to broaden our imagination of how users will use the product. Based on this test story, I labeled the “User” Mindset tool and identified the following Mindset Tweaks which I use for adapting my reasoning when I test. They have been very useful in finding more important bugs in this category.

Mindset Tweaks (extracted from lessons learned):

  • Become the user, i.e. think like the user when you test (both programmers and testers)
  •  Users will experience the product using their 5 senses. For example, think about: how they would touch, what they would feel when they touch, how they would possibly react when they touch, taste, smell and hear sounds from the product
  • Human beings are exploratory in nature, hence users will explore!
  • Gather information about how the users could use the Program Under Test to help your reasoning

A second example is the "Already Tested” Mindset tool.

Background test story: Often times I have encountered situations where it was said that a piece of software has already been tested, and that all I need to do is a quick check.  On one occasion my programmer colleague told me he had already tested a function in a feature and that I shouldn't bother testing it again. But due to precedents, I decided to still check it briefly. To my amazement, the function failed on what the programmer said he had tested.

One challenge that I had was, how to tell him I still went to check what he said I shouldn't test. Well, I solved this by setting up a test scenario that included the use of the failing function in my current test. So, I invited him to the lab and explained that I observed a behavior that I didn’t understand during one of my tests, and that I would like him to have a look at it. When he saw what had happened, he said, “…but I tested this before”. He further said, "Vivien, you won't trust me again”.

I could see the embarrassment written all over him and knew I needed to help the situation. So, I responded, “not at all, believe me, I trust you and I know you always strive to do a good job. However, my understanding is that it's the nature of code to have bugs” (I also used the embarrassment and the trust mindset on this occasion). 

On another occasion, a programmer colleague of mine told a tester to merge a piece of software to the main branch without testing. According to him, he only made an insignificant change in cleaning up a line of unused code, which was previously commented out. But unknown to him, he had deleted an additional line of active code in the process.

So, the tester merged without testing, and after that no one could use the main branch of the software. During investigation, it was discovered that the cause of the problem was the piece of software that he told the tester to merge.

Based on the lessons learned from these test stories, I came up with the name “Already Tested” Mindset Tool and the following Mindset Tweaks which I use for adapting my reasoning when I test:

Mindset Tweaks:

  • Consider the quality of testing that was previously done
  •  Consider “pressured tester/programmer possibility”
  • We see differently, reason differently and have varying expertise as programmers and testers
  • Consider so called “insignificant changes”- there are no “insignificant changes"

A third example is the “The Lazy Tester” Mindset Tool:

Background test story: Sometime ago I was sitting in a meeting and the head of software said “… the lazy tester found that bug”. He further said, “it’s good to have them on the project, but not too many of them.” This caught my attention. I took note of the Bug report ID and went to find out who this "lazy tester" was.

I discovered that the person being referred to was a tester colleague of mine, who usually finds quite important bugs. But the way he finds them is that while he is testing, he takes a break to go to the coffee machine for example. At the coffee machine he gets carried away talking to a colleague, forgetting that he was running a test. When he gets back to the Program Under Test, he finds out that it is in some abnormal state: an error has occurred! He reports the error including an explanation that he got carried away talking to a colleague. Hence, he got the title:  “ Lazy tester”.

Analyzing this test story, I decided to research laziness. I discovered Bill Gates' quote, which says: “I will always use a lazy tester to do a difficult job because I know he will always find an easy way to do it”. Then I thought to myself:

  • There seems to be some value in lazy people, hence I named this Mindset Tool “Lazy Tester’s” Mindset Tool
  • There are bugs we might never find, except when we test like the Lazy tester!
  • I don’t have to be lazy, but switching to this Mindset will get things done!

So, I came up with the following Mindset Tweaks which I use for adapting my Mindset when I test:

Mindset Tweaks:

  • Explore what the lazy tester does; they explore the software in ways that hard working testers don’t!
  • For Test leads: explore talents in your team; don’t write off “lazy testers” for example

The Test Mindset diagnosis: Mindset Tools are for everyone!

I further observed occurences that resulted in interaction within the team and I couldn't stop wondering:

  • Why should the tester get blamed for not finding certain bugs, when all they’ve got is an impossible time plan?
  • Why should programmers be rated on how many bugs are found in their code, or testers be rated by how many bugs that they find?
  • Why wouldn't bugs be found during production if the expectation when testing is that the tester should just tick a checklist?
  • Why wouldn't the PUT not be “as buggy as bug”, when the tester’s brain and mind is being limited to strictly follow written test cases, thereby restricting their ability to reason beyond the scope of the written test cases? 
  • Why should testing and the quality of the product be seen as the sole responsibility of testers or programmers?

These perceptions wreck our projects due to lack of proper understanding of what testing involves.

Now, let’s imagine a leaking boat and the attitude described in the picture below:

It doesn’t matter whose side the hole is on- if the boat sinks, everyone is sinking! In the same vein, if the project sinks, everyone will be affected, not only testers and programmers.

So, come to think of it:

  • The Programmers say: I want to build the software
  • The Testers say: I want to test the software and provide input for improving quality
  • The Project managers say: I want to deliver a working quality software to the stakeholders
  • The Marketing guys say: I want to sell the software profitably

Each of these roles often expect that the testers would find all the bugs in the software.

However in my opinion, successful and effective testing starts with individuals in each role recognizing that:

  •  Testing has a dependency on their role, and the success of their role has a dependency on testing. In other words, they are not successful until testing is successful.
  • Building quality software is the responsibility of everyone, hence all roles in a software development projects must cooperate together
  • Understanding the psychology of each role and what’s most important in different circumstances is needed for the development and release of quality software
  • Everyone working with the PUT needs a mindset that works with the understanding of the goal of each role and theirs’.

If you agree with me on the above points, then you will probably agree with me that everyone working with the PUT needs a test mindset to develop and release quality software! And if you agree with that, you will most likely further agree with me that the Mindset Tools are for everyone!

If everyone working with the development of a product has a reasonable appropriation of test mindset and we work with an understanding of how our work impacts testing and the eventual quality of the product, then quality wouldn’t be farfetched!

Discovering and developing your own Mindset Tools

Often times we are not observant, and when we are, we don’t reflect on our observations, and if we do, we most probably don’t draw conclusions or learn from our reflections. Test stories are everywhere, every day, all around us as we work in software development projects. If we dare to explore them, I think they can be a great source of learning. I came up with the idea of the Mindset Tools by observing, reflecting and responding to my reflections, by adapting my reasoning to the result of my reflections.

People often ask me: how can we cram the Mindset Tools and the Mindset Tweaks? This question actually got me thinking and what I came up with, is that there is no need to cram. Since the Mindset Tools are built from test stories happening all around us, then we have the possibility to naturally learn them and even develop our own Mindset Tools, if we become conscious of the process. Hence I propose a Mindset Tooling model as below:


  • Observe what happens in your daily tasks  
  • Pay attention to how you/other testers find bugs
  • Learn to tell/take note of test stories resulting from interactions among Testers, Programmers, Test Leads and Project Managers in the team


  • Reflect on the observed activities of the day, bugs found, how they were found and situations resulting from Testers, Programmers, Test Leads and Project Managers’ interactions in the team etc


  •  Identify and label the reasoning/mindset that you find useful in the test stories and while executing your task on the project
  • Come up with Mindset Tweaks by itemizing statement from lessons learned
  •  Adapt your reasoning based on your identified Mindset Tools and Mindset Tweaks as you execute your task on the project


If we dare to observe, and dare to reflect on our observations and further dare to act on the result of our reflections, then we have dared to learn and grow! As I started to use the Mindset Tools, I started to grow and become better at testing. I became a more valuable tester, whose opinion mattered in decisions that were being made about the product. I saw things differently and found important bugs, in addition to the obvious ones. My programmer colleagues would ask my opinion on how I think an issue should be resolved or what I think is the best solution for fixing particular bugs or issues. They think Vivien sees everything that could be wrong in the software. This, I believe, is because they discovered that my reasoning about the software has become valuable.

I find colleagues asking me how I discover certain bugs, because sometimes they are puzzled by what could have made someone think of such valuable scenarios. My Project Manager had given feedback to my company saying: Vivien is a “super star” tester. On one occasion, we had a visiting customer and the programmers had introduced me as the “best tester in the world” (…though I think I’m very far from being best or super star tester, but I guess it’s their way of expressing the value they have discovered in the way I test). One other interesting thing, is that as I practiced using the Mindset Tools, I noticed that it also impacted the way the programmers worked; they also grew, learnt and improved their test mindset.

Thanks to the idea of the Mindset Tools. I grew and am still growing!

Link to Mindset Tools slides online: Mindset Tools Slides

About the Author

Vivien Ibironke Ibiyemi currently works for House of Test AB. Some folks call her by the native name, Ronke, but she also likes to describe herself as a terrific tester! She has a background in Electrical Electronics Engineering. Her experience as a tester has been in the mobile industry and medical technology. Ibiyemi also studied an MBA and MSc. in Electrical Engineering. The blend of the MBA together with her testing profession empowers her with the possibility to leverage the testing skills with a certain level of business mindedness. She's quite excited and passionate about testing - testing has been more than a profession- it has been a way of life! You can follow her on twitter, linkedin.

Rate this Article