Software development is a complex, technical and intense process, that is continuously evolving, and so are the supporting technologies and software testing tools available. Software testing may have been initially thought to be the least technical aspect of software development, but that myth has been busted now. Software testing is now much more technical in nature and the days when we could do everything manually are now long gone.
Software Testing is supported by an array of tools; some of them are functional automation tools like Selenium, others may be API tools like SoapUI, load testing tools, monitoring tools, simulation tools, CI tools and many more. With the rise of testing in DevOps, we also see the need to expand our familiarity with build tools, deployment tools, and containers, and integrate them into our environment in order to work smoothly as part of the complete software lifecycle.
With the increased demand to 'simplify’ software testing tools also comes an increased variety of testing tools to choose from. Choosing the right tool is no longer defining needs and buying a shelf tool. Many times, we find ourselves looking for a software testing tool but due to the wide selection of tools, we lose track of our initial requirements. You look for a tool to solve a little problem, but the tool’s various capabilities, make you forget the simplicity of your purpose. We may also spend a ton of time, money and effort learning and implementing a new software testing tool just because it is popular or highly recommended, and later realize that it doesn’t really fit our context, and hence is not suited for our needs.
There may be other issues too, like trying to use the wrong tools for the wrong needs. Or probably trying to make a tool work for a new project, just because the team has been working with it for the previous projects and it worked well last time. We may also be forcing ourselves to work with 2 tools instead of 10, or on the other hand trying to work with 20 tools instead of a set of 5 which may suffice.
Teams are also faced with a dilemma of selecting open source tools or licensed tools. Some will go for a fancier expensive tool, when a simple open source tool may be sufficient for their team. On the other hand, big teams may be stuck with a basic tool because it is a legacy when they could easily up their quality game by bringing in a good licensed tool with a variety of features to help their growing team.
So, before getting bogged down with the huge list of tools we should keep an open mind and ask some basic questions about the context and need. Here are 4 simple things to keep in mind before selecting your software testing tool(s):
Simplistic Approach
Always remember what your basic needs are. Ask yourself:
- Do we really need a tool for this task?
- Will the tool simplify or over-complicate the life of the tester?
- Is this tool the simplest way to solve this practical problem?
Focusing on the need and not the tool will make your decision simpler and often a complex situation can be solved with a software testing tool that provides a simple solution.
Setup a Committee for Selection of Tool(s)
Instead of relying on a single person’s advice, skill or perspective, have a group of people to review a list of tools. This can be a review committee assigned to perform a small Proof-Of-Concept (POC) on all tools of interest and suggest solutions that can then be evaluated by the entire team. This will provide a fair insight into all possibilities and then the final decision can be made based on their findings. This committee can then also spread awareness and knowledge about the tool within the organization, and keep a track of tools you have and their usage.
Information Gathering and Feedback
When bringing in a tool to replace a manual process, you must keep track of the usage of the tool, and how team handling it. Make sure you gather information from the usage of the tool, which you can use to provide feedback on the new automated process. Using this information as a feedback for improvement will confirm the purpose of bringing in the tool in the first place.
For example, let’s say you just began using an automated build tool to generate your builds by adding a build tool like maven to your CI system. Now your focus should be to keep a track of how many times a build failed to generate automatically. Every time a build fails, someone has to go and check the code repository and make the fix and re-run the build. There may be simple reasons of such failures like missing a check-in or not updating the build’s dependencies, but without tracking this information we will not be able to improve the process and hence will not be able to make the best of it. So, set up some periodic metrics of build failures and the reason identified, and focus on bringing this number to the minimum.
Evolve
Even though you may have found your perfect solution/tool, for now, you must still keep your eyes open for new ways to solve old problems. The tools ecosystem is constantly advancing and evolving, and so must you. As your team grows, projects change and get more complex, your needs may also change. You must have an open perspective and be on a constant lookout for newer and better ways to achieve your quality goals.
So - keep an open mind, choose the right way to evaluate your different options, and always stay focused on the reasons that made you start this journey!
By- Nishi Grover Garg
For more articles like this – Go to our QA Learning Center.
