Test-driven and behavior-driven development, also known as TDD and BDD, often involve trade-offs between development time, software quality and test performance. These trade-offs are often questioned the most when testing non-functional requirements, or NFRs, since they involve a greater level of uncertainty than traditional functional requirements. Many development teams aren’t even sure if they should be testing them.

In this article, we will take a look at NFRs in greater detail and explore how to handle testing them with BDD and TDD testing strategies.

What Are Non-Functional Requirements?

Imagine that you’re building a customer relationship management software application and the stakeholder wants users to see a list of their contacts. The process of querying contacts from a relational database is an example of a functional requirement since there are a series of tangible steps that developers can take to implement it. Most developers know how to write a user story and add these kinds of requirements to their development workflow.

[content_upgrade cu_id="5354"]Download our checklist of common non-functional requirements.[content_upgrade_button]Click Here[/content_upgrade_button][/content_upgrade]

Now, suppose that the contacts are actually input from a remote call center and the stakeholder wants them updated in real-time for a salesperson that’s using the CRM to reach out to potential leads. The development team must ensure that the software is capable of updating contacts within an acceptably short period of time. Since there’s no specific functionality involved in this requirement, it’s referred to as a non-functional requirement.

Non-functional requirements, or NFRs, often describe software attributes like security, reliability, performance, maintainability, scalability and usability.

There are two types of non-functional requirements:

1. Execution Qualities - These are security, reliability, usability and other factors that are observable during software’s user-facing runtime.
   
   
2. Evolution Qualities - These are testability, maintainability, scalability and other factors that are embodied in the static structure of the software.

Some NFRs are impossible to test with code. For example, you may not be able to write a test that quantifies the maintainability of a web application. Other NFRs may introduce significant overhead if they’re included in a test suite. For example, a NFR covering performance may require a large sample database in order to test record retrieval times. Development teams must balance these trade-offs when writing tests for NFRs.

How to Handle Non-Functional Requirements

Many test-driven development teams struggle to write user stories and test non-functional requirements. On one hand, NFRs may be a critical component of software usability and deserve their own tests. For example, a real-time chat feature isn’t very useful if messages take too long to display. On the other hand, NFR stories may create issues around prioritization with more functionally-focused features in the backlog.

[content_upgrade cu_id="5354"]Download our checklist of common non-functional requirements.[content_upgrade_button]Click Here[/content_upgrade_button][/content_upgrade]Don’t forget to download our checklist of common non-functional requirements.

Let’s take a look at an example.

Suppose that you’re using a Gherkin-based behavior-driven development, or BDD, framework and have the following scenario in place:

Scenario: User can refresh a list of contacts

Given I am on the contacts page
When I refresh the list
Then I see the most current list of contacts

Now, suppose that the stakeholder wants the refresh process to take no longer than five seconds. You may rewrite this scenario to specify a maximum wait time while keeping it declarative by avoiding a specific timeframe:

Scenario: User can quickly refresh a list of contacts

Given I am on the contacts page
When I refresh the list
Then I see the most current list of contacts
And I should have to wait no longer than the max acceptable wait time

You may also specify the inverse of this scenario to handle situations where the wait time is too long, where you may want a log of the problem:

Scenario: Timeouts are logged when refreshing

Given I am on the contacts page
And I have refreshed the page
When refreshing takes more that the max acceptable time
Then the problem is logged

The decision of whether to write user stories and scenarios for NFRs depends on their importance within the overall system and the overhead requirements. Almost all NFRs can be converted into a user story or scenario, but not all NFRs can be tested with code and the performance costs of some NFRs may outweigh the benefits. It’s important to consider all of these factors with both the stakeholder goals and user experience in mind.

Integrating NFRs into Your BDD Workflow

HipTest makes it easy for business and technical teams to get on the same page when using behavior-driven development. Using a simple web-based interface, you can easily create scenarios that can be exported to step definitions with a single click. You can even create templates for common action words and steps that can be reused across different scenarios to remain consistent throughout your test suite.

Non-functional requirements can be easily added to this workflow — even when manual testing is necessary. Product managers and stakeholders can see the results of these tests in living documentation that’s accessible via a simple web interface. They can see what functionality exists within the application, as well as the development history and progress over time, knowing that it’s a reflection of what’s actually deployed.

HipTest also integrates with most popular testing frameworks, such as Cucumber, SpecFlow, Rspec, Jasmine, Behave and more. Using HipTest Publisher, you can quickly create feature files and step definitions that can be built into a continuous integration, or CI, workflow. This streamlines the BDD development process and ensures that everyone is seeing the benefits of putting user behaviors first with minimal extra effort.

Sign up today for free!

The Bottom Line

Non-functional requirements can be challenging for development teams to integrate into their workflow. By making thoughtful decisions, you can avoid creating extra work and ensure that the user experience meets all of the necessary criteria. HipTest also makes it easy to manage these NFRs and keep stakeholders informed with living documentation, which can significantly simplify and streamline the development process.