Bloggo back to the blog
Choosing the Right Tool for your Testing and Requirements Management-->
Complex products, critical features and integration requirements all need one thing – a tool that makes it possible to test and manage requirements in a structured manner. This is not just the case in agile development but also when working in a more traditional way. A hugely important prerequisite for raising the quality of the software under test is the right administrative tools for managing requirements and testing.
Evaluating and deciding which requirements and test tools best fit an organization can cost much time, money and resources. There are even companies who specialize in evaluating tools at high costs but you could also do this yourself.
You should decide which tool to choose depending on what capabilities you value most and what weaknesses you can accept, since all tools have inherent strengths and weaknesses.
The purpose of this article is to give you a number of parameters to consider before selecting a tool in a concise and informative manner.
Each and every customer has their own needs for integrating the tools into their own more or less mature test process.
Various types of tools
There are several requirements and test tools on the market. Tools can help you plan requirements and test work (how, where, when, duration, and by whom), coordinate resources, coordinate tasks, follow-up on results and store information for later use. Tools can be specialized or fairly generic, expensive or cheap, simple or complex, and so on.
Goals, purpose and benefits of a tool
It is important to use the tool in the right way so that the tool’s functionality and its structure are optimized for the best use, thus obtaining an effective and easy to understand traceability, reporting and information. Only then can the tool provide reliability, predictability and save time by making it possible to find the right information at the right time.
If updated information is readily available to team members in one place, it can ease operations and simplify tasks. Team members can quickly know what’s going on, how the work is distributed and which of the tasks depend on other tasks. This results in a greater understanding between different project teams and promotes collaboration between roles and projects.
Is it realistic to expect all this of a tool? Yes, certainly, if the ambition exists and active involvement is put on the tool. However, the ambition needs to be driven by factors such as time, money, resources and knowledge.
Common limitations when selecting a tool
• Learning curve of the tool
• International or national projects
• Technical environments (development, system testing, integration testing, acceptance testing, performance testing, training, production)
• Political aspects
• Strategic management decisions (e.g., ensuring the tool fits into the organization’s structure)
• Technical limitations (e.g., infrastructure and integration)
• Test Automation
• Test data
• Time period, a project or more years of project (short-term needs or long term)
How much does the tool cost?
Cost is always one of the greater areas of consideration, and it should well be. That said, just because a tool is free does not mean it costs nothing to use it. Bear in mind that you’re paying people per hour to use the tool, so if the tool lightens their workload and speeds processes up, it’s already saving you money you’d otherwise be spending on wages. A practical example we often come across is teams handling requirements or bug reports in Word/Excel, which is time-consuming as a process and rather clumsy. If a project has 500 bug reports, which is an altogether realistic number, and each issue takes a team member 10 minutes to deal with in Word Or Excel, this makes around 80 hours. Assuming that you pay out employees at a rate of 100 euros per hour, this totals up to €8000.
Depending on whether you rent or buy a tool or invest in a complete and comprehensive tool, the cost of the tool can be anything from relatively low to extremely high. Some factors can take lots of time, like internal support and administration of the tool. Therefore it is important to look at these factors since there might be high hidden costs buried there.
A few examples of costs that may affect the total cost of a tool:
• Upgrades and support. These often cost between 10-18 % of the initial investment. Free upgrades and support are included for some of the better tools.
• Total number of active users
• Database licenses
• External Support
• Additional hardware needed (some tools have negative effects on performance)
• Internal support
• In-house maintenance
• Test environments
• Operating Systems
• Transaction managers
Selecting the right tool
Depending on the choice of tool and the degree of engagement both within the organization and the project members, the result can be anything from a costly aborted experiment to high-efficiency improvement and aids in documenting requirements and test work.
First and foremost the tool will need to be simple and user friendly in order to obtain excessive usage within the organization, but when selecting the tool you also need to consider:
• The need for the tool in the present and future.
• The primary and secondary users for the tool.
• Previous experience in the organization of working with a tool.
• The frequency of use of the tool and its components.
• Management’s expectations for the tool.
• Psychological and social aspects of the tool implementation.
Evaluate both the supplier and the tool
Contact the tool supplier that you are interested in. Obtain your own opinion about the tool and the supplier. This will make it much easier to understand whether they will be the right fit for your unique organization, your needs and requirements.
Ask for a specific configuration of the tool, such as creating a new field in the requirements form or renaming an existing field. The response you get will be symptomatic of how open to customization the tool is, as well as what help you can expect from the vendor.
Ask questions like “Which tools can be integrated with the tool, and how is integration made? How can existing documents be linked to the requirements and test tools? ”
Test the tool in your own system / organization, with representatives from the professionals that are the target group of the tool.
Contact some of the vendor’s customers and ask for positive and negative experiences with the tool.
And finally, if you have done all of the above and are not yet fully convinced, don’t rush things. Wait and weigh your options out carefully and only choose once you feel committed with the option you most want.
Ulf Eriksson is an entrepreneur with a great interest in developing other people. Ulf heads ReQtest, an online bug tracking software based in Sweden. ReQtest is the culmination of Ulf’s decades of work in development and testing and is a very handy and simple tool to track bugs, list requirements and better manage all communication by anyone involved in any project.
Always passionate about making life easier for everyone involved in testing and requirements management, Ulf works towards this goal in his role of Product Owner at ReQtest, where he strives to make ReQtest the ultimate, must-have tool for anyone somehow involved in testing or requirements management.
Ulf is also the author of many white papers and articles, mostly on the world of software testing, which he has also taught and mentored in for a number of years. He is also slaving over a book, which will be compendium of his experiences. Ulf lives in Stockholm, Sweden.