thanks, @lisa.crispin such an important point about diverse teams. While I do my utmost to put myself in other’s shoes and think from many perspectives, I don’t have those life experiences to truly replicate others. My effort will only ever be my best effort so there’s always something that’s missed.
Testers are humble
Always asking self what I may have missed due to my current understanding of the AUT or user expectations.
I should get another new pairs of eyes to have a look. I should talk to another tester to verify.
What else I may have missed but not aware of. Am I focusing on the most important things at the moment? Is it critical to someone?
Janet Gregory’s talk on “discusses changing a tester’s mindset from “How can I break the software?” to “How can I help deliver excellent software?”, using examples and advising how to apply it on agile projects.” Definitely inspired me on my current research on the current tester mindset.
And Michael Bolton on the testing mindset podcast
Here is another good one from James Bach
Here is another example of tester mindset illustrated by an example
I have been working with my idol and mentor in the last a few weeks about the mindset discussion.
During the process, we talked about if it is changing as testers learned more and practiced more and “matured” more. We talked about how the mindset may change from “break” to “assist”. We also talked about if it is more of expanding of the mindset like onions instead of being linear change.
We tried to see if there is something or one thing unique about testers mindset. We found we don’t agree all a lot of things, and the different schools of software testing surfaced up in our discussion. It’s getting very interesting…
We keep digging until we realized we may be in a rabbit hole. Then, we paused and revisit our original intent.
We thought… (From a tester perspective)
Developer is with a build mindset when approaching ideas, features, user stories, implementations, maintenance etc.
Tester is holding the critique perspective from ideas through into the production. Possibly we believe in whatever we have at the moment can be better.
At the end, I was laughing myself with this finding as it is not very surprising. We are kind of finished at where we started but I enjoy the process of finding it.
Do you agree with this finding?
I think I partially agree as I think it’s more than just critique for testers but developers do have a primarily build mindset.
I tried some time ago for a ‘simple’ definition of the testers mindset and came up with;
What could happen given any possible, practical situation?
Possible allows us to think far and wide, from ‘ilities’ to edge cases. Practical means we focus on risk and the things deemed in scope. Definitely over simplistic with no acknowledgement of questioning our and others biases, which a lot of testers do. Nothing about removing ambiguity of meaning which testers are great at making sure we know what we are aiming for, e.g. acceptance criteria.
This is why I love using the ‘Mary had a little lamb’ exercise to demonstrate how testers think. Is Mary a girl, a woman or something else? Had is past tense so there is no longer a lamb present? I went back to school recently and when I ask, ‘what if Mary isn’t human’ the number one reaction was; ‘Oh my, a sheep gave birth!’ Or something else…
All of this pretty much explains why I love testing and and all it entails. Sorry for rambling on. Great discussion Luke!
I think you are spot on with the builder / creator mind set. Which to me is about get it to work.
But I do not think we should accept the critique perspective for testers. It’s more about learning or investigation. Understand how it works. For me critique is more focused on having an opinion. For me your focus should be more towards providing evidence for others to have an opinion. Basically investigation. You need to apply critical thinking of both the product, the development methods and your own methods. Like I have found this thing that points towards this portion of the product working as intended or not working as intended. Where can I have erred in my finding. What more do I need to find out before I can provide a “fact” or something similar?
Sounds like a cool conversation to have tho!
If not critique, how about
Tester thinks and proves more about how the solution may fail in various of “what if…” situation with/without tools to assist…
Testers have the mindset of how the systems may fail during it’s idea, design, development, implementation?
Are we close to getting somewhere with this? I felt it will be something very obvious once found because it is the mindset guides testers day in day out
I really like this statement. There will always be room for improvement so it is likely that a tester will never be fully satisfied with the quality of the application.
I was once asked in an interview, ‘what does QA mean to you?’. My reply was ‘Achieving a balance of business and user needs’.
Are we developing products for the user or the business? Should the tester care more about the user or the business needs?
I believe we should be focussing on both. A product will never be perfect, so the tester needs to learn to recognize when the product is fit for release so that the business can make money. Perfect enough so that the user gets value out of the application. Too many issues and the business loses money from dissatisfied customers. However, if too much time is spent improving the application, the business could lose money from a delayed released.
The seeing how things fail is a good angle, not because finding failures but because the value of the information it is getting.
How do you test the starting of your computer.
You can go and try to start your computer over and over and over and over again. The first time you start your computer and it starts. You really do not know much about the quality of that aspect. So how many times to you need to start your computer (without failure) for you to confidently say. This computer almost always starts!
If you instead approach is from what can I do to cause this computer not to start. All of a sudden your individual tests will provide way more information. For me at least right away I get some dimensions that I want to explore. Low battery, high / low temperature, humidity, dust, in the middle of an upgrade. low disc space. Restarting in the middle of the start process. This to me is more about investigation than it is about critique.
Some good math areas that is relevant here is both formal proof https://en.wikipedia.org/wiki/Mathematical_proof. Both by the method and the types.
And https://en.wikipedia.org/wiki/Bayesian_statistics for models on certainty of probability.
Part of the tester mindset is being aware of all these dimensions required for a product or service to be successful. It complements the narrower, detailed focus of a specialized development role.
I’d be careful in describing generically a tester mindset.
There are multiple contexts, and multiple strengths of different testers which you might want to have at a particular time.
I doubt a tester, any tester can have all possible mindset attributes.
I would prefer if we’d acknowledge the fact that you can have different testers with different mindsets that would bring something valuable inside various contexts.
Thanks for your opinions on the tester mindset, Stefan. That’s where and why this was started.
I’m on a journey to find out if all testers share something big or tiny in terms of mindset and it is critical to be tester.
or as you are suggesting that we may all have different mindset. each tester is unique and we have nothing in commmon, nothing we shares in common in terms of tester mindset.
At this stage, my thinking is like one moment “aha, i think i found it”, next minute it’s like “hmmm~~ no, not really unique to testers.” welcome on this journey and share your thoughts over time and see if we can get somewhere together or nowhere
p.s. when i say mindset, i mean a belieft we hold as a tester when we encounter with testing thinking, actitivities.
There was another thread a while back which asked about people’s favourite non-testing books that had inspired them, and I put forward that any fictional genre where the story involves a puzzle with a rational solution - detective stories, mysteries and a lot of science fiction - is a likely indicator of the sort of person who will have the best mindset to work as a tester.
I wrote a blog post on the subject:
Just thought about this more Ady
Do you mind if I say these are the things we as testers:
- Value Open minded and embrace different perspectives
- Value Inclusive in our testing
Thanks Lisa, just thought if these are:
- We value learning and exploring
- We encourage testers asking questions
- We value built better quality as a whole team effort
- We value diversity to overcome our unconscious biases
So does this mean the mindset for tester is more similar to “solve the puzzles”?
After more discussions with many awesome colleagues, here is my latest thinking of #TesterMindset
As a tester I believe there’re chances the software is built the wrong way or the wrong thing is built. There are always risks to be uncovered.