Three Ways To Get the Whole Team Involved in Selecting a Testing Tool

🧑‍🏫 Content Discussions
, , ,
1

Ministry of Testing launched a LinkedIn newsletter at the start of 2023. Each newsletter article has gotten a lot of attention which is awesome. Each one celebrates people in the community who have produced something published on the MoT platform. Written by me or @sarah1 – based on our own interpretations and experiences. Here’s one I wrote about tool selection inspired by @lborodajko

So I thought, why not bring them onto The Club to spark conversations, share ideas, celebrate and debate?

Selecting a testing tool is a big decision. Yet it doesn’t have to be if you share the effort across your team or squad. Yet how do you navigate all the requirements, particularly those that differ amongst individuals? Read on for three ways to get the whole team involved in selecting a testing tool.

1. Collectively spike tool options

It’s easy to get excited about a new tool when someone in the team has been trying it out for themselves or you’ve done the spike by yourself already. Yet it’s dangerous to do so. Getting caught up in their buzz – or your own – could miss an opportunity for the team to discover another tool that is better placed to solve the team’s problems. And if someone leads the way too far then others feel left out of the decision-making process and don’t feel a sense of investment when a tool is being implemented. Pair up to explore a tool together. Make notes. Be aware of any bias you or others might have. Debrief your discoveries as a team.

:tshirt: Buy a “Problem Before Tools” T-Shirt in the Ministry of Testing store .

2. Define selection criteria

How are you going to assess tool options as a team? What criteria are important? Can you decide on a weighting for each and agree on the weighting as a team? Use the same score sheet when comparing multiple tool options. The act of defining selection criteria as a team/squad helps everyone feel a part of the decision-making process. Don’t just use a method that’s been used before.

:open_book: Read helpful tool selection criteria ideas on The Club .

3. Be willing to compromise

Everyone on the team or squad will have different needs. The collectively agreed selection criteria will go a long way to support those needs yet it’s important to recognise that you might not get exactly what you want. Listen to the concerns of your fellow developers, quality engineers/testers and managers. Acknowledge where there are differences of opinions and work to compromise. Like testing, there will likely be unknowns. Agree as a team on the unknowns you are willing to accept when making your final tool choice decision.

This article is inspired by Lauren Borodajko testbash talk: Approach to Comparing Tools

Lauren joins Mahathee Dandibhotla and Diego Molina for a panel discussion on ‘The “Whens” and “Whys” of Automation’ at TestBash Autumn 2023. :maple_leaf:

The best way to join is to register for a Pro Membership. You get access to the 2-day event and over 500 talks from previous TestBashes! It’s incredible value for money if you want career growth learning content from the Ministry of Testing community.

How about you, what does your process look like for selecting a testing tool? How do you ensure the decision is inclusive?

1 Like
2

We are about to go live on Zephyr (other test case management tools do exist). I would take the time and cover the why we choose it and how, and more, but. For me… Every tool costs you, but not using a tool also costs you.

I look at tool and all test equipment cost in terms of team lunches. I have to decide, if I buy a computer or a cellphone, could I spend that money better in another place, could I treat my whole team to a nice lunch instead? Will the equipment go out of date, will the equipment just catch fire and distract people, or will it save us from a disaster because having it now means we can verify a defect much faster. Zephyr is like that. It’s expensive, I could buy fancy lunches for every QA/dev team twice a month, someone is laughing all the way to the bank with it I know, but. If I don’t have this tool, the bugs we do not catch will laugh back. We could catch some of those bugs over a team lunch just by doing the socialization that a test case tracker enforces and helps with. But it’s less likely long term, that fancy lunches will deliver, especially since some of my team is remote and sharing burgers and beer/coke over MS Teams (other meeting tools do exist) is not the same. We did not spend a lot of time trying out other test case management tools. I really hope I can write about our choice in a few months time and tell you more, but you have to weight it up, time wasted trying multiple tools, can often be waste. Do you price your tools in terms of team lunches?

1 Like
3

So we finally did, and so I’m going to share a few plusses and minuses as well as what worked for us in our first 3 weeks of Zephyr.

  • We were supposed to get the tool in October, but it’s not cheap so it meant we got the license just before Christmas break using up the last of the dept budget. I’m chuffed that I pushed so hard for this tool, because what we had before was pretty dire, but:

No matter which tool you settle on, I can recommend pushing for budget harder than you feel you should.

Plusses

  1. I can see at a glance how many tests are still not run
  2. I no longer need to switch between tools when running manual tests
  3. It’s in the cloud, so upgrades are not your responsibility anymore
  4. You now have a final resting place for properly documented tests, so it’s easier to commit the effort to capturing notes

Minuses

  1. My release manage can see at a glance how many tests I have not yet run
  2. It’s cloud based, so it’s not fast and if Jira has a hiccough, you are a bit stuck

Discoveries

  1. You have to be disciplined and not just import all of your tests at once. Run part of a release using the tool and learn how to re-arrange things so that labelling and filtering make sense. Then add more tests for the next release activity
  2. Do not go and customise like mad until you know how things will look once you have loads of tests and loads of iterations.
  3. Make small tweaks to how you put tests into folders, also don’t have loads of folders, fewer is better as it will reduce repetition when it comes time to create a new itteration/release cycle.
1 Like