ID

Requirement

Notes

Section 1 – Enabling login

1.1

In version 5.7.1 and later, users can log in to the example.com website.

1.2

By default, when upgrading to a version that supports logging in, logging in is disabled.

1.3

Logging in can be enabled via a configuration option in version 5.7.1 and later.

Set the enable_login option to True in the login_configuration.conf file.

1.4

Logging in can be disabled via a configuration option in version 5.7.1 and later.

1.5

When logging in is disabled, the Login button disappears from the web page.

1.6

When logging in is disabled, all user details are saved.

1.7

When logging in is re-enabled, users who had previously signed in can log in again.

Section 2 – Login screen

2.1

When a user is logged out, the Login button appears in the top right-hand corner of every page in the interface.

You will need to list all those pages.

2.2

The appearance of the Login button is shown in graphic 1.

(Not included here)

2.3

Clicking on the Login button takes users to the login screen.

2.4

The login screen contains five elements:

1. An email address textbox

2. A password textbox

3. A Submit button

4. A sign-up page link

5. A forgotten password page link

2.5

The appearance of the login screen is shown in graphic 2.

(Not included here)

2.6

Clicking on the sign-up page link on the login screen takes the user to the Signup page.

(Remember to keep your requirements obvious!)

2.7

Clicking on the forgotten password link on the login screen takes the user to the forgotten password page.

2.8

The email address textbox on the login screen validates the email.

See the standard requirements for email validity.

2.9

The password box on the login screen does not show the text the user enters.

2.10

The maximum length of the email address field on the login screen is 320 characters.

2.11

The maximum length of the password field on the login screen is 50 characters.

2.12

If the user enters an incorrect email and password combination, an error message appears letting them know.

(Wording not included here)

2.13

If a user enters a valid email address and password combination, they are taken to the home page.

2.14

When a user is logged in, the account menu is shown at the top right of every page.

Instead of the login button

2.15

The appearance of the account menu is shown in graphic 3.

(Not included here)

2.16

The account menu has a single option to log out.

2.17

Pressing the Log out button keeps the user on the same page but logs them out.

2.18

Other than displaying the account menu, logging in has no effect on the web pages.

Actually, doing something with the login is covered in version 2 and is not covered here.

2.19

If a user who has already logged out logs out again, it has no effect.

For instance, if they use a stale webpage having logged out elsewhere

2.20

Pressing the Log out button once logs out every login session for that user.

Even if they were logged in using 10 different browsers, logging 1 out logs them all out.

2.21

A single user can log in up to 20 times using different tabs and browsers.

There’s no limit in the code to how many times a user can be logged in; we will test up to 20.

Section 3 – Security

3.1

If the user enters an incorrect email and password combination, the same error message always appears.

There aren’t separate error messages if the email address is correct for privacy.

3.2

If the user enters an incorrect email and password combination, the error message appears for the same length of time regardless of whether the email address is valid.

So, attackers can’t use the length of time of response to detect valid email addresses.

3.3

Users are limited to three attempts to log in with the same password per minute (using a rolling window).

3.4

If a user attempts to log in more than three times in a minute, then an error message appears, letting them know.

(Wording not included here)

3.5

The login, sign-up, and password reset screens are protected against CSRF attacks.

3.6

Email addresses are stored securely and are only available to employees who require access.

(That needs to be specified; support needs to be able to look people up, the development team shouldn’t generally have access to live data, and so on)

3.7

Passwords are hashed and stored securely.

The algorithm should be specified.

3.8

Users are logged out after 10 minutes of inactivity.

If they visit a page after that, they would need to log in again.

Section 4 – Sign-up

4.1

On the Signup page, there are five elements:

1. An email address field

2. A password field

3. A password confirmation field

4. A Submit button

5. A link back to the login page

4.2

The maximum length of the email address field on the sign-up screen is 320 characters.

4.3

The maximum length of the password field on the login screen is 50 characters.

4.4

Passwords entered on the sign-up screen are validated for complexity.

(Complexity requirements not included here)

4.5

The email address field on the Signup page is validated.

See the standard requirements for email validity.

4.6

The password field does not show the text that the user has entered.

4.7

If the user enters an invalid email address, then they are shown a warning when they submit the form.

(Wording not included here)

4.8

If the user enters an invalid password, then they are shown a warning when they submit the form.

(Wording not included here)

4.9

If the user enters passwords that don’t match, then they are shown a warning when they submit the form.

(Wording not included here)

4.10

If the user enters a new email address that has never been used before, then an email is sent to that address to verify the account.

4.11

If the user enters an email address that has been entered previously but not verified, then another email is sent to the address to be verified.

4.12

No feedback should be given to the requester as to whether the email already exists.

To avoid leaking information about email addresses already in use on the system

4.13

If the user enters an email address that has been verified but doesn’t have a password set up, then another email is sent to the user with a new link to the password page.

4.14

If the user enters an email address with a verified email address with a password set, then they are sent another email with a link to the page to reset their password.

4.15

Verification emails are sent within 1 minute of being requested.

4.16

The appearance verification emails are shown in graphic 4.

(Not included here)

4.17

When the user clicks a link in the verification email, they are sent to the login screen.

4.18

When the user clicks a link in the verification email, the system records that that email address has been verified.

(State which database column records that state)

4.19

If a user clicks the link to the Login page on the Signup page, they are taken to the Login page.

Section 5 – Password reset

5.1

The password reset page includes three elements:

1. An email address field

2. A Submit button

3. A link to the sign-in page

5.2

The email address field on the password reset page is validated.

5.3

If the user enters an invalid email address, then they are shown a warning when they submit the form.

(Wording not included here)

5.4

Whether the email address is on our system or not, the user is shown the same message.

To avoid leaking information about which email addresses have been signed up to the system

5.5

If a user requests to reset the password of an email address that is on the system, then the application sends a password reset email.

5.6

The appearance of the password reset email is shown in graphic 5.

(Not included here)

5.7

If a user requests to reset the password of an email address that is not on the system, then the application does nothing.

5.8

The password reset email includes a secure link to let that user reset their password.

5.9

If a user clicks the link to the Login page on the password reset page, they are taken to the Signup page to enter a new password.

5.10

If a user enters an existing email address and a new password on the Signup page after following a reset password email link, then the password on their existing account is updated.

5.11

There are no requirements for new passwords to be different from previous passwords for a user.

5.12

If an email delivery fails, then no indication is given to a user, but an internal error is raised.

5.13

Password reset links are valid for 24 hours.

5.14

If a user clicks an out-of-date password link, then they are redirected to the login page.

5.15

Users can send a maximum of three password reset emails in a 10-minute rolling window.

5.16

Password reset emails are sent within 1 minute of being requested.

Section 6 – Performance

6.1

The application can support 50 sign-ups per second.

6.2

The application can support 100 logins per second.

6.3

The application can support logging in and then out within 1 second.

6.4

The application can support logging out and then back in within 1 second.

6.5

All application web pages load within 3 seconds.

6.6

The application supports 1,000,000 user accounts.

6.7

The application supports 1,000 users logged in simultaneously.

Section 7 – Interoperability

7.1

The login function works on the following web browsers:

• Chrome
• Firefox
• Edge
• Safari
• Opera

7.2

The login function works on the last three versions of each web browser.

7.3

The login function works on the following operating systems:

• Windows
• macOS
• iOS
• Android

7.4

The minimum width of all screens is 512 pixels.

7.5

The maximum width of all screens is 4,096 pixels.

(Note that this is limited; it’s just what we’ll test up to)

Section 8 – Documentation

8.1

All textboxes include tooltips.

(Wording not included here)

8.2

The written documentation describes how to sign up, log in, and reset your password.

8,3

All existing screenshots in the documentation include the account menu.

8.4

All existing instructional videos include the account menu.

Section 9 – Events

9.1

An event is raised every time a user logs in.

9.2

An event is raised every time a user signs up.

9.3

An event is raised every time a user logs out or when their login times out.

9.4

The system displays how many users have signed up.

On an internal metrics page, which also needs to be specified

9.5

The system displays how many users have signed in during the last 7 days.