Choosing the right testing tools

31 Jul 2019
Choosing the right testing tools

Don’t be afraid to explore new solutions

Much like the evolution of horseless carriages in 1915 into a multitude of motor vehicle options in 2019, the testing tools available to Testers, Test Managers and Test Architects have evolved over time into a sophisticated toolbox of choices. While this is a good thing, it also presents a more complex decision-making process. The temptation to revert to what you know can inhibit that process, but asking the right questions will help you move out of your comfort zone and enable you to choose the best testing tools for the various phases of your project.

What testing techniques am I using?

Is your focus on automation testing and have you included regression testing to test existing code? Perhaps your project requires high-level security? We should be asking what level of testing detail and coverage is necessary to ensure the functionality of an application is free from defects.

Am I testing third-party product, custom software or in-house products?

If you’re testing a third-party product, it should be ready to integrate at time of download, making it unnecessary to check the quality – whereas custom software and in-house software requires detailed testing of every individual module and component. In most cases you’re utilising a combination of the two, so it’s important to understand what will require testing and what won’t - otherwise you might end up testing something that has already been tested.

What is my business sector?

If it’s retail, your testing tool will need to ensure that the point of sale system is stable and functional. If it’s banking, security will be a priority and so will the capability to handle thousands of transactions concurrently.

Do I see new technology as threatening or exciting?

The advantage of today’s testing tools is that they come complete with technological advancements such as self-remediation scripts and sample test data. While such advancements are exciting, they can also be overwhelming or even threatening. When making your testing tools selection, be aware of your own bias and strive to keep your choices based on objective criteria. Sometimes clients can see new technology as a bit threatening. They might focus on what it will cost to adopt it, without looking at the gain. There is often also considerable effort – and expense - that has been put into existing technology, so there is resistance to change. We can draw a parallel with the embracing of Agile, which has a knock-on effect because it helps companies adopt new technologies more easily. They see the benefits and start asking what they can adopt, where they can implement a more efficient process.

Is our quest for speed going to impact on our quality?

This is about how perfect your product needs to be before you go live. Testing an innovation where speed to market is more important than ensuring every single bug is detected will require a different approach to launching a new banking app. Speed doesn’t necessary impact on quality: if your business has adopted a DevOps culture you can have both.

Is research part of our pre-decision investigation?

While research plays an important role in furthering our knowledge, perhaps a sensible approach would be to limit your research time and approach it with a particular goal in mind. Your research should enable you to present your findings to your team, project manager or CIO as a faster, better or more cost-effective solution.

Am I using a tool because of a legacy relationship?

What will be the cost of moving away from the existing relationship and can you get a better solution elsewhere? Does your legacy tool run automated testing? Is it worth sitting with a legacy tool that will get older, or is it better to cut your losses now and make the change?

Testing techniques do not exist in isolation. Every part of your organisation is touched by testing. So, for example, if you are going to commit to shifting left – where testing is performed earlier in the software development lifecycle – this approach should be incorporated at every level. It requires a cultural and mindset shift.

Like choosing a new car, your testing tools will be expected to meet specific requirements. The analysis and evaluation process leading up to the final decision is critical to making the correct decisions. There are many options and some will involve going into unchartered territory. If it’s the best decision for your software testing process – and of course for the users - be bold and take the plunge.

Steve Beck

Automation Architect, Inspired Testing

Stephen Beck, Automation Architect at Inspired Testing joined the company in 2016 and has worked to provide Automation Testing solutions for multiple clients, as well as overseeing project delivery. He has also worked on creating, maintaining, and updating the tools used by Inspired Testing to ensure that clients are provided with effective Test Automation solutions.


Join the conversation on LinkedIn
Connect with our experts and read the latest industry insights on our dedicated LinkedIn page.