The Requirements module is where your process should start.
Even though you can always add requirements later, if you want to work by the book, the application life cycle management process will start with the definition of requirements. Only then will you proceed to write and execute the tests, and report the issues detected by them. Each requirement may be linked to Tests and/or Issues in order to create traceability links (explained below in this page).

The requirements should list the items that need to be part of your product. They can also list the non-functional attributes of your AUT such as scalability, reliability, portability and so on.

We recommend that you use the Requirements Filters Mode, which is fully customizable. Just like in the other modules (issues, tests etc.), The filters mode allows you to organize your requirements using dynamic filters and cascading (hierarchical tree structure). You can organize your requirements by any criterion (field) assigned to requirements. For example, you can create a filter that will display all the requirements that belong to a certain product component, a certain version, etc.

Click here to learn more about Custom filters.

requirements_grid_with_icons

Requirement Parent Field

Another way to view your requirements is by using the Requirement Tree Mode, where each requirement can have a parent and it can also have multiple child-requirements, denoting the relationship and association between the different functional and non-functional aspects of your system.
To switch to the Requirements Tree mode, click on the “Requirements Tree Mode” link at the top of the view tree.

requirements_tree

As we explained above, requirements can be represented as a hierarchical tree, meaning that each requirement can have a parent and multiple children, denoting the relationship between the different attributes listed.

In order to manage this relationship, in addition to the regular fields and the Custom Fields that may be added to the requirements (and to any entity in PractiTest), a requirement also has a parent field.

This field will be the one to determine the specific tree structure for your requirements

Requirement Status field for full traceability

The Requirement’s status is derived from the Tests that are linked to it, and it’s essential for the full traceability.
Requirement statuses are automatically set by PractiTest according to the following cases:

  • NOT COVERED – There are no tests linked to this Requirement.
  • NO RUN – There is at least one test linked to the requirement. None of the linked tests ran.
  • STARTED – There is at least one test linked to the requirement that started running. None of them Failed or was set to Blocked
  • PASSED – All linked tests ran and passed.
  • BLOCKED – At least one of the linked test was set to blocked. None of the linked Tests was Failed.
  • FAILED – At least one linked tests failed.
  • N/A – All tests linked to this requirement marked as N/A

You may link as many Tests and Issues to each Requirement

requirement_traceability

Adding a New Requirement

To add a requirement in PractiTest, follow these simple steps:

  1. Go to the Requirements tab
  2. Click the New Requirement
  3. Fill-out the fields for your requirements
  4. link the Requirements to relevant tests / issues (optional)
  5. Click ‘Save Changes’ or ‘Save & Close’ to get immediately back to the Requirement Grid.

 

Next >>

Turn your testing data into QA intelligence now!

Buy

PractiTest – all rights reserved / The website was designed & developed by Chilid

SaaS Test Management Tool and QA Management Tools - PractiTest