Testing Requirements: How to Get Good Ones and How to Deal With Bad Ones

Every day, all we QAs do is test. APIs, user interfaces, cross-browser compatibility, business logic, etc. To know whether a product works the way it’s supposed to, we need to know the requirements.

But the sad truth is that the life of an average engineer consists of developing and testing work with badly formulated requirements – if there are any at all. This way, engineers in software quality assurance are forced to work with incomplete, old, or and – let’s be honest – bad documentation.

The worst thing about this situation is the fact that everyone talks about testing requirements, but no one really talks about how to do it.

Being one of those engineers, I decided to share my views on requirements, how to test them, how to know they’re good, and what to do if they’re bad.

Definition of Requirements

Let’s start with the basics. It’s expected that web development companies will get detailed and structured requirements for product development from the client. But if we don’t always get good product requirements, maybe it’s just not clear to everyone what they actually are. The basic definition of product requirements is a set of statements that describe a product’s or a system’s features and realization. Requirement analysis in the QA process is, in turn, a part of the software development process, and includes:

The requirement analysis in testing is very important, so it should not be neglected in the development process.

Types of Requirements for QA Testing

To be absolutely precise, there are several types of requirements in the QA Python testing process. We can sort them by level (functional, user, business) and by attribute (functional, non-functional).

I won’t go into detail on these types, since you either know all about them already or can Google them in a blink of an eye. So let’s talk about the type of requirements that no one has yet attempted to properly describe and fix – the bad requirements. Obviously, requirements listed by the client during a video call while eating lunch, through comments on Jira, Slack messages, or the hand-written notes of one of the team members are some of them.

Characteristics of Requirements

But wait – does that mean that a story on Jira or a long text on Confluence automatically make requirements solid and well-written? Well, yes, as long as they exhibit certain features. My software development team and I use the following list, since in my opinion it’s perfect not just for software quality testing, but for working on any project with any kind of client-vendor combination.

As I said, this is just a general list that can be applied to different projects. But if we take agile teams, user stories are the most popular type of requirement among agile teams. In this case, requirement quality can be easily described by using INVEST, an abbreviation that is simple and easy to remember:

Testing QA Requirements: How Do I Know They’re Sound?

A QA engineer’s main job is to ensure quality throughout the whole development process. Thus, it’s only fair to say that QA requirements development is a very important part of the job, as we’re all aware of how the cost of a bug correlates to the time spent on finding it. A good way to avoid this extra expense is to find bugs in advance by testing the requirements n software testing before the code is completed.

This seems obvious, but how exactly does one test the requirements? The answer has never been properly articulated, even though many specialists even list characteristics that should be checked.

At the beginning of my career, it was a very difficult subject, and everything I read or heard was pretty vague. Which is why, over time, I created a sort of check-list that allows me to see if a user story is a good one (i.e., suitable for development) or needs further analysis and elaboration.

Bad Requirements Bring Risks

If you answered Yes to all of the above, congratulations! You’ve got yourself some accurate requirements. But what if you’ve tested the requirements and they turn out to be far from perfect? As a QA engineer, your task is to make the software quality-assurance process flow as smoothly as possible.
The next step is to show the Product Owner (client, team, and everyone involved in requirement development) the risks of bad requirements and explain how to create good QA requirements that are easy to work with and help developers create a well-functioning product.

How to Deal with Bad Requirements

Ideally, these should help you get better requirements for product development and make the QA process more easy and transparent. But, sadly, this doesn’t always happen. What do you do then? What should QAs do when they have tons of unstructured documentation pages, different versions of tasks, heaps of comments on Jira, and questions dispersed across a bunch of emails?
Some engineers have developed their own quality-assurance methodologies. Here’s a simple algorithm I developed and use myself. Basically, you just take everything apart and put it together the way it should be.

1. Determine structure.
   Write down a list of components and functions. Use your engineering skills to define connections, the dependencies between them, and their hierarchy. Ask yourself what goal you want to achieve with every component or feature, and how.
2. Create a skeleton.
   It can be a UML diagram or a page map on Confluence including all the attachments, connections, and links. You should get a transparent structure that everyone can follow.
3. “Grow over” descriptions.
   Use your skeleton to add some muscle – entity and functionality descriptions.
4. Go deeper, in order of priority.
   Add necessary characteristics to your documentation, in order of priority. (Obviously, relevance has higher priority than traceability.)

When all the information is well structured, the holes in it are easier to see. This algorithm should allow you to see what information is present and what needs to be added to complete the puzzle.
As I’ve said, product requirements are often a pain point to everyone involved. To make a good product, all its requirements and functionality should be communicated well. Everyone should fully understand the goal they’re working towards and be on the same page about its value.
Sadly, it doesn’t always work this way. The worst thing about a lack of (or inadequate) requirements is that there’s no one way to solve the problem. Developers deal with it in different ways, and some of them don’t. This is why I decided to share my experience and help you navigate through this mess. I hope this article helps you identify the problem and find ways to either get the requirements you deserve, or at least deal with the so-so ones you have.

If you are looking for a reliable software vendor with developers who have participated in demanding projects and experienced QAs who are well-versed in all of the above nuances, contact the Django Stars team.