Testspecifikation - BackEndByAlex/Timelock GitHub Wiki

Test Specification (Continued)

Manual testing is used to:

  • Validate that central authentication flows work correctly in a real user scenario.
  • Identify deviations in user interface behavior and session management.

Automated tests complement manual testing by:

  • Systematically verifying access controls during authentication.
  • Ensuring that only authorized users are granted access, while unauthorized users are effectively blocked.
  • Testing critical security functions over time and during code changes.

Start Configuration: (When starting the application locally)

Frontend-app (Server):

  • In the terminal, we start the application by typing npm start or npm run dev scripts.

Auth-service (Server) and Password-service (Server):

  • We start by starting the database by typing in the terminal docker start authdb then docker start passworddb

Tip! I have used locally, docker desktop, before starting docker start ... open docker desktop application then use the commands to start the databases.

  • Furthermore, as before, type
  • npm start or npm run dev scripts.

Access the website online: https://cscloud7-142.lnu.se/TimeLock/

Test Cases

Registration Flow

TC1.1 – Registration Page Display

User Case: UC1
Goal: Verify that the registration view renders correctly.
Actor: Unregistered user
Prerequisite: User is not logged in.

Scenario:

  1. Go to the start page https://cscloud7-142.lnu.se/TimeLock/
  2. Click on "Register" in the menu or "Get Started"

Expected Result:

  • Registration form displays with input fields: First Name, Last Name, Email, Confirm Email, Password, Confirm Password
  • "Continue with Google" button is visible

TC1.8 – Registration Form Display

User Case: UC1
Goal: Ensure that the /register page renders the correct form with all fields.
Actor: Unregistered user

Scenario:

  1. User navigates to /register

Expected Result:

  • Fields are displayed for name, email, password, confirm email/password
  • "Continue with Google" button is visible

TC1.4 – Empty Registration Field Handling

User Case: UC1
Goal: Ensure that registration is not allowed without required fields being filled.
Actor: Unregistered user
Prerequisite: User is on /register.

Scenario:

  1. Click "Register" without filling in any fields.

Expected Result:

  • Error messages are displayed for each empty field.
  • No registration occurs.

TC1.2 – Google Registration

User Case: UC1
Goal: Verify that users can log in via Google.
Actor: Unregistered user
Prerequisite: Firebase configuration and backend connection correct.

Scenario:

  1. Click on "Continue with Google"
  2. Select a Google account
  3. Wait for redirect

Expected Result:

  • User is redirected to dashboard.
  • Welcome text with user's name is displayed.

TC3.1 – Secure Code Generation (automatic test)

Goal: Generate a six-digit code during registration.
Actor: New user

Scenario:

  1. User registers

Expected Result:

  • A 6-digit code is generated.

Automatic test: generateCode.test.js

TC3.2 – Verification Code Sending

User Case: UC1
Goal: Send verification code to user's email (via nodemailer or mock).
Actor: New user

Scenario:

  1. Complete registration.
  2. Code is sent to user's email.

Expected Result:

  • Verification code is delivered to user's inbox.

TC5.3 – Email Code Verification

User Case: UC1
Goal: User has started registration and received a six-digit verification code via email

Scenario:

  1. User navigates to the code verification page.
  2. User enters the code exactly as received.
  3. User clicks "Verify"

Expected Result:

  • System displays "Verification successful".
  • User can see in the sidebar that they are verified.

Login Flow

TC1.5 – Login Page Display

User Case: UC1
Goal: Ensure that the login form loads correctly when user navigates to /login.
Actor: Non-logged in user
Prerequisite: No session exists.

Scenario:

  1. Go to /login.

Expected Result:

  • Form for email and password is displayed.
  • Buttons for regular login and Google login are visible.

TC1.3 – Failed Login with Password Only

User Case: UC1
Goal: Verify that login function requires both email and password
Actor: Non-logged in user
Prerequisite: User is already on the login page

Scenario:

  1. Leave email field empty
  2. Fill in only password
  3. Click "Log in"

Expected Result:

  • Error message: "Please fill in this field"
  • User remains on login page

TC1.6 – Incorrect Password

User Case: UC1
Goal: Verify that wrong password does not grant access to the system.
Actor: Non-logged in user

Scenario:

  1. Fill in correct email but wrong password.
  2. Click "Log in".

Expected Result:

  • Error message is displayed.
  • Login fails

TC4.3 – Error exists

User Case: UC1
Goal: Do not reveal if email exists or not

Scenario:

  1. Try to log in with incorrect email

Expected Result:

  • Generic message: "Login error. Check your credentials."

TC1.7 – Incorrect Login Data Shows Error Message

User Case: UC1
Goal: Ensure that authentication fails with incorrect login credentials.
Actor: Non-logged in user

Scenario:

  1. User fills in incorrect email and password
  2. Attempts to log in.

Expected Result:

  • User receives error message.

Dashboard Flow

TC2.1 – Dashboard Renders with Form Login

User Case: UC1
Goal: Display correct content on dashboard for users who logged in via form.
Actor: Logged-in user (form)
Prerequisite: User has logged in correctly and was redirected to /dashboard

Scenario:

  1. Log in with email and password.
  2. Go to /dashboard.

Expected Result:

  • Message: "Login successful! A verification code has been sent to your email." is displayed.

Automatic test: dashboard.test.js

TC2.2 – Dashboard Renders with Google Login

User Case: UC1
Goal: Display correct content on dashboard for users who logged in via Google.
Actor: Logged-in user (Google)
Prerequisite: User has logged in correctly by clicking "continue with google" and was redirected to /dashboard

Scenario:

  1. Log in via Google.
  2. Go to /dashboard.

Expected Result:

  • Message: "You are logged in with Google! A verification code has been sent to your email." is displayed.

TC2.3 – Redirect from Dashboard without Login

User Case: UC1
Goal: Ensure unauthorized users are redirected away from protected views.
Actor: Non-logged in user

Scenario:

  1. User attempts to visit /dashboard directly without being logged in

Expected Result:

  • User is redirected to /login.

Security Features

TC4.1 – Timeout

User Case: UC1
Goal: Ensure the user is logged out after inactivity.

Scenario:

  1. Log in as a user
  2. Wait 15+ minutes without interaction
  3. Try to navigate to /dashboard

Expected Result:

  • User is redirected to /login and session is terminated.

TC4.4 – Code Attempts

User Case: UC1
Goal: Limit attempts to guess verification code

Scenario:

  1. Enter incorrect code 5 times

Expected Result:

  • User receives message "Too many attempts. Try again later."

Password Management

TC5.1 – Generate New Password

User Case: UC1
Goal: User should be able to generate a password

Scenario:

  1. User clicks on "Generate password" in dashboard

Expected Result:

  • A new, secure password is displayed in the user's view.

TC5.2 – Save Password in Vault

User Case: UC1
Goal: User has either generated or manually entered a password in dashboard and saves it in the vault.

Scenario:

  1. User clicks on "Save password" next to the password field.

Expected Result:

  • System confirms that the password was saved ("Password saved").
  • Password is now visible under "Saved Passwords" in the dashboard.