(A) Unit Testing Plan
Module Selected: Login Module (Node A)
1. Test Objectives
The Login Module must correctly authenticate three types of users (Student, Faculty, Administrator)
and reject all invalid access attempts. Specific objectives are:
Verify that valid credentials grant access to the correct role-based dashboard.
Verify that invalid credentials (wrong password / unregistered email) are rejected.
Verify that blank username or blank password fields trigger a validation error.
Verify that a locked/inactive account cannot log in.
Verify that SQL injection and script injection attempts are sanitised and rejected.
Verify that after N failed attempts the account is temporarily locked.
Verify that "Forgot Password" sends a reset link to the registered email.
2. INPUT CONDITIONS
Conditi
on
Description Type
IDditio
n
IC-01 Valid username + valid Valid
password (registered, active
account)
IC-02 Valid username + wrong Invalid
password
IC-03 Unregistered username + any Invalid
password
IC-04 Empty username field Invalid
(password filled)
IC-05 Empty password field Invalid
(username filled)
IC-06 Both fields empty Invalid
IC-07 Valid credentials for a Invalid
locked/inactive account
IC-08 SQL injection string in Attack
username: ' OR '1'='1
IC-09 XSS payload in Attack
password: <script>alert(1)</s
cript>
IC-10 3 consecutive failed login Bounda
attempts with valid username ry
IC-11 Password containing Bounda
maximum allowed length ry
(e.g. 128 chars)
IC-12 Password with special Bounda
characters: !@#$%^&* ry
3. EXPECTED OUTPUT
InInput Expected
Expected B
Condition Output
IC-01 Login Redirect to Student
(Student) successful Dashboard; session
token created.
IC-01 Login Redirect to Admin
(Admin) successful Panel with all-
module access.
IC-02 Error "Invalid username or
message password" — no hint
about which field is
wrong.
IC-03 Error "Invalid username or
message password" (generic,
no account
enumeration).
IC-04 / IC- Validation Red inline error:
05 / IC-06 error "This field is
required." Submit
button disabled until
corrected.
IC-07 Account "Your account is
locked suspended. Contact
message the administrator."
No login granted.
IC-08 / IC- Rejected, Input
09 sanitised stripped/escaped;
login fails with
generic error; attempt
logged.
IC-10 Account "Too many failed
temporarily attempts. Try again
locked in 15 minutes."
Further attempts
blocked.
IC-11 / IC- Login System accepts valid
12 successful or long/special-char
appropriate passwords without
error truncation.
4. TEST CASES
[Link] Student Login
Preconditions: Student account s001@[Link] is active in the database.
Input: Username: s001@[Link] Password: Student@123
Steps: 1. Open login page. 2. Enter credentials. 3. Click "Login".
Expected Output: Redirect to Student Dashboard. Session token stored. Welcome message displays
student's name.
Pass/Fail Criteria: PASS if dashboard appears within 3s, FAIL if error or wrong role.
[Link] Password
Input: Username: s001@[Link] Password: WrongPass!
Expected Output: Error message: "Invalid username or password." User stays on login page. Failed
attempt counter incremented.
Pass/Fail Criteria: PASS if access denied and error shown, FAIL if login succeeds.
[Link] Fields Validation
Input: Username: (blank) Password: (blank)
Expected Output: Client-side validation fires before API call. Both fields highlighted red with "This
field is required."
Pass/Fail Criteria: PASS if no server request is made, FAIL if server is hit or login proceeds.
5. Possible Defects
System accepts SQL injection in the username field, allowing authentication bypass.
Empty field validation is only performed server-side; malicious requests can skip client
validation.
Error message reveals which field is incorrect (e.g., "Password is wrong"), enabling account
enumeration.
Account lockout counter resets on page refresh, allowing unlimited brute-force attempts.
Session token is not invalidated after logout, enabling session hijacking via token reuse.
Long passwords (>128 chars) are silently truncated, allowing login with any prefix of the real
password.
Locked account message reveals the exact lockout duration, aiding timing attacks.
Role-based redirect fails — admin credentials redirect to student dashboard or vice versa.
Password field is not masked (plaintext visible) on certain mobile browsers.
"Forgot Password" link sends the reset token to an unverified email; no old-password invalidation
occurs.
(B) Integration Testing Strategy
Top-Down Integration Testing
Top-Down integration is the most suitable strategy for the OEMS because:
1. Login is the mandatory entry point — No other module is accessible without successful
authentication. Testing from the top ensures that the foundational access control is verified before
any dependent module is exercised.
2. The module interaction is strictly hierarchical — The interaction graph
(A→B→C→D→E→F→G) is a directed linear chain with one branch (A→D). This natural top-to-
bottom flow maps perfectly to top-down integration: once Login and Registration are integrated and
stable, Admit Card is connected, then Online Test, and so on.
3. User journey validation is prioritised — OEMS is a user-facing system. Testing the complete
student journey (login → register → download admit card → sit exam → see result) incrementally
from the top gives the QA team early confidence that the critical user path is functional.
4. Stubs are simple to write — Because lower modules (Evaluation, Result, Notification) are largely
independent data processors, their stubs can return pre-defined responses without complex logic,
reducing the overhead of top-down testing.
5. Early defect detection in control flow — Most integration defects in examination systems relate to
role-based routing and data hand-off between Login → Registration → Admit Card. Top-down
exposes these defects early, when they are cheapest to fix.
(C) Adjacency Matrix
The adjacency matrix M represents the direct relationships (edges) between the modules (nodes). A
value of 1 at Mij indicates a direct interaction from module i to module j.
Nodes Reference:
A: Login
B: Registration
C: Admit Card
D: Online Test
E: Evaluation
F: Result
G: Notification
Matrix Construction:
A B C D E F G
A 0 1 0 1 0 0 0
B 0 0 1 0 0 0 0
C 0 0 0 1 0 0 0
D 0 0 0 0 1 0 0
E 0 0 0 0 0 1 0
F 0 0 0 0 0 0 1
G 0 0 0 0 0 0 0
Explanation of the matrix:
From
Too Meaning
m
A B Login grants access to Exam Registration
A D Login grants direct access to Online Test
B C Registered student can generate Admit
Card
C D Valid Admit Card is required to enter
Online Test
D E Submitted test answers are sent for
Evaluation
E F Evaluated scripts generate Result
F G Published result triggers Notification