Testing Tools – When in Rome

The crowded streets of Rome were busy with locals and visitors alike. With the Trevi Fountain just a short walk from our hotel, we ventured out to take in the sights. Our walking exploits included endless dodging of scooters, speeding cars and a sea of pedestrians. The wondrous thing about Rome is the awareness that history is everywhere. The Spanish Steps, Colosseum, and other memorable landmarks, most thousands of years old, enthralled this traveler.

Another curious observation about Rome was the number of people on their cell phones. Heads down, eyes fixed on tiny screens, yet all around, wonders of the world. As I contemplated this mystery, I realized that the world of software testing and automation suffers from a similar fate. Let me clarify, while most of us would confess, we know what it means to be distracted by our phones, have we ever contemplated our obsession for testing tools?

I’ve often equated the tools of the technologist as the shiny kinds-of-things that sidetrack us from the actual craft of Quality Assurance. Not a week goes by that I don’t hear about another tool “you just have to try.” Vendors are continually selling us capabilities of tools that we “must have” to comprehend something bigger, better and newer. If you’re serious about the craft of quality, then you should be equally aware of the things that can distract you, leading to higher risk in your testing. All tools come at a cost, yes even the free, Open Source species. The moment you take your attention away from the application you’re responsible for testing, to “evaluate” a new tool, money starts to drain from someone’s bank account. Perhaps it’s a good idea to start equating time exploring new tools as a withdrawal from your quality bank account? After all, if you don’t take account and balance your books every once in a while, you’ll end up overdrawn in some capacity.

Let’s be practical; tools are required to get the work of testing done. Taking time to evaluate and select the right ones is essential to our success. So what leads to realizing the benefits of a wise tool investment vs. the decision to go with the latest gimmick?

Here are a few ideas to help lead you to successful tool additions.

  1. Do you already have a tool or process that fulfills the promised functionality of the new one you’re exploring? Google testing leaders said it this way; it’s essential to slim down toolsets to only what is necessary and remove duplication. Redundant tools need to be done away with, and the focus placed on becoming excellent with the tools already chosen. Have the discipline to ask, “Do we already have a tool that does this well?”
  2. You might be surprised just how many tools exist in the testing space which yields almost no benefits to software testers. Sales teams and marketers understand the weakness of most technologists, the allure of a shiny, new gadget is hard to resist. Open Source tools get trendy names that draw us away from success in what we’re using to follow the cool kids and their latest, technology fidget spinners. When assembling our test automation team, we standardized on a primary IDE (Integrated Development Environment), taking advantage of its many capabilities. This approach provided several advantages such as sharing newly leveraged capabilities across our team and faster onboarding of new team members. This discipline helps us focus on being skilled Test Engineers developing the right automation efficiently.
  3. Agree as a testing team, how to decide and train for the tools adopted. Be committed to a single-tool-philosophy when possible. Engage team members that may be diluting the selected toolset for the sake of chasing the next shiny thing.
  4. Have a real, financial budget for tools. There is a blind quest technologist get caught up in, the quest for “free” as I call it. I’ve known test engineers who pursue, adopt and replace free tools at a blinding pace. All this energy spent looking for free tools without considering the cost of the quest and reality of great tools that could cost just a few dollars. Screen capture tools are an excellent example, consider the amazing functionality of Snagit by TechSmith which sells for about $50. I use this tool every day because it gives me the features and efficiencies I expect from a great tool. Snap out of the “Everything must be free” trance and instead, pursue excellence tools for your craft as Quality Engineers.
  5. Assign a subject matter expert (SME) and get training for the tools your team adopts. Use a federated approach for the SME to learn the tool and then train the rest of the team on its usage. Building this into your team culture provides opportunities for ownership and growth across your testing organization. Regardless of the tool being paid or free, find the right training to get the most out of it as an investment in your testing organization.

In my book, Test Automation in the Real World, I have an entire chapter dedicated to tools. I often say, “Use a tool as designed, not as discovered.” When you use a tool as designed, you get more out of it quicker than merely trial and error.

As we conclude, remember the craft we pursue is quality. Be tactful and know when you’re getting robbed of your quality bank account at the cost of a shiny new toy with no real benefits. Surround yourself with a community of quality craftsman, known for putting out products that perform well and meet real testing needs. Be alert for quality robbers, masquerading as a testing tool yet bringing no real value.