Requirements management is the first stage of every successful testing process. Before assigning tasks to the particular team members, in cooperation with analysts, product owners, customers, and all the other stakeholders, test managers gather requirements determining what features the final product should provide to be considered fully functional. We distinguish 4 main types of requirements:
Functional requirements describe features that solve possible problems of the product’s future users.
Non-functional requirements are related to other functions under development that are also significant for the customers, like for example integrity with other software or design qualities.
UI Requirements define functionalities or actions that can be performed by the product’s client from the level of the user interface.
Business Requirements are business objectives mainly concentrated on the economic value of the final outcome, like the financial profits or the improvement of the overall service.
Requirements can be organized in many different ways, depending on the business individual needs, for example by their priority, the environment where they aim to function in (for example Desktop or Mobile, Chrome, Firefox, or Safari), a person assigned, software version, etc. The main goal is to keep them logically ordered, as it significantly improves the efficiency of all the next steps. It’s also important to remember the properties of the well-written requirements. In order to make them easy to work with they should be complete, clear, correct, consistent, and testable. It can seem like a lot of work before the real action even starts, but we can guarantee that it pays off. Every time.
The example of a complete requirement in Requirements and Test Management for Jira (RTM)
There still are companies that don’t believe requirements management is one of the most important stages in the software development process. This is a common mistake that can lead to costly consequences. The NIST’s report The Economic Impacts of Inadequate Infrastructure for Software Testing points out that a bug can cost even up to 880 times less when it’s found during the starting phase of testing than if it’s discovered later in the process.
The numbers mentioned in the previous paragraph only confirm the cruciality of requirements management. Nevertheless, it’s indispensable to be aware of the reasons why is it so. The first thing we have to remember is that collecting requirements may be the first phase of the process, but definitely shouldn’t be separated, as it strongly influences every following step. When requirements are well-structured, the consistent test plan practically designs itself. All that has to be done is assigning related test cases to each requirement on the list. Thanks to this, every team member can be sure that nothing’s omitted or forgotten throughout the process. Having in mind that in more complicated projects there can be even thousands of requirements, it’s easy to imagine how difficult it is to always stay in control. Acting in a logical way seems to be the only possible solution to see the project successfully finished.
Secondly, requirements management helps to determine how much time the whole testing process will take and how many team members should be involved in it. An accurate estimation of these factors at the very beginning supports budget economization, as thanks to it, test managers can assign tasks to the exact number of testers as well as plan the work accordingly with the other projects.
Last but not least, requirements are collected not only by people who do strict, IT-related work. As it was said before, they’re also gathered by analysts and the other stakeholders. In order to make the final product successful, everyone should have a possibility of participating in the discussion about which functionalities they would like to see developed and what are the priorities of each one of them. Plus, it’s much easier to communicate with the clients, which will surely ask during the process when they can expect the specific results.
Not only in software testing but also in other types of projects, it’s more difficult to keep everything under control when each part is separated. The non-consistent testing process makes it hard to observe the relations between the particular elements. This almost inevitably leads to chaos. When testing starts with writing and assigning test cases, there is a bigger possibility of making mistakes like duplicating test steps related to the same functionality, generating too many of them, etc. It shows during test plan creation or execution – so when it’s too late and all the unnecessary work is already done. Then, the team would have to deal with copied bugs. If requirements are planned at the beginning, it’s more probable to eliminate this kind of risk.
Requirements can be written separately, they’re often collected as plain documents, files, sheets, or even side notes. Unfortunately, this approach causes numerous problems further in the process. Initially gathered requirements can change throughout the work, for example after additional consultations, verification of needs, budget optimization, or other kinds of updates. Even though the person responsible for the specific requirement adds a comment or delete one position from the requirements list, testers might not pay attention to it in the middle of executing test cases. This kind of misunderstandings may have serious consequences in the end, as the final product may come out completely different than it’s expected by the customer. Including requirements management into the rest of the testing-related activities can easily prevent the problem. Even the basic versions of project management tools like Jira have functionalities which allow to alert the team members about each modification implemented during the process.
The ability to check if the requirements are safely covered by related test cases and included in test plans is highly valued by the testing teams. When it comes to the execution of many test cases, it’s very easy to forget some elements in the process. There may be new requirements or on the contrary, some that are already out-of-date. If the requirements are not included in the rest of the testing, the final check if everything is properly updated and covered takes a lot of time, or worse, is overlooked and not done at all. In consequence, the whole test plan has to be executed once again. This is clearly an additional time to the final release, not to mention the team’s demotivation resulting from the necessity of doing the exact same work from the top.
The Traceability Matrix report is a great example of how quickly we can check the coverage of two baselined testing objects, including requirements.
Reporting is something that can’t be avoided in any type of project, no matter if it’s an IT product or service, E-commerce shop, or a completely different industry. There are always customers and stakeholders who can expect to see the progress, not only at the end or just before the final release, but anytime they need. Collecting data in order to describe the steps to the stakeholders is always easier when all the elements are in one place. If the requirements are excluded from test cases, test plans, and defects it’s very difficult to put it all together when the client asks. It’s not the case with requirements included and connected to the rest of the objects. There are even solutions that generate reports automatically, which speeds up the work even more.
When requirements aren’t in the same place as the other testing objects, they still have to be managed somewhere else. Apart from Word and Excel, which aren’t recommended for the efficient cooperation inside and across the teams, there are dedicated tools for requirements. They can be synchronized with testing apps and give multiple organizing options. But like every additional extension, they cost extra and require training or just more time from the team members to learn how to work with it. The smartest idea is to get one tool that has features not only for test case management but also fully functional when it comes to requirements.
The Atlassian’s Jira is a project management tool used by the majority of entrepreneurs to organize their workflow. It’s possible to manage the testing process using only Jira Software as such but luckily on the Marketplace there are dedicated extensions that support all the testing activities from gathering requirements until reporting defects. One of them is Requirements and Test Management for Jira (RTM). It distinguishes itself from other available apps by enabling to include requirements into the rest of the testing process. The user-friendly UI and seamless Jira integration make it intuitive even for users who start using this tool for testing but had a chance to use the Atlassian suite before. All relations between the objects are visible at a glance, not only from the dedicated Relations view but also on graphs and tables, like in the Traceability Matrix or the Requirement Coverage report.
The Requirement Coverage report in RTM for Jira
If you agree that requirements management is a crucial part of the whole development process and Requirements and Test Management for Jira caught your eye, we invite you to read more about it. In case of any questions, don’t hesitate to reach us on Linkedin or set up a Demo session.
We believe that a functional test management tool should allow you to properly arrange the…
Let’s be honest. All predictions about the future from 2019 until now start from the…
You probably do not need much convincing that Jira Service Management (JSM) is an awesome…
Collaboration between testers and developers is crucial when it comes to releasing a successful product.…
The Atlassian toolset makes it possible to perform the whole software development in just one…
As far as software testing is concerned, traceability is one of the key elements for…