Would Heu-risk it? Part 23: The Shapeshifter

First of all, this is probably my favourite illustration of them all. SO pretty and I have many times felt like this lovely green ”monster”, trying to fit into a line of clones. Sorry, back to the trap! This is an anti-pattern or weakness I see in a lot of senior testers and/or testers who are very familiar with the system under test. Check the rhyme out first:

”Never stick to what comes easy to you
You will never grow or learn anything new
The same old techniques will find the same things anew
A different approach might mean treasure for you!”

So, what does it mean?

Honestly: How often do you actively think about what techniques, methods and/or approaches you will be using for doing a certain task?
And how often do you simply automatically choose the way you usually do it?

For a long time: I thought I did. Or rather: I was under the impression that I had found The Right Way™ of testing, and I applied that formula to e.v.e.r.y.t.h.i.n.g.
I also thought everyone else focused on the wrong things, that their discoveries were less important than mine.

When you are really good at testing something, you find a lot of bugs. Enough to make you think this is the most important thing ever. So you start leaning more and more into that area, those techniques and you start neglecting others. It’s human. We are very biased creatures and confirmation bias is strong.

And I see this in soooo many testers!
We get really really good at something and let other areas fall completely below an acceptable level.
We get lazy (comfortable?) and fall into patterns that are useful first but a hinder after a while.
Instead of taking a step back, thinking about what is most suitable for our context now, prioritizing and executing we stick to the formula that has worked before.

Doing the same thing will not get you new results. It’s the same thing with testing: testing the same way won’t find new bugs!

Changing things up will make you a better tester.
Learn something new, try something different, observe how someone else works. Try a session of TestSphere, my Would-heu-risk it? or another type of game.

Maybe boundary values aren’t the most important thing every time?
Maybe for this story is way more important to get good accessibility?
Maybe this feature has such high security requirements that your normal UX-focus is a waste compared to learning basic OWASP-testing?

Be a shapeshifter instead of a one-trick pony! Try different things – to grow, to improve, to do bettere.

Story time

To continue the story above: For a long time I thought I had cracked the code for how to test anything.
I always found bugs. Always. And I enjoyed it. I felt like a rock star!
I (realize now that I) had a pretty unhealthy obsession with boundary values and edge cases and my behaviour resulted in
– Devs got sloppier, since they never felt that what they did was good enough and I would find bugs anyway so it was quicker (easier) to just let me test it.
– I got resentful because I felt they should know what I would test so why did they not make sure it worked?
– Other testers also ignored those areas, maybe because they expected me to do it – maybe because I alienated them
– My bugs got prioritized because no one had the energy to fight me, so the people prioritizing got frustrated and felt side stepped
– I felt a sense of ”why is everyone else not DOING things??”, meaning I was not a pleasant person.

Not a good place to be.
Don’t be me.

Quote of the day

”When you start to test your next story, step back and think “big picture”. Consider not only the feature that it is part of, but the system as a whole”

Lisa Crispin & Janet Gregory

Reading suggestions

Testing all the way down and other – QA Hiccupps
Measuring defect potentials and defect removal efficiency – Rex Black Consulting
What to test – Nick Chamberlain
Testing the bigger picture – Lisa Crispin and Janet Gregory

Previous posts in the series