Vivien Ronke Ibiyemi, the terrific tester has been an inspiring tester and we had the privilege to ask and learn about the Mindset Toolkit that she has developed as part of her testing learning journey. Read on to know more about the tools that she uses and which ones are her personal favourites.
Do introduce your Mindset ToolKit to our testers?
The Mindset ToolKit presents an approach that uses what I call “Mindset Tools” for testing and development of testing skills. This approach was invented basically by Observing, Reflecting, Identifying and Adapting the reasoning during the test. Now, what do I mean by this?
I started out as a “finder of obvious bugs”. Well, that’s 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 some other testers whom I eventually started to refer to as “good testers”, scoop out important bugs from software that I already tested. I used to wonder what was the difference: “how did they find those bugs and why am I not like them?”.
Observations: As I thought about what makes the difference, it occurred to me that maybe I can learn something from what’s happening around me. So, I started to observe, analyze and reflect on occasions when I or the other people in my team discover important bugs: how did I/they find them? What were my/their thought processes then?
Reflections: My reflections drew my attention to test stories resulting from those occasions of bug finding and my day to day encounter as I test and interact with individuals in different roles on the project. I discovered that:
- my mindset played a major role in how I find bugs and how good my testing was.
I came to the conclusion that testing requires that:
- I keep my mindset flexible when I test and
- View different test task,
- From different angles,
- With different lenses and
- Different mindsets
Therefore, I need to vary my mindset/reasoning towards the Program under test (PUT) when I test.
Identify & Adapting: To keep my mindset flexible and help me look at things from different angles, I decided to:
- Put a label on the mindset approaches that I find useful. I call each labelled mindset a” Mindset Tool”.
- Based on lessons learned from the test stories, find a name that makes it easy for me to remember each identified “Mindset Tool”
- Itemize key statements from lessons learned, this I call “Mindset tweaks”
- Use the “Mindset Tweaks” to initiate the use of each “Mindset Tool” by tweaking or adapting my mindset according to “Mindset Tweaks” whenever I test.
This was the beginning of an explosion into the world of better and effective testing as well as rapid growth as a tester!
Which is your personal favourite tool from this toolkit when you test?
It’s actually hard to say that one of the Mindset tools is my favourite because I find all of them very useful but let me answer based on the ones I use most often. And that’s the User Mindset Tool, the Communication Mindset Tool and the Analytical Mindset Tool(with focus on the Curiosity Mindset).
How do you pick which tool to use, what context drives you to pick a/any tool?
For me, I always find it useful to start with the 7W+ 1h tweaking technique in the Curiosity Mindset Tool. This triggers my reasoning about different questions that can then lead me into which tool I will find useful.
Using the 7W + 1h tweaking technique I ask:
Who ( e.g. who will use the product (Culture, race, gender)),
What(e.g. what kind of product or feature is it, what will the users use it for, what will the product or features interact with, what evidences do I need to prove the bug guilty)),
Where (e.g. Where will it be used( location, altitude), platforms, etc),
How (e.g. how will it be used, how will it be accessed, how many features, how will people react if a feature fails, etc),
When (e.g. when will it be used (time of the day, time of the year, season, etc)),
Why( e.g. Why am I testing this? Why does this feature work like this, why does it not work like that, why will anyone be interested in buying this product),
What If (e.g. what if they don’t use it the way I’ve itemized, what if the device falls down, what if it falls into water, what if this feature fails etc).
And when pressured with time I ask for example Which of these is most important to consider, which feature or area has the highest risk and make the PUT fail in real life, which of these can ruin the image of the company etc.
There are a few of the tools that I initiate all the time as soon as I start on a project, for example, start on a project I usually initiate the communication Mindset Tool. I find it useful all the time and I can’t do without it. In as much as people feel communication is a common thing, I see that a lot of testers have a lot of problems in this area everywhere I’ve presented this.
How can testers equip themselves to test irrespective of any domain and any tool choice they may or may not have?
One of the goals and advantages of the Mindset Toolkit is to help a tester come up with valuable test ideas irrespective of domain and availability of the tool. This does not in any way remove the importance of tools but it doesn’t make testing impossible when there’s a lack of tools.
I have found the Mindset Tools so useful when I don’t have a tool or when I’m assigned to a domain that I’m not so familiar with. Those days I usually get worried but these days I just get into my Mindset Toolkit and I’m set to go. The classical Mindset Tools(the Mindset Tools listed in my presentation) could be a starting point for a tester but my goal is that testers, programmers and team leads will be able to come up with their own Mindset Tools based on the technology that they work with.
Often time when I’m assigned to a domain I’m not familiar with, most useful for me has always been the User Mindset tool and the curiosity Mindset tool. Thinking about the user and how they might use the product or how they interact with the product is always a good starting point. Using the 7w + 1h tweaking technique always provokes my thoughts on what to test.
One occasion I always remember was when I was assigned to test a language pack containing 15 different languages on a device and there was very shallow requirement available and little information because this feature was added late in the Project. I didn’t know what to test but luckily I already invented the 7W + 1h technique in my Curiosity Mindset Tool Kit so I basically applied this asking: What will the languages be used for? What happens if the users change from one language to the other? Why would the users change the language? When they change from one language to the other what do they expect?what do they expect? What if there’s an upgrade from an older version to new firmware and vice versa? What kind of platforms are the languages running on? Where will the different languages be used? What’s the culture of the people? How will they use the languages: which of the 5 senses interacts with the language and what happens when the senses interact with the languages? You won’t believe how many bugs I found!
Hence with the Mindset Tools, the limitation of tools should not completely block us, there’s still a way a tester can be able to interact with the software and test.
How using 5 senses equip a tester, to test better?
For many products, the users interact with the product and features of the product using their 5 senses. So what came to mind when I developed this as a part of the User Mindset Tool was to think about how the users use their 5 senses to interact with the Program Under Test. For example, what do they do with their Touch, Ear, Sight, Smell and Mouth Functions? There’s a way the users use each of these functions to interact with the PUT and embedded in this interaction between the User and the PUT is a whole lot of Test Ideas. This approach helps a tester to test more effectively and this eventually improves a tester’s testing skills.
What were your biggest challenges as a tester and as a conference speaker?
My biggest challenge as a tester was how to grow and be valuable irrespective of the technology that I’m testing. Within my biggest challenge was the challenge of coming up with what to test to find important bugs on time. And also getting someone to listen and decide to fix the bugs that I find.
As a conference speaker, my biggest challenge was knowing whether my idea could be appealing to the testing world or should I say the software development world. When I came up with the Mindset Tool Kit, it was a bit difficult to know if it will be interesting for others. I shared with a few of my tester colleagues and some thought it made sense while others were not sure. And at this point, it wasn’t so clear but I knew I had a true story. So I decided to put my thoughts in a presentation. One of my friends, mentor and colleague Måns Norelius who happens to be a programmer assisted in helping to put my thoughts together in a structured way. And at this time I was working with House of Test and House Of Test was actually a place for inspiration and when it comes to sharing your ideas at conferences there was much support. I shared with Carsten Feilberg and he helped review and gave a lot of feedback that further helped me to conceptualize my presentation. Maria Kedemo also gave me a lot of feedback. By this time I was ready for my first conference. I submitted with a lot of uncertainty in my heart but there and then my proposal got selected from the conference to another. I became more confident as I got the opportunity to speak at different conferences.
Youtube Video: https://bit.ly/2TzqI3p
Vivien’s Bio
My name is Vivien. Some folks call me by my native name: Ronke but I also like to describe myself as a terrific tester! I coined this from my terrific love for testing and the aggressiveness with which I approach my test task. However, I take the definition of terrific that is defined as “awesome” in the description of my personality as a tester and that part of being terrifying (fear and awe) towards bugs and anything that degrades the quality of the product. I have a background in Electrical Electronics Engineering. My experience as a tester has been in the Mobile Platforms industry, Medical Technology, and Surveillance Technology. I have also studied MBA and MSc. in Electrical Engineering. The blend of MBA with the testing profession empowers me with the possibility to leverage my testing skills with some level of business mindedness. I’m quite excited and passionate about testing and for me, testing has been more than a profession, it has been a way of life!
1