No Requirements No Test

This is about how requirements and tests are related. “Requirements” are used as a synonym here for user stories in an agile environment as well. Without having requirements you don´t know how an application should behave and you can´t test whether the application is behaving the way business decided it should.

So having no requirements means you can´t do any testing.

The Need For Requirements

Without requirements the behaviour of an application is not specified and nobody can guess, what behaviour should be tested. Without requirements there is no consensus what the application should do. Requirements are also the prerequisite for failures during testing. Are failures defects or change requests? No or unstable requirements is the most common cause of failed projects. The lack of requirements can´t be solved by testers. Requirements in the heads of stakeholders do not help, requirements must be documented and have reached a predefined level of quality, which should also include reviews by the business stakeholders and the testers.

Let´s start with an example of a simple login screen for a shop application. This may sound very simple, but the requirements specify the behaviour of this screen. Without having them, developers and testers don´t know how this screen should look like and what is the behaviour expected by the business stakeholders.

For a shop application a login screen must be presented and an user can only access the shop, when successfully logged in. Test cases should prove, whether the login screen works like it should. But can you write valid test cases without knowing how this screen should work? No you can´t. You need a list of requirements, which then can be verfied whether the login screen works as expected.

FR1
The Shop App must have a login page before showing the store.

FR1.1
The login requires an username and a password.

FR1.2
The user must provide a valid username and password in order to access the shop.

FR1.3
When the username or password are invalid, then a message “No valid login” must be presented and the shop entrance denied.

FR 1.4
When the username and/or password are empty, then a message “Username or Password must not remain empty” must be presented and the shop entrance denied

FR1.5
TouchID or FaceID should be allowed to login.

FR1.6
A new user can click to register for the shop.

NFR1
The login screen should be presented in less than 1 second.

NFR2
After login, the shop page should be functional in less than 1 second. #

NFR3
The login page should look pretty.

How Many Testcases do we need?

Every requirement must be covered by at least one test case. When necessary we can create more test cases per requirement but one test case can also cover more then one requirement. Look at FR1.2, FR1.3 and FR1.4. You need 7 variations of a test case to prove this:

Username ok, password ok, enter the shop
Username ok, password invalid, shop entry denied and message presented “Username or password invalid”
Username invalid, password ok, shop entry denied and message presented “Username or password invalid”
Username invalid, password invalid, shop entry denied and message presented “Username or password invalid”
Username ok/invalid, password empty, shop entry denied and message presented “Username or password must not remain empty”
Username empty, password ok/invalid, shop entry denied and message presented “Username or password must not remain empty”
Username empty, password empty, shop entry denied and message presented “Username or password must not remain empty”

Having No Requirements

What would happen, when developers and testers don´t have this requirements for the login screen? A simple prove: tell 4 developers they should write the code for a login screen:

Developer 1: Enter your name to access the shop
Developer 2: Enter some specific code to access the shop
Developer 3: Use only FaceID (No web, no Android)
Developer 4: The shop don´t need any login until checkout

And now what about the testers? They need to ask the developer what to test. The result: the screen is working like the developer created it and not how the business wanted. So you need a business signed-off requirements document, which specifies the behaviour.

Having Not Testable Requirements

This happens, when testers are not involved in the requirements process. Not only the business stakeholders must sign-off the requirements document (specification), but also the testers, so they are able to verify the application.

Having No Requirements for Testing

This should not happen, but when it happens, you need to collect everything possible regarding the application, so you´re able to write test cases:

Identify other sources than business stakeholders
Check for any prototypes or screen layouts
Find any similar systems
Look for RfP documents
Try to find meeting minutes or similar documents