What Is Testing Without Requirements

What do you think: is it possible to perform software testing without requirements? The answer is simple: no.

Since the requirements define the parts of software that is being developed.

But there are common objections that can be reduced to two points:

1. There is no product’s requirements document on a project but testing is still performed;
2. A team uses Agile — software functionality is more important than documentation that could describe it properly.

Anyway, you should understand the software target group, its design, components, and functionality.

Though this information is not included in the specification, it contains the main requirements for software that is being developed.

This information can be formed not only with the help of typical documents but also by analyzing the software testing lab’s skills, client’s expectations, short dialogues during calls — in other words, everything that can create a group of implicit requirements.

What are implicit requirements and when should they be used?

Implicit requirements are data regarding expected software behavior, its design and settings, that have not been included in a product’s requirements document and specifications, and also data that have not been included in established tasks.

They can be created with the help of undocumented client’s requirements, oral compromises between several members of a project group, and even the personal experience of employees.

Moreover, a register of implicit requirements should be added to the tools aimed at structuring existing software data.

It’s a list of all established system restrictions and factors that have not been mentioned in specification due to some reasons.

This tool can be useful not only when there is no product’s requirements document but it can also serve as an additional source of data when a specification is present and verified by the parties.

Such documents are created in 3 stages, that require the creation of the following components:

• A register of available sources of implicit client’s requirements;
• A register of implicit project’s data;
• A register of implicit requirements.

Let’s analyze every stage in detail.

Implicit Requirements in Software Testing

A register of possible sources of implicit client’s requirements

Taking into account the fact that the number of sources of implicit requirements can be infinite and every project has its unique list of such sources, it’s useful to be familiar with a complete list of them:

1. Regulations;
2. User manuals;
3. Advertisements;
4. Test data;
5. Mock-ups;
6. Cheat sheets;
7. Guidelines;
8. Feedback from technical support;
9. Experience and work achievements.

It’s recommended to maintain a general document of such a kind for every testing team or entire product company in general.

In such a case, every employee can not only use it but also add his/her ideas and suggestions.

A register of implicit project’s data

The first stage of developing a register of implicit requirements entails the creation of a list of its actual sources, that are based on the potential ones.

Some points are added by a project group on the basis of their experience and some — after finishing a discussion with a client and a group of potential users.

At this stage, it’s important to receive an exhaustive list of specific sources.

For example, if a group of engaged marketing specialists has conducted their analyses, you should get access to them; if the requirements are mentioned in chats, ask for personal access to such chats.

The information you have received should be organized in a form of a table.

You should take into account the following parameters, to work smoothly with this register:

1. A unique source identifier;
2. A source type;
3. A link to a current version (if any).

A register of implicit requirements

If you use only a register of implicit data, you will get at most the basic data, used to build software.

In most cases, it doesn’t contain any necessary information to reach an established goal.

A register of implicit requirements must contain the facts and restrictions that can affect software performance.

If a description is too long to be added to a table, you can simply add a link to a specific part of the requirements.

All requirements in a register should contain a unique ID and have a link to its source.

The best variant is to add all implicit requirements to the project’s technical documents.