Best Practices When Writing Features

In the world of software and product testing, features play a critical role—but what exactly is a feature? Think of it as a testing blueprint for the areas of a website or product that need to be examined.

Essentially, features are the core areas of a product written to inform on user flows, mechanisms, limitations, and functionality that is not as visible to those outside of an internal development or product team.

Features have two purposes. First, they serve as modules or building blocks for testers to quickly choose what functionally they want to focus on for a given test. If there is a certain user flow or functionality that’s not on the test cycle, it won’t be tested.

For example, if an eCommerce company wanted to add new functionality to their website, like moving items into a wish list, a feature would specify to perform this action for testing. Then, the customer would better understand any issues that might exist in this added functionality through the bugs that are reported back.

The second purpose of features is to serve as a scope definition for a group of crowdtesters. They inform how different areas fit into the context of the entire product.

Just because a feature exists, doesn’t mean it’s easy for testers to follow. When features aren’t written properly, it’s more likely that a reported bug was irrelevant, not a bug at all, or not a user flow that the customer wanted to test because it doesn’t give the tester enough information.  

As the primary communication path for testers to follow, the customers need to clearly articulate how the feature should work and what they want from the testing cycle. The rule of thumb here is that the more acceptance criteria, the better the testers will be able to understand what the customer wants  and the more valuable the bugs will be.

In the larger picture of the software development lifecycle (SDLC), less detailed features might also affect the volume of bugs reported. There could be issues with bugs being reported that aren’t relevant, or they miss the mark on the feature itself. These bugs could be indicative of a symptom instead of a root cause, making it difficult for the engineers to know how to fix the problem. This commonly happens if features are too granular, ultimately slowing down the SDLC.

When writing features, customers can bear these tips in mind:

1. Keep it simple. Limit language around internal domain knowledge and focus more on a high-level explanation descriptive enough for laymen. This enables the testers to act as your customer would and explore functionality without being stumped by jargon. Internal teams can drill down into more complex, fluid features.
   
2. Keep it intuitive. Consider the most logical user flow. Think of feature writing like an instruction manual for assembling something. While it might be tempting to assume that users will automatically understand how to move from one step to another, it’s critical to include every step in these instructions.
   
3. Keep it clear. Don’t overuse text in features. The best features cover purpose and scope of what a function is supposed to do, what should be test or what triggers testers will go through. Think about the nuances a user might experience (think “if, then” scenarios) and comment on any complexity testers might encounter in the user journey.

Ideally, as test cycles continue, the volume of bugs should decrease. Testers should become more familiar with the product, enabling the customer to triage bugs as they come in. If the customer realizes that there is a gap in functionality, they can notify the development team to update the feature and work on it internally, so it doesn’t get reported again.

The best testers are consistently learning and evolving with your features. Over time, the flow of features should be more refined and targeted. Testers are a tremendous asset, but you must be able to control when you want broader feedback and more targeted feedback. You can leverage features to do that.

Testers serve as go-between from the developer side and the customer side. They’re the gatekeepers between the internal development teams and the end users. Before anyone knows how the product is going to function for an end user, testers can find out—all based on criteria stipulated in the features. By developing a well-written feature, you will find more bugs that exist, which is incredibly valuable UX feedback.

You’re not going to achieve perfect features on the first go-around. The whole point of the unlimited testing model and crowdtesting is that you iterate. You run the test, get results, find bugs, and fix them. The features are meant to evolve and grow alongside your product and testing.

To learn more about crowdtesting with test IO, check out our website.