Working with ReQtest in a Scrum project

Agile methodologies have become increasingly common over the past few years, and Scrum in particular is very popular among development teams.

However, it’s no use calling yourself Agile if the tools you use in your work are anything but!

In this article, I will show you how ReQtest can be easily customized to fit better in Scrum and Agile-based projects.

Know your tools

ReQtest is a very flexible tool which makes it possible for users to customise it according to their needs, whether they follow Agile or traditional methods.

But why be forced to choose between them? If you want, you can configure different project templates in ReQtest that can be adapted to both conventional and Agile projects.

Our team at ReQtest uses Scrum to develop and maintain ReQtest, which is why I focus mainly on this particular Agile strategy.

Obviously, we use ReQtest to manage our own testing and requirements. And while ReQtest comes ready-equipped to deal with testing in an agile way, you might want to tweak the requirements management module a bit to make it better suited for agile projects.

Managing requirements in Agile

An Agile mindset will call upon your ability to keep good track of both requirements in the product backlog (requirements that should be implemented in future sprints) as well as requirements in the sprint backlog (requirements that are being handled in the current sprint).

This process can be automated with ReQtest by simply adding a new drop-down field and name it ‘Sprint’. The field values may include:

• Product Backlog
• Sprint 1
• Sprint 2
• …

The way we do it here is to first assign every requirement in the list to ‘Product Backlog’ until the team decides when each requirement will be handled. When our sprints have been planned, I update the Sprint field-value for each requirement accordingly.

To make it even quicker you can set ‘Product backlog’ as the default value in the Sprint field for every new requirement you add, and then adjust it after the planning phase.

EXTRA — Find out how you can develop a first-class requirements template

Planning in sprint

You can start adding requirements to a particular sprint concurrently with your planning process.

On ReQtest you can select multiple requirements directly from the list or narrow down your search by using the search-and-filter functionality. Once you’ve selected the requirements, use the bulk edit feature to assign all of them to a particular sprint.

Setting priorities for each requirement

When deciding which requirements to include in which sprint, it is important to have a clear idea of the relative priorities of the requirements you are handling. Important requirements should be implemented first and less important ones should be handled later or, if at all possible, discarded.

One popular method we use in Agile to assess priorities is the MoSCoW-scale (Must, Should, Could, Will Not?). By setting up a separate ‘Priority’ drop-down field and assigning each requirement a priority value, you will be able to filter out easily the important requirements from those that are not.

But how will you decide which level of priority a given requirement should be assigned?

A simple way to do so is to assess how useful the requirement is to the organization and how high the cost of implementation is. You can use both criteria to set up a four-fold decision matrix that you can use to award points to each requirement depending on its priority status.

Requirement priority decision matrix

 

In this case you might want to set up three new drop-down fields for your requirements. One will be used to indicate the relative benefit to the organisation (significant vs low), a second to indicate the cost of implementation (high vs low), and a third field to show the priority score as shown in the matrix above.

This point-system makes it very easy to filter out requirements when planning which to move from the product backlog to the next sprint. Once again, by using ReQtest’s bulk edit feature you can quickly adjust the priority of the requirements according to their scores.

Analysing information on product and sprint backlog

When all the requirements have been assigned to particular sprints, it is very easy to view? relevant statistics about the status of the product backlog and current sprint backlog.

Add a filter to the list of requirements and change the view to see the data in a table, a pie chart or as a bar chart. You can use this to compare the proportion of requirements relative to their level of priorities from one sprint to the next for example.

Note that ReQtest allows you to manipulate the order in which columns are displayed on the diagram. You can change this setting on the diagram page. In certain situations, altering the order of the columns may be important to ensure that the data is displayed in the correct order.

Adapting the requirements template for user stories

Many people who use Agile for requirements documentation will be familiar with the use of user stories for this purpose. ReQtest can be customized to write requirements in the format of a user story, which typically looks like this:

            As a <type of user>, I want to be able to do <some goal> so I can do <some reason>.           

The requirements in ReQtest can be set up so that they contain a template for user stories using the default text feature. This functionality can be used as template or guide to the requirements writer to help them write good requirements.

In the image below, you can see that I included the user formula above to appear by default in the ‘Description’ field, which for our purposes, I’ve renamed as ‘User Story’.

 

You can set the default text to appear in a template by going to menu, settings, customize forms.

Using default text is a compact and faster way of writing requirements because the writer is told which information he or she should enter in the field, without having to create more fields to fill in. The traditional option would have been to split the user story in three text fields:

• Type of user (or role)
• Goal
• Reason (or motivation)

This method is more time consuming however and breaks up a story in separate parts, making it difficult for people reading it.

Removing unnecessary fields

I believe that you should restrict the number of fields in a requirements form to the absolute minimum necessary. It’s easy to go overboard with the detail inputted, thinking that it be helpful down the line. More often than not, this only translates in taking a longer time to fill out forms and then wasting more time again to go through them all.

If you are not regularly using certain fields – like ‘Reviewer and ‘Review status’ – just remove them from the form and add this information only if it is really needed.

It is less easy to determine which fields you need for test cases and bug reports when working in Agile. I recommend that you keep track for some time of the fields that you use and then hide the fields you find you rarely need to fill in or consult. If you require these fields any time in the future, you can display them again in a couple of clicks.

Managing tests in Agile

Requirements management features are mainly used at the beginning of a sprint. During the iteration you’re more likely to use the test functions that are present in ReQtest.

BONUS — Learn how to develop a template for test cases

When we build ReQtest we use the digital Agile board that is part of ReQtest. We use it for our daily scrum meetings, whenever someone moves a sticky and during sprint demos.

The board is extremely useful when team members are spread in different locations or when parts of the team are not located in the same offices. One of the features of the board is that you can see a photo of the owner of the sticky.

We also use other tools to automate our testing in keeping with agile philosophy. Tools like Selenium and NUnit help us in this task. We also do a lot of manual testing as needed.

Bug reports can also be written in ReQtest and the diagram features are a quick and helpful way to analyse the data collected.

Using ReQtest for exploratory testing

Checklists are another important tool that help us keep track of the tasks we have to do during deployment. They are particularly useful when conducting exploratory testing and ReQtest lets you set up checklists quickly to help you structure exploratory tests better.

Creating an Agile project template

I already alluded to project templates in ReQtest and I’ll mention them again because they’re such a great tool to help you make sure that work flows smoothly and that you can easily switch from one project to the next.

A project template will have all the information that you include in the form settings and it is a handy way to base projects on a system that you understand and can easily work with.

Each time you embark on a new project you can simply map the new information onto a familiar template and be instantly clued in to what needs to be done next. This makes it easier for everyone to work in a consistent way.

As I said earlier, you can draft templates in ReQtest that are suitable for both agile and traditional projects, as well as for other purposes like maintenance. You can conveniently pull up the template you need by giving them a descriptive name like ‘_Agile template’ or ‘_Traditional template’ to instantly pull up the right one with a quick search, or else using the project selector drop down in the top right corner of ReQtest.

A few more tips

1 – When adding new fields you probably want them visible in listings. Just click the settings gear icon above the list on every page and check the columns you wish to display.

2 – To make inputting information in fields easier, write an explanation for the field so that whenever your users hover the pointer over the preview icon near a field a description will appear.

3 – Remember that you can arrange the order of columns in a list simply by dragging the column header and dropping it in its new position.