What is one small change that made a huge impact on your testing style?

Ever made a small change to your testing approach that ended up making a big difference? Not talking about switching tools or rewriting your whole strategy

like changing how you write bug titles, asking why one extra time or even just slowing down before diving into the next task.

What is one small thing you did that unexpectedly improved your testing game?

Let’s swap ideas

Started making a daily to-do list before starting the day and also prioritizing them.

Just like Ujjwal, I started making a “Where did i left off” list which helps get context back when you rejoin after a weekend or vacations.

Stopped telling people what to do… just made sure we agreed what we wanted to achieve - let the rest take its course through trust and support.

Started chasing my curiosity. Sometimes, a problem exists because of something else that’s being missed entirely. Sitting with the problem vs. getting frustrated by it and figuring out why something is the way it is helps drive direction and uncovers action items to solve it, even if the action item is bringing up the topic to the team and start a conversation.

Started appreciating that I had technical knowledge even if I couldn’t code

Working more closely with devs and talking to them daily :slight_smile:

This is probably the one, actually. Made such a difference actually communicating with the people I work with. I remember just setting up a Skype chat with two devs I was working closely with and it made such a difference. That was a bit of a turning point.

Loving all the responses here, it’s amazing how even the smallest changes can make a big difference in how we test.

I stopped aiming to find bugs & started aiming to ask better questions.

Has anyone tried doing exploratory testing with someone else, but without actually testing together? Like just sharing your thoughts first, before jumping in. Did it help?

Thinking before doing. Better to say - pause, think, do.

I am usually fast and impulsive. I can do things before I think. Sometimes it’s good as I don’t procrastinate or overthink about that perfect scenario, I get feedback quickly. But often I had to rework a lot of things and were not efficient because I didn’t think and plan properly.

Another one was recognising that I prefer to have an informed conversation, meaning to load up on information and preparation (like writing down any questions I have) before going into things like refinements or just talking with devs about a ticket. I think I mostly did it anyway but when it became explicit in my head it helped shape my approach and led to better discussions and outcomes.

Considering accessiblity alongside my ‘normal’ testing was a game changer for me. Opened up so many opportunities to identify risks, improve the product and was my way of making small contributions to making the world a little better and accessible.

Windows PowerToys

It gave 10x power to me.

I’m not sure what you are looking for, but I once or twice had this:
In a remote session a developer noshared their screen to show the application and do all the interaction.
We discussed together what would be good to look at and they carried it out immediately. When there we found a big, they jumped directly in the code, fixed it and rebuild the application within seconds so that we test the fix.
By that I have ideas and guided / consultant the exploration of the product, but wasn’t hands on by myself.
It was fun to do and very effective.

Cool, It almost like live pair debugging but with a testing mindset guiding the journey. I like that it was not just about finding bugs, but actually shaping the exploration collaboratively & acting on insights instantly. That fast feedback loop must have felt really empowering for both sides.

Also, the fact that you were not directly testing, but instead steering the direction, it kind of flips the traditional tester = clicker mindset, It makes testing feel more like critical thinking in motion than a checklist task.

The discovery of ChatGPT…

Could you provide some examples @AdyStokes ? Namely:

  • How did you add those considerations while testing?
  • What kind of risks did you uncover?
  • What kind of improvements did you suggest?

Thanks

The simplest way was to do whatever testing I was going to do, but without the mouse. That way I was checking keyboard navigation which is the foundation of a lot of accessibility. By doing that I was also looking at visual indicators, logical tabbing order etc.
The associated risks are related to not knowing where you are on a page. Not following a logical tabbing or page order.
I raised anything I found mostly with who it affects, the impacts on them and how to address them.
Hope that helps.

Context driven testing. Discovery of Rapid Software Testing.