A wonderful question! I’ve been catching myself increasingly more thinking about my mind-thinking while testing. Though at times one does go on autopilot, stopping for a thought does give me room to consider where I may be assuming something rather than working off evidence.
For me, a few things stand out:
Switching mindsets deliberately: Sometimes I go into testing sceptically; other times, I might be more exploratory or risk-based. Just asking, “Which mindset am I in right now?” begins the process of becoming more deliberate.
Challenging my first interpretation: If something feels obvious, I put in extra effort to flip it around and look at what alternative meanings or outcomes could present themselves. (And that nursery rhyme exercise does give a lesson on how much ambiguity we turtles over!)
Asking meta-questions: Not just “what am I testing,” but property questions like “why am I testing this way?”
Additional interpretations on that nursery rhyme example:
Mary owned a lamb as property.
Mary was the lamb (as a nickname, metaphor, etc.).
Mary performed a song called Little Lamb.
Each example you provided demonstrates one example of how teachers must first take cognizance of linguistic diversity.
Its the thinking that sets quality professionals apart from other professions. For each requirement we’ll have a variety of inputs for us to interpret how we should test something. Some are quite well documented, some not and some put together collaboratively with quality engineers. But when you’re faced with a feature, the inputs only go so far.
The mindsets you use can navigate perspectives that just cannot be documented from the outset in requirements specs or stories. You don’t get documented for example what a feature won’t do, or how a user could misuse it, or if it actually solves the business problem. The mindsets you use will depend on your experience with the team, with the product and with the clients as to what are the most important ways of thinking.
For products that often get a high defect count, I may approach more sceptical of features. I’ll often go with a more risk based mindset if a product can impact other products internal or 3rd party. In general I suppose the default would be a balance of inclusive, exploratory and risk. If we’re working on prototypes then more blue sky.
I confess I haven’t really thought about the specific mindsets I’m using, just that I need to approach the testing with specific perspective and hence I’ll adopt a mindset for that situation . I think at the end of the day, we use the mindsets as a creative technique to manage risks, but those risks could come from any of the dimensions that is software development: People, product, industry, architecture, process, customers etc..
Thinking about the MHALL example, I thought I’d try and cover as many scenarios in as fewer sentences as possible.
As part of the holistic mindset I would probably count sociotechnical theories and research eg. Team Topologies and Wardley Mapping. The later is still a fave of mine for strategic understanding. Also holistic (but not exclusively the Holistic Test Model) could be using theories to understand company culture. Hofstede cultural dimensions as an example.
I’m not sure where to put a more “outreach” mindset, where you consider factors outside your delivery team and daily grind. Where the staff-level testers often play and address company strategic programs etc. It’s not inclusive, as it’s not specialisms draw into the testing, but where testing mindset is making an impact beyond software application testing.
Good thing to list these 11, they often overlap and hat’s ok. They key is to think about the testing
.