A good tester is also a good tool selector

Discussions
, ,
1

Love this quote from Rahul Parwal (@parwalrahul):

Here’s a little challenge if you’re up for it.

Share your top three tips on how to be a good tool selector. What helps you make good choices?

Bonus points for searching for inspiration on previous The Club threads and not using a GPT tool to craft your reply. :brain:

I’ll start:

  1. Beware of the individual bias. Bias from having used the tool in another place, assuming it’ll work great here too. I’ve learnt the hard way with that one. :melting_face:
  2. Beware of the team bias. Sure let’s blindly follow what other teams are up to cos they have majority vote on this stuff. I’ve found it’s been ok to question choices and share compelling reasons why the majority selection might not be the right strategic choice. Tough to do that, yet can be pretty cool when it works out.
  3. Beware of the tool trap. Not all tools are tools, you know like the things we install or access via a browser. Tools are heuristics, oracles, models and things like that.
1 Like
2

Which reminds me, Isabel Evans (@isabel-evans) has got a couple of crakin’ things happening at TestBash 2025.

Talk: Will a new tool help? Here’s an IDEA-T to think about…
Workshop: Heuristics to help you design, build and choose test tools

1 Like
3

I’m looking forward to presenting my research about tool design and acquisition, and the idea-t framework, and to discussing it in the workshop at TestBash!

2 Likes
4

A good tester should also be able to create his own tools. My experience has been that many of the tools I want don’t exist, so I have created them. Some have been spreadsheet-based, such as one that concatenates data to create URLs that can be used with cURL to test APIs (Postman didn’t exist when I created it).

More recently, I have created complex bookmarklets that do various things to help test websites. They aren’t ready to be published, but James Bach has created some for other purposes at https://github.com/satisfice/web-testing-bookmarklets.

1 Like
5
  1. Be absolutely clear what problem you are trying to solve with tooling, before you start looking for tooling. You need to be able demonstrate it has had a positive impact, not that it was cool and fun to use.
  2. Be absolutely clear on the constraints that surround your tool selection criteria. For example, compliance to any industry or tech standards, budget, skills required of the users, integration with current tools etc. Just because you are capable of trying out a new tool and proving its capability, how many hoops will you need to go through for it to become a natural part of the way you work
  3. If your clear about 1 and 2, don’t feel you have to trial lots of tools to compare them. Your focus should be if the tool solves your problem and fits in your constraints. If it doesn’t fit one or more of those constraints, see what other options there are (including as @steve.green said, writing you’re own). If it does fit, you’re done.
2 Likes
6

Think long term.

Lot of tools start with a free, and open source strategy.

Certain players in the market have a reputation towards slowly adding paywalls to such tools with time.

Know the different between “true community first” vs “community first till community arrives”.

Maybe this reference would help seekers understand corporate strategies:

Embrace, extend, and extinguish - Wikipedia

1 Like