5 Checklists for Customizing Fields in ReQtest

Our team has worked hard to ensure that ReQtest provides testers with all the tools they need to excel at their work straight out of the box. If you use our product or have taken the free trial, then you’ll know that ReQtest is brimming with options and advanced customization features that let you tailor the program to your particular work system.

So, why have we crammed ReQtest full of features that come ready-set and calibrated for the easiest testing and bug reporting experience possible?

It’s simply because we didn’t want you to worry a lot about lengthy decision-making and wasting more time tinkering with the tool instead of actually using it.

Using our team’s extensive experience in the area we created a comprehensive testing solution that is ready for action the moment you log in. In many situations, all you have to do is to input the names of the subsystems you’re using and that’s it.

But that’s not to discourage all the rebels and freethinkers out there. Although most of our users find the default settings in ReQtest to be ‘just right’ for them, there’s still plenty of ways to improve your experience with ReQtest and configure it to look and feel just the way you want it to.

* * *

In this five-article series about how to customise ReQtest, we’ll present five different checklists for every area in which ReQtest can help you perform better showing you exactly all the settings you can modify to your heart’s content. 

The areas we’ll covering in this series include: requirements management, test cases, test runs, bug reporting and, finally, global settings on ReQtest.

The fields listed in these checklists were chosen to reflect those which in our experience of helping customers configure ReQtest are the most commonly modified.

Although you might be tempted to go ahead and start adding, removing and modifying fields straight away, we’d advise you to start by experimenting with a small number of fields and gradually change others only if you really need to.

After all, we’ve taken great care to ensure that ReQtest delivers the best possible experience for testers, and we’ve observed countless times that anybody can pick it up and use it professionally using the standard settings.

* * *

Part 1: Requirements Management

Commonly modified fields in the requirements form:

Title 

Brief description of the requirement which clearly shows what the requirement is about, e.g. “Ability to add customer”, “Notification via e-mail”.

Description

Full description of the requirement

User Story

Requirements when using Scrum. If Scrum is used, you might want to hide/delete the description field. For your convenience, we deliver both these fields out of the box, so you can choose one.

Time

Can be used to document the estimated time for the requirement. We do not offer the ability to sum values, so you cannot make calculations based on time directly in ReQtest, however, you can easily sum values by exporting the data to Excel.

Subsystem/Functional Area/Maintenance Object

Used to indicate the part of the system that the requirement belongs to. This field is shared between the modules in ReQtest, so you only have to update the list in one place.

Priority

Indicates importance to developers, testers and other stakeholders. Common scales are:

• High, medium, low.
• Must, Should, Could, Won’t (also known as MoSCoW).

Business value

Value for the business. Could be a four-point scale.

Cost

Development cost (or time). Could be a four-point scale.

Status

Describes what is happening with the requirement now.

For example, proposed, approved, under development, under test, implemented, postponed.

Reviewer and review status

These fields are used if the requirements are to be audited before they are put into use. Whoever is assigned a requirement for review will receive an email from ReQtest and it is also displayed on the start page. If you do not use review, hide these fields.

Sprint, release, system version

Version of the planned release of this requirement, e.g. a drop-down list of sprint numbers.

Comments

Used to post comments, for example during the review, or to document change decisions.

Source

A description of the origin for this requirement, for example, the name of a customer, a department or a person.

Motivation

Explanation of why the requirement is there. Not required if you document the requirements in the form of user stories (since the user story template already contains the motivation).

Risk probability and consequence

Used for risk-based testing so it is easier to find the requirements that are associated with the highest risk. You can use a four-point scale for instance.

Type of requirement

Requirement, change request, functional/non-functional, etc.

Remove unused fields

Fields that will not be used can either be removed or hidden. Decide if the following fields are required:

• Description or User story (choose one of them, but probably not both)
• Time
• Business value and Cost
• Review status and reviewer
• Release or Sprint

Requirements Tree

Some questions to ponder: Will the requirements tree be used? How should the requirements be structured in the tree? Should the tree be organized by subsystem, type of requirement or otherwise?

It is not mandatory to use the requirements tree.

Creating requirements via e-mail

If you want users to be able to create requirements by e-mail, you need to create an email address for this. You can do this from the settings menu.

This concludes the first post out of our five-article series about customising fields in ReQtest. Stay tuned for our next checklist, which will cover the most commonly modified fields when writing test cases.