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?
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.
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.
For me it certainly is. I adored the Myst games for the same reason I love exploring software and finding the gaps between what the customer is likely to want and what was actually built - I had some guidelines, which I could build into a model of what was going on and expand that model as I learned more.
Iām still addicted to Myst-style games, even though replaying them isnāt nearly as much fun as puzzling the situation out the first time. I react much the same way any time I encounter something anomalous in software Iām working with, soā¦ for me at least āsolve the puzzlesā is a big part of tester-mindset.
but I agree these things have value to testers 