28 May 2020

User Registration Scenarios and Test Cases

testing

Many web applications such as e-commerce websites and web portals provide user registration and login functionality for their users.

When we are asked to test a user registration flow, we need to have a set of scenarios that we can readily use to exercise the registration feature.

The goal of this post is to provide you with a list of common scenarios and test cases that need to be considered when testing a user registration functionality.

User Registration Scenarios

The registration process is part of the identity and access management, IDAM.

Let’s consider we have a registration api which can be accessed via /register endpoint.

The /register endpoint takes a JSON payload of the form:

{
    "username": "",
    "password": "",
    "first_name": "",
    "last_name": "",
    "email": ""
}

Now, we’re going to test this /register endpoint. What scenarios can we think of?

Valid Payloads

Scenario 1: Should be able to register user with valid registration request payload

Payload:

All fields
All required fields

Check:

API response status code: 200
Database: User should exist in database

Note: Don't forget to test with Cyrillic characters, apostrophes and hyphens. These are usually allowed and valid characters but some systems handle them differently.

Invalid Payloads

Scenario 2: Should not be able to Register user with Malformed JSON payload

Payload:

Missing/Empty Headers
Missing/Empty Required Fields
Incorrect values/Incorrect format for Required Fields
Various combinations of invalid email formats

Check:

API response status code: 400
Database: No record is created in DB

Verify User Registration

Quite often, when a user is registered, a verification link is sent to the user’s email address to ensure the email is valid.

Users normally need to click the link in the email to verify their email account.

We can test with valid and invalid verification link.

Scenario 3: Verify user registration

Payload: Valid request

Check:

API response status code: 200
Database: Check user status changes from unverified to verified

Scenario 4: Verify user registration

Payload: Invalid request

Check:

API response status code: 400 or 403
Database: Check user status doesn’t change. User should still be unverified.
Login: Check user cannot login if status is unverified.

Re-registration

Scenario 5: Should not be able to register the same user twice

Payload: Valid request

Check:

API response status code: Depends
Response message: Error message saying user already exists. Note: for security reasons, some applications may not return this message.

Restricted Passwords

Restricted passwords are the ones that have already been hacked and put on pastebins. HIBP (HaveIBeenPawned.com) has a list of hacked passwords.

Scenario 6: Should not be able to register user with restricted passwords

Payload: All fields valid, but restricted password

Check:

API response status code: 400
Response message: Check error message is appropriate

Easy to Guess Passwords

There are a list of passwords that are common and easy to hack so should be avoided in user registration.

Scenario 7: Should not be able to register user with easy to guess passwords

Payload: All fields valid, but easy to guess password

Check:

API response status code: 400
Response message: Check error message is appropriate

Password Same as Username

Scenario 8: Should not be able to set password the same as username

Payload: All fields valid, but password same as username

Check:

API response status code: 400
Response message: Check error message is appropriate

Summary

Each application’s requirements are different and the above scenarios may or may not be applicable to the registration feature that you are testing.

But hopefully these scenarios can give you some guidance on what to look for when testing a user registration flow.

28 May 2020