Congratulations! You’ve finally launched a web application after months of development.

As an Agile developer, you used test-driven development from the start and achieved nearly 100% test coverage. And any new commits go through a robust continuous integration and delivery process to instantly identify issues before they hit production.

What could go wrong?

To your surprise, you wake up the next morning to find a mountain of bug reports in your inbox. Angry users are complaining that the software isn’t working properly and the server logs are filled with crashes. Something has gone horribly wrong despite your diligent testing.

What happened? And how can you fix it?

Let’s take a look at what likely went wrong and how you can modify your testing approach to ensure that your software is intuitive and error free.

Many developers make assumptions when writing tests and fail to cover the ‘unhappy paths’.

Happy vs. Unhappy Paths

Many developers make the mistake of only testing happy paths, or what users are supposed to do when using an application, and neglect testing unhappy paths, or the many ways that users can break your software. By doing so, they may not be prepared to properly handle errors.

For example, suppose that you have a user registration form that automatically records the user’s location using their IP address and you use this information to show them relevant businesses in their area. This approach works great for most users but might fail if someone is using a VPN.

If you write a test covering this use case, you could plan ahead and add the user’s location to the registration form with an option to edit it to a different location. That way, the user could easily change the setting and avoid the confusion of seeing non-local businesses after completing the registration.

Happy and unhappy paths can be useful in both behavior-driven development (BDD) and test-driven development (TDD). In general, BDD tests ensure that the software behaves as a user would expect and should be accessible to stakeholder. TDD tests to ensure that the software functions on a technical level.

In other words, you may use BDD to ensure that unhappy paths create helpful error messages or workflow reminders and use TDD to ensure that the application experience errors.

How to Find Unhappy Paths

The biggest challenge with writing tests for unhappy paths is identifying them. When we write software, we create an intended workflow for the user, but there are countless ways that they can deviate from that workflow. This is especially true with large and complex software projects.

How can you anticipate these deviations?

Marketers try to understand users by writing detailed personas. The idea is to put yourself in the shoes of a user in order to better understand how they may interact with the software. These personas should be modeled after your target user base and include a fair amount of detail.

[content_upgrade cu_id="5335"]Download our free guide to creating user personas to help identify unhappy paths. [content_upgrade_button]Download Now[/content_upgrade_button][/content_upgrade]

For example, suppose that your software has a form with an upload field and your persona is an older, extremely busy, non-tech-savvy salesperson. You may quickly realize that a common scenario may be starting an upload and leaving the page before finishing it, which could create an unhappy path.

In behavior-driven development, you might write an unhappy path scenario like this:

```

Scenario: User leaves page before upload is completed

Given a user begins uploading a document

When the user closes the browser

Then the upload should be canceled

```

Without this test, it’s possible that the form submission would create a database object that’s incomplete without the uploaded document. The user could then be very confused when they log in and don’t see the uploaded document attached to the database object — at least without the proper messaging.

Build Them into Your Workflow

Behavior-driven development starts with Three Amigos meetings where test engineers, developers and stakeholders come up with examples of how software should behave. These examples are expressed in scenarios that are ultimately converted into executable specifications that can be added to a continuous integration process.

[content_upgrade cu_id="5335"]Don’t forget to download our free guide to creating user personas to help identify unhappy paths.[content_upgrade_button]Download Now[/content_upgrade_button][/content_upgrade]

Some questions to ask during these meetings include:

• What could a user do wrong?
• How might a user be confused?
• Is there anything that’s not intuitive?
• How could we help the user along the path?

The goal is to write both happy and unhappy scenarios in Gherkin that are ultimately converted into executable specifications and added to a test suite.

HipTest makes it easy to collaborate on these scenarios through an easy-to-use web interface. Rather than trying to read code or reports, stakeholders can access living documentation to see how the software behaves.

Example of a ‘Happy Path’ Cash Transfer - Source: HipTest

Test-driven development takes over with the implementation of these scenarios. During this process, it helps to imagine what could go wrong with each unit or integration test that’s written from a technical, rather than business, standpoint.

Some questions to ask at this stage include:

• Are there any limits to user inputs?
• What happens if a user clicks twice?
• What happens if the page doesn’t fully load?
• What if the internet connection drops?

These questions can help guide what validations, error messages and other features should be included when writing the actual code.

The Bottom Line

Most developers are familiar with testing the happy paths, or how users should use the software, but it’s equally important to test unhappy paths to eliminate any edge cases. By testing both paths in TDD and BDD situations, you can dramatically cut down on the number of unanticipated errors and improve the reliability and usability of your software.
If you’re interested in trying out HipTest, sign up today to start your free trial and see how easy it is to collaborate on writing effective BDD scenarios.