Scribd
Upload
12 views28 pages

Create A Webpage Using Ordered List and Unordered List

Uploaded by

hodbca
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
12 views28 pages

Create A Webpage Using Ordered List and Unordered List

Uploaded by

hodbca
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 28

Create a webpage using ordered list and unordered list

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<metaname="viewport"content="width=device-width,initial-scale=1.0">
<title>List Example</title>
<style>
body {
font-family: Arial, sans-serif;
margin: 0;
padding:0;
}

.container{
max-width: 600px;
margin: 20px auto;
padding: 0 20px;
}

h1{
text-align:center;
}

.ordered-list
{ color: blue;
}

.unordered-list
{ color: green;
}
</style>
</head>
<body>
<div class="container">
<h1>List Example</h1>
<h2>Ordered List</h2>
<ol class="ordered-list">
<li>First item</li>
<li>Second item</li>
<li>Third item</li>
</ol>
<h2>Unordered List</h2>
<ul class="unordered-list">
<li>Apple</li>
<li>Orange</li>
<li>Banana</li>
</ul>
</div>
</body>
</html>
Project: Student Management System

1. Software Requirements Specification (SRS)

1.1 Introduction

 Purpose: This document provides the system requirements for the development of a
Student Management System, which allows users (teachers and administrators) to
manage student information, including enrollment, grading, and attendance.
 Scope: The system will allow adding, viewing, updating, and deleting student records,
tracking attendance, and generating grade reports.
 Audience: The target audience includes the system developers, system administrators,
and end users (teachers, students).

1.2 Functional Requirements

 Student Management:
o Add, update, delete, and view student information (name, age, roll number, etc.)
 Attendance Management:
o Mark attendance for students (daily/weekly).
o View attendance records.
 Grading System:
o Add grades for students for various subjects.
o Generate a report card for each student.
 User Roles:
o Admin: Can manage all aspects (students, attendance, grades).
o Teacher: Can manage student grades and attendance.
o Student: Can view grades and attendance (no modification).

1.3 Non-Functional Requirements

 Performance: The system should load within 3 seconds.


 Security: User data should be encrypted.
 Usability: The system should have an intuitive and simple interface.
 Portability: The system should work on all major browsers (Chrome, Firefox, Edge).

1.4 Assumptions

 The system will be a web-based application.


 The database will be MySQL for storing records.
 Authentication will be handled via a username and password.

1.5 Constraints
 The application should work on both desktop and mobile browsers.
 The system should support multi-user access with role-based permissions.

2. Design

2.1 Architecture Design

The system follows a 3-layer architecture:

1. Presentation Layer: The User Interface (UI), built using HTML, CSS, and JavaScript.
2. Business Logic Layer: Handles logic for managing students, attendance, and grades
(built in PHP or Python).
3. Data Layer: A MySQL database to store all records.

2.2 Database Design

Tables:

1. Students
o student_id (Primary Key)
o name
o roll_no
o dob
o address
2. Attendance
o attendance_id (Primary Key)
o student_id (Foreign Key)
o date
o status (Present/Absent)
3. Grades
o grade_id (Primary Key)
o student_id (Foreign Key)
o subject
o grade
4. Users (Authentication)
o user_id (Primary Key)
o username
o password
o role (Admin/Teacher/Student)

2.3 UI Design

 Home Page: Options for Admin, Teacher, and Student logins.


 Admin Dashboard: Manage students, attendance, and grades.
 Teacher Dashboard: Mark attendance and assign grades.
 Student Dashboard: View grades and attendance.
3. Coding

3.1 Technologies

 Frontend: HTML, CSS, JavaScript


 Backend: Python (Flask/Django) or PHP
 Database: MySQL
 Authentication: Simple login system using hashed passwords

3.2 Code Structure

plaintext
Copy
/StudentManagementSystem
/static
/css
/js
/templates
index.html
dashboard.html
login.html
/app
/models
student.py
attendance.py
grade.py
/controllers
student_controller.py
attendance_controller.py
grade_controller.py
/views
dashboard_view.py
login_view.py
/app.py
/config
database.py

3.3 Sample Code Snippet (Python/Flask)

python
Copy
# app.py (Flask Application)
from flask import Flask, render_template, request, redirect, url_for
from models import Student, Attendance, Grade

app = Flask(__name__)

@app.route('/')
def index():
return render_template('index.html')
@app.route('/login', methods=['POST'])
def login():
username = request.form['username']
password = request.form['password']
# Validate user
return redirect(url_for('dashboard'))

@app.route('/dashboard')
def dashboard():
return render_template('dashboard.html')

if __name__ == '__main__':
app.run(debug=True)

4. Test Plan

4.1 Types of Testing

 Unit Testing: Each function (e.g., adding student, marking attendance) will be tested
individually.
 Integration Testing: Test how components interact with each other, e.g., adding a
student and checking if they appear in the attendance system.
 System Testing: Complete end-to-end testing of the application’s functionality.
 User Acceptance Testing (UAT): Test the system with real users (teachers and admins)
to ensure it meets their requirements.

4.2 Test Cases

1. Test Case 1: Add a new student


o Input: Name: "John Doe", Roll No: "1234", Age: 21
o Expected Output: The student is added to the database, and the student appears
in the student list.
2. Test Case 2: Mark attendance for a student
o Input: Student ID: 1, Date: "2025-04-09", Status: "Present"
o Expected Output: The attendance for the student is recorded in the database.
3. Test Case 3: Add grade for a student
o Input: Student ID: 1, Subject: "Math", Grade: "A"
o Expected Output: Grade is added, and the student’s grade is updated in the
database.
4. Test Case 4: View student’s grade and attendance
o Input: Student ID: 1
o Expected Output: Display student’s grades and attendance records correctly.

4.3 Tools for Testing

 Unit Testing Framework: PyTest (for Python) or PHPUnit (for PHP).


 Browser Testing: Selenium for automated UI testing.
 Database Testing: MySQL queries to verify records.

Conclusion:

This project is a simple yet effective way to manage student records. By following the design,
coding, and testing plans outlined here, the system should be robust, secure, and easy to use.

WinRunner was an automated functional testing tool developed by Mercury Interactive


(which was later acquired by HP, and WinRunner was eventually discontinued in favor of QTP
(QuickTest Professional), now known as UFT). WinRunner was used to perform automated
regression and functional testing for software applications, primarily for GUI-based applications.

Here’s a study of WinRunner, covering key aspects of its functionalities, features, and use
cases:

1. Overview of WinRunner

WinRunner was a tool designed for automating the testing of GUI (Graphical User Interface)-
based applications. It supported various types of testing, such as functional, regression, and load
testing, and was commonly used to verify that software behaved as expected. The tool was
designed to simulate user actions, such as clicks, keystrokes, and other interactions with the
application interface, to automate the execution of test scripts.

2. Key Features of WinRunner

 Record and Playback: WinRunner had the ability to record user interactions with the
application and generate test scripts that could be played back to simulate those
interactions. This provided a quick way to create automated tests without writing scripts
manually.
 Test Script Generation: WinRunner created test scripts in a scripting language called
TSL (Test Script Language), which was similar to C. This language provided flexibility
and allowed for detailed control over the test execution.
 Object Recognition: WinRunner automatically recognized objects on the screen, such as
buttons, text fields, and other GUI elements. These objects were mapped to the
corresponding test scripts.
 Synchronization: WinRunner ensured that tests were synchronized with the
application’s behavior, meaning the testing process waited for the appropriate events
(such as loading a page) before executing further steps.
 Data-Driven Testing: WinRunner supported data-driven testing, where different sets of
input data could be used to test the application, allowing for more comprehensive test
coverage.
 Integration with Test Management Tools: WinRunner could be integrated with
Quality Center (QC) or TestDirector, allowing teams to manage their test cases, report
defects, and track progress in one centralized system.
 Built-in Checkpoints: Checkpoints were a key feature in WinRunner, which allowed the
tester to verify that certain conditions were met during the test. For example, verifying
that an image appeared on the screen or that text was present in a field.

3. Architecture of WinRunner

WinRunner consisted of several components that worked together to perform automated testing:

 Test Script Editor: The TSL editor where users could create, modify, and run their test
scripts.
 GUI Map Editor: This component was responsible for identifying the objects within the
GUI of the application and mapping them to the corresponding test script elements.
 Test Runner: The tool that executed the test scripts created by the user. It simulated user
actions like mouse clicks, keystrokes, and interactions with the application.
 Verification and Checkpoints: These were used to verify whether the application under
test was behaving as expected. The checkpoints could be used to validate that an object
exists or that specific text appeared on the screen.
 Data Table: Used to store input and expected output data for data-driven testing. The
data table provided a means to easily swap input values and execute the same test with
different datasets.

4. Test Script Language (TSL)

Test Script Language (TSL) was a scripting language used by WinRunner to define automated
test scripts. TSL had similarities to C and allowed testers to create robust test scripts with control
structures (such as loops, if-else statements), functions, and variables. Here’s an example of a
basic TSL script:

tsl
Copy
// Example of a simple WinRunner script in TSL
load("winrunner_gui_map"); // Load GUI map
window_activate("MyApp"); // Activate the application window
edit_set("username_field", "test_user"); // Set value in username field
edit_set("password_field", "test_password"); // Set value in password field
button_click("login_button"); // Click the login button
verify("login_message", "Welcome!"); // Verify the login message

5. Key Benefits of WinRunner

 Efficiency: WinRunner allowed for the automation of repetitive test cases, which saved
time and reduced manual effort.
 Regression Testing: WinRunner was particularly useful for regression testing, ensuring
that new code changes did not break existing functionality.
 Ease of Use: The record and playback functionality made it relatively easy for testers,
even those without much programming experience, to create and execute automated tests.
 Customizable: The TSL scripting language gave testers a lot of control and flexibility,
allowing them to tailor their test scripts according to the specific needs of the application.
 Cross-Platform Testing: WinRunner supported a variety of applications, including those
built with technologies such as Java, SAP, and .NET.

6. Limitations of WinRunner

 Limited Support for Web Applications: While WinRunner supported a variety of GUI-
based applications, it had limited support for web applications. This made it less suitable
for testing web-based applications compared to more modern tools like Selenium.
 Discontinued: As mentioned, WinRunner was eventually phased out in favor of UFT
(Unified Functional Testing), which provides more comprehensive support for modern
web, mobile, and desktop applications.
 Requires Expertise in TSL: While the record-and-playback feature was useful, creating
more complex test cases required knowledge of the TSL language, which had a learning
curve.
 High Cost: Like many enterprise-level testing tools, WinRunner came with a high price
tag, making it difficult for small teams or companies to afford.

7. End of Life and Transition to UFT

 Discontinued: HP officially discontinued WinRunner in 2009, moving forward with


QTP (QuickTest Professional), which later became UFT (Unified Functional Testing).
UFT combined the functionalities of WinRunner with support for web applications, APIs,
and other modern technologies.
 UFT: Unlike WinRunner, UFT was designed to handle more advanced testing needs,
including the ability to test web applications, mobile applications, and services like APIs.
It also integrated with other HP testing tools and provided better support for modern
software development methodologies.

8. WinRunner vs. Other Tools

Feature WinRunner Selenium QTP/UFT


Functional and Regression Primarily Functional Functional, Regression,
Test Type
Testing Testing API Testing
Scripting JavaScript, Java, Python,
TSL (similar to C) VBScript, JavaScript
Language etc.
Support for Excellent (especially for Good (Web, Mobile,
Limited
Web web) API, Desktop)
Integration Integration with Integration with Jenkins, Integration with HP
Feature WinRunner Selenium QTP/UFT
etc. ALM, Jenkins
QC/TestDirector
Open Source No Yes No
Cross-platform (Linux,
Cross-Platform Windows Only Windows
Mac, Windows)

9. Conclusion

While WinRunner was a powerful tool for its time, it is now considered outdated due to its
limited support for modern web and mobile applications. The tool has been replaced by newer,
more flexible automation tools like UFT, Selenium, and Appium, which offer better support for
modern software testing needs. However, the principles of automated testing established by
WinRunner, such as record-and-playback, test script generation, and the use of checkpoints, have
influenced many of the tools that followed.

If you're studying WinRunner for historical context or transitioning from legacy tools,
understanding its key concepts will help you appreciate the evolution of automated testing tools
and their role in the software development lifecycle.

Manual Testing Plan for Student Management System

1. Test Objectives

The primary objective of manual testing for the Student Management System is to:

 Verify the accuracy and completeness of all features.


 Ensure the application works as expected under normal and edge conditions.
 Identify any bugs or issues that could impact the user experience.

2. Test Cases

Below are some of the key test cases for Student Management System.

Test Case 1: User Login


 Test Description: Ensure that users can log in based on their roles (Admin, Teacher,
Student).
 Test Steps:
1. Open the application’s login page.
2. Enter a valid Admin username and password.
3. Click the "Login" button.
4. Verify that the Admin dashboard loads successfully.
5. Repeat steps for Teacher and Student logins.
 Expected Result:

o Admin, Teacher, and Student should be able to log in successfully with their
credentials.
o Users should be redirected to their respective dashboards.

Test Case 2: Add New Student (Admin Role)

 Test Description: Verify that an Admin can add a new student to the system.
 Test Steps:
1. Log in as Admin.
2. Navigate to the "Manage Students" section.
3. Click on "Add New Student."
4. Enter valid details (name, roll number, date of birth, address).
5. Click the "Save" button.
 Expected Result: The new student should be successfully added to the database, and
their details should appear in the student list.

Test Case 3: Update Student Information (Admin Role)

 Test Description: Verify that an Admin can update student details.


 Test Steps:
1. Log in as Admin.
2. Navigate to the "Manage Students" section.
3. Select an existing student from the list.
4. Click on "Edit" and modify any of the student's information (e.g., name, address).
5. Save the changes.
 Expected Result: The updated student details should be saved, and the changes should
be visible in the student record.

Test Case 4: Delete Student (Admin Role)

 Test Description: Verify that an Admin can delete a student from the system.
 Test Steps:
1. Log in as Admin.
2. Navigate to the "Manage Students" section.
3. Select a student from the list.
4. Click on "Delete."
5. Confirm the deletion.
 Expected Result: The student should be removed from the database, and the student list
should be updated.

Test Case 5: Mark Attendance (Teacher Role)

 Test Description: Verify that a Teacher can mark attendance for students.
 Test Steps:
1. Log in as Teacher.
2. Navigate to the "Attendance" section.
3. Select a date and the students to mark as present or absent.
4. Click on "Save."
 Expected Result: The attendance should be saved for the selected students, and the status
should reflect in the attendance record.

Test Case 6: Generate Student Report Card (Teacher Role)

 Test Description: Verify that a Teacher can generate a report card with grades for a
student.
 Test Steps:
1. Log in as Teacher.
2. Navigate to the "Grades" section.
3. Select a student.
4. Assign grades for various subjects.
5. Click on "Generate Report."
 Expected Result: A report card should be generated with the student's grades and other
relevant information.

Test Case 7: View Grades and Attendance (Student Role)

 Test Description: Verify that a student can view their grades and attendance.
 Test Steps:
1. Log in as Student.
2. Navigate to the "My Grades" and "My Attendance" sections.
3. Check if the grades and attendance records are displayed correctly.
 Expected Result: The student should be able to view their grades and attendance without
modification.

Test Case 8: Invalid Login Attempt

 Test Description: Ensure that the system prevents login with invalid credentials.
 Test Steps:
1. Open the login page.
2. Enter invalid credentials (wrong username/password).
3. Click the "Login" button.
 Expected Result: The system should display an error message like "Invalid username or
password," and the user should not be logged in.

Test Case 9: User Role Access Control

 Test Description: Verify that users cannot access features that are not permitted to their
role.
 Test Steps:
1. Log in as Student.
2. Try to access the "Manage Students" section.
3. Log in as Teacher and try to access "Admin Dashboard."
 Expected Result: Students should not have access to the "Manage Students" section.
Teachers should not have access to the "Admin Dashboard."

Test Case 10: Data Integrity Check (Database)

 Test Description: Ensure that data is correctly reflected in the database after performing
any operation.
 Test Steps:
1. Add a new student using the application’s interface.
2. Verify that the student's details are correctly inserted into the database (using SQL
queries).
 Expected Result: The data in the database should match the information entered in the
application.

3. Testing Environment

 Browser: Test the application on multiple browsers (e.g., Chrome, Firefox, Edge) to
ensure compatibility.
 Operating System: Test on Windows, macOS, and Linux (if applicable).
 Database: MySQL or any relational database management system to store data.
 Application: Web application running on a server or locally hosted.

4. Test Execution Process

1. Test Preparation: Ensure all resources, including test cases, test environment, and test
data, are ready.
2. Test Execution: Execute each test case manually following the steps listed. Document
any issues or bugs encountered.
3. Bug Reporting: For any defects found, report them in a bug tracking system (e.g., JIRA)
with detailed steps to reproduce, severity, and expected vs. actual results.
4. Test Completion: Once all the tests are executed, create a report detailing the passed,
failed, and blocked test cases.

5. Test Reporting

 Pass/Fail Criteria:
o A test case is considered passed if the actual result matches the expected result.
o A test case is considered failed if the actual result does not match the expected
result.
 Test Summary Report: After executing all test cases, prepare a test summary report that
includes:
o Total number of test cases
o Number of passed test cases
o Number of failed test cases
o Details of defects and issues found during testing
o Recommendations for improvement (if any)

6. Conclusion

Manual testing for the Student Management System ensures that the application works as
expected for all user roles (Admin, Teacher, Student) and functionalities (adding students,
managing attendance, assigning grades, etc.). By following this test plan, you can systematically
identify and address issues in the application, ensuring its quality before release.

White Box Testing Manual Example for Student Management System

1. Test Case: Verify Student ID Generation Logic

Test Description:
Ensure that the system generates unique student IDs when a new student is added to the system.

Code Logic to Test:

 When a new student is added, the system should generate a unique student ID by using an
algorithm or function that ensures no duplication.

Example logic in pseudocode:


python
Copy
def generate_student_id():
student_id = last_student_id + 1
return student_id

Test Steps:

1. Access the application as Admin.


2. Add a new student.
3. Check if the student ID is unique and follows the correct pattern (e.g., incrementing by
1).
4. Add multiple students and verify that the IDs generated are unique each time.

Expected Result:

 The student IDs should be generated incrementally (e.g., 1001, 1002, 1003), with no
duplicates.

White Box Aspect:

 This test verifies the internal code logic for generating unique IDs by ensuring that the
logic (incrementing the ID) works correctly, and that no duplicates are created in the
database.

2. Test Case: Verify Grade Assignment Logic

Test Description:
Ensure that the grading system only accepts valid grade values and handles invalid inputs
appropriately.

Code Logic to Test:

 The system must only accept valid grade values (e.g., A, B, C, D, F).
 If an invalid grade is entered, it should trigger an error or validation message.

Example logic in pseudocode:

python
Copy
def validate_grade(grade):
valid_grades = ['A', 'B', 'C', 'D', 'F']
if grade not in valid_grades:
return "Invalid Grade"
else:
return "Grade Accepted"
Test Steps:

1. Log in as Teacher.
2. Assign a grade of "A" to a student. Verify that the grade is accepted.
3. Assign a grade of "Z" to a student. Verify that an error or warning is generated (e.g.,
"Invalid Grade").
4. Repeat the test with other invalid inputs (e.g., empty input, numbers, special characters).

Expected Result:

 The grade "A" should be accepted.


 The grade "Z" should trigger an error message: "Invalid Grade."

White Box Aspect:

 This test ensures that the internal logic for grade validation works correctly and that
invalid inputs are properly handled by the system.

3. Test Case: Verify Attendance Marking Logic

Test Description:
Test that attendance is correctly marked and that the status is updated in the database.

Code Logic to Test:

 The system should mark attendance as Present or Absent based on the teacher's input
and update the database accordingly.

Example logic in pseudocode:

python
Copy
def mark_attendance(student_id, date, status):
if status not in ['Present', 'Absent']:
return "Invalid Status"
else:
# Update the attendance record in the database
db.execute(f"INSERT INTO attendance (student_id, date, status)
VALUES ({student_id}, {date}, {status})")
return "Attendance Recorded"

Test Steps:

1. Log in as Teacher.
2. Mark attendance for a student with ID 1001 as Present on 2025-04-09.
3. Verify that the attendance is recorded as Present in the database (e.g., check the
attendance table).
4. Mark attendance for the same student as Absent.
5. Verify that the attendance status is correctly updated in the database.

Expected Result:

 The system should record and update the attendance correctly. If a student is marked as
Present or Absent, the status should be saved accurately in the database.

White Box Aspect:

 This test checks the internal logic for marking attendance, ensuring that the system can
correctly update the database according to the teacher's input and that the validation
(checking the status) works as expected.

4. Test Case: Verify Report Generation Logic

Test Description:
Test that the system generates the correct report for a student based on their grades and
attendance.

Code Logic to Test:

 When generating a report for a student, the system should collect data from both the
grades and attendance records and combine them into a report.

Example logic in pseudocode:

python
Copy
def generate_report(student_id):
grades = db.execute(f"SELECT grade FROM grades WHERE student_id =
{student_id}")
attendance = db.execute(f"SELECT status FROM attendance WHERE
student_id = {student_id}")
report = {
'grades': grades,
'attendance': attendance
}
return report

Test Steps:

1. Log in as Teacher.
2. Select a student (e.g., Student 1001).
3. Generate the report for that student.
4. Verify that the report includes both the grades and attendance data for the selected
student.
5. Ensure that the report accurately reflects the data stored in the database for that student.

Expected Result:

 The generated report should include the student’s grades and attendance records.
 The data should match the student’s records in the database.

White Box Aspect:

 This test ensures that the internal logic for fetching and combining data from the grades
and attendance tables works correctly and that the report generation mechanism operates
as expected.

5. Test Case: Verify Search Functionality for Students

Test Description:
Verify that the search functionality for students correctly filters and returns the correct student
records based on the search query.

Code Logic to Test:

 The search function should query the database for student records that match the search
term and return the results.

Example logic in pseudocode:

python
Copy
def search_students(query):
students = db.execute(f"SELECT * FROM students WHERE name LIKE '%
{query}%' OR roll_no LIKE '%{query}%'")
return students

Test Steps:

1. Log in as Admin.
2. Use the search functionality to search for a student by name (e.g., "John").
3. Verify that the student with the name "John" appears in the search results.
4. Search for a student by roll number (e.g., "1234").
5. Verify that the student with the roll number "1234" appears in the search results.

Expected Result:
 The system should return accurate search results that match the name or roll number
provided in the query.

White Box Aspect:

 This test ensures that the internal search logic works correctly, including proper database
querying and result filtering.

Conclusion

White box testing of the Student Management System involves testing the internal logic,
algorithms, and data flow of the application. By examining how the system processes data (such
as student IDs, grades, attendance, and report generation), testers can ensure that the code
functions as expected. This includes testing database interactions, validation logic, and the
application’s behavior when interacting with the backend.

Manual white-box testing typically requires access to the application’s source code and a deep
understanding of the internal workings, which allows testers to focus on the critical paths and
edge cases in the application’s codebase.

Black Box Testing Techniques for the Student Management System

1. Equivalence Partitioning

Equivalence Partitioning divides input data into valid and invalid partitions, and the tester
selects one representative value from each partition to test.

Test Case 1: Add New Student - Valid Input

 Test Description: Verify that the system correctly handles valid student information.
 Test Inputs:
o Name: "John Doe"
o Roll Number: "12345"
o Date of Birth: "2000-01-01"
o Address: "123 Main St"
 Test Steps:

1. Log in as Admin.
2.Navigate to the "Add New Student" form.
3.Enter the above details into the form fields.
4.Click "Save."
 Expected Result:

o The student should be successfully added to the system, and the details should
appear in the student list.

Test Case 2: Add New Student - Invalid Input

 Test Description: Verify that the system rejects invalid student information.
 Test Inputs:
o Name: ""
o Roll Number: "12345" (valid)
o Date of Birth: "2000-01-01" (valid)
o Address: "" (empty)
 Test Steps:

1.Log in as Admin.
2.Navigate to the "Add New Student" form.
3.Leave the "Name" and "Address" fields empty.
4.Click "Save."
 Expected Result:

o The system should show an error message, e.g., "Name and Address are
required."
o The student should not be added.

2. Boundary Value Testing

Boundary Value Testing focuses on testing the boundaries of input values, as errors often occur
at the boundaries.

Test Case 1: Check Minimum Length for Roll Number

 Test Description: Ensure that the system enforces the minimum character length for the
roll number.
 Test Inputs:
o Roll Number: "123" (minimum length of 4 digits is required)
 Test Steps:

1. Log in as Admin.
2. Navigate to the "Add New Student" form.
3. Enter a roll number of "123."
4.Fill in the rest of the student details (name, DOB, address).
5.Click "Save."
 Expected Result:

o The system should display an error message indicating that the roll number is too
short (e.g., "Roll Number must be at least 4 digits").

Test Case 2: Check Maximum Length for Student Name

 Test Description: Ensure that the system correctly handles a long student name
(boundary value).
 Test Inputs:
o Name: "A" * 101 (more than 100 characters)
 Test Steps:

1.Log in as Admin.
2.Navigate to the "Add New Student" form.
3.Enter a name with 101 characters.
4.Fill in the rest of the student details (roll number, DOB, address).
5.Click "Save."
 Expected Result:

o The system should display an error message indicating the name exceeds the
maximum character limit (e.g., "Name cannot exceed 100 characters").

3. Decision Table Testing

Decision Table Testing involves identifying different combinations of inputs and their
corresponding outputs to create a decision table.

Test Case 1: Mark Attendance (Teacher Role)

 Test Description: Verify that attendance marking works for different combinations of
student presence or absence.
 Test Inputs:
o Student 1: Present
o Student 2: Absent
o Student 3: Absent
 Test Steps:

1. Log in as Teacher.
2. Navigate to the "Mark Attendance" section.
3. Mark Student 1 as Present.
4. Mark Student 2 as Absent.
5.Mark Student 3 as Absent.
6.Click "Save."
 Expected Result:

o Attendance should be saved correctly:


 Student 1 is marked Present.
 Student 2 and Student 3 are marked Absent.

Decision Table for Marking Attendance

Student ID Present (P) Absent (A)


Student 1 P
Student 2 A
Student 3 A

4. State Transition Testing

State Transition Testing is used to verify the system's behavior for different states, transitions
between them, and whether the system behaves as expected when inputs are provided.

Test Case 1: Student Login Based on Role

 Test Description: Ensure that users (Admin, Teacher, Student) are taken to the correct
page based on their roles.
 Test Steps:
1. Log in as Admin.
2. Verify that the Admin Dashboard loads.
3. Log in as Teacher.
4. Verify that the Teacher Dashboard loads.
5. Log in as Student.
6. Verify that the Student Dashboard loads.
 Expected Result:

o Admin should be redirected to the Admin Dashboard.


o Teacher should be redirected to the Teacher Dashboard.
o Student should be redirected to the Student Dashboard.

5. Error Guessing

Error Guessing is based on the tester’s experience and intuition to guess where errors might
occur and create tests to validate those areas.
Test Case 1: Attempt to Add Student Without Required Fields

 Test Description: Ensure that the system prevents adding a student when required fields
are missing.
 Test Inputs:
o Name: "John Doe"
o Roll Number: "" (empty)
o Date of Birth: "2000-01-01"
o Address: "123 Main St"
 Test Steps:

1.Log in as Admin.
2.Navigate to the "Add New Student" form.
3.Leave the "Roll Number" field empty.
4.Click "Save."
 Expected Result:

o The system should display an error message like "Roll Number is required" and
should not allow adding the student.

Test Case 2: Test Large Number of Students for Performance

 Test Description: Ensure that the system handles the addition of a large number of
students without crashing or slowing down.
 Test Steps:
1. Log in as Admin.
2. Add a large number of students (e.g., 500 students).
3. Monitor the system’s response time and check if the page loads correctly.
 Expected Result:

o The system should not crash, and the page should load efficiently even with a
large number of students.

6. Usability Testing (Part of Black Box)

Usability testing checks the user interface and experience.

Test Case 1: Verify Navigation and User Interface

 Test Description: Ensure that users can easily navigate between sections of the
application.
 Test Steps:
1. Log in as Admin.
2. Verify that the navigation links (Dashboard, Manage Students, Attendance,
Grades, etc.) are visible and clickable.
3. Click through different sections and ensure the interface is intuitive.
 Expected Result:

o All sections should be accessible, and the user should be able to navigate
seamlessly between them.

Conclusion

Black box testing for the Student Management System focuses on validating the functionality,
user interface, and behavior of the system based on the inputs and expected outputs, without
knowledge of the internal code. By applying techniques such as Equivalence Partitioning,
Boundary Value Testing, Decision Table Testing, State Transition Testing, and Error
Guessing, we can ensure that the system meets the requirements and functions as expected in
real-world scenarios.

Test Case Format for Student Management System

1. Test Case ID

 A unique identifier for the test case (e.g., TC_SMS_001).

2. Test Case Title

 A brief description of what the test case is testing (e.g., Login with Valid Credentials).

3. Test Designed By

 The name of the person designing the test case (e.g., John Doe).

4. Test Priority

 Define the priority of the test case (e.g., High, Medium, Low).

5. Test Category

 Type of testing: Functional, Non-functional, Security, Performance, etc.


6. Module Name

 The module being tested (e.g., User Authentication, Student Management).

7. Pre-conditions

 The conditions that must be met before executing the test (e.g., User is logged in,
Database contains students).

8. Test Data

 Data that will be used during the test (e.g., Valid username = "admin", Valid password
= "admin123").

9. Test Steps

 A detailed list of steps to be followed to perform the test (e.g.):


1. Open the application.
2. Enter the valid username and password.
3. Click the Login button.

10. Expected Result

 The expected outcome after performing the test steps (e.g., The Admin dashboard
should load).

11. Actual Result

 The outcome observed after executing the test. This should be filled in after executing the
test (e.g., Admin dashboard loaded successfully).

12. Status

 The status of the test case after execution:


o Pass (if the actual result matches the expected result)
o Fail (if the actual result differs from the expected result)
o Blocked (if the test cannot be executed for some reason)

13. Defect ID (If Any)

 A reference ID to any defect identified during testing, if applicable (e.g., DEF_001).

14. Remarks

 Any additional notes or observations related to the test (e.g., UI loading time was slower
than expected).
15. Execution Date

 The date when the test case was executed.

16. Executed By

 The name of the person who executed the test case (e.g., Jane Smith).

Sample Test Case for Student Management System

Field Details
Test Case ID TC_SMS_001
Test Case Title Login with Valid Credentials
Test Designed By John Doe
Test Priority High
Test Category Functional
Module Name User Authentication
Pre-conditions User is registered with valid credentials, application is up and running.
Test Data Username: admin, Password: admin123
1. Open the login page.
2. Enter "admin" as the username.
Test Steps
3. Enter "admin123" as the password.
4. Click on the Login button.
Expected Result The Admin dashboard should be displayed.
Actual Result Admin dashboard was displayed correctly.
Status Pass
Defect ID (If Any) N/A
Remarks N/A
Execution Date 2025-04-09
Executed By Jane Smith

Sample Test Case for Adding a Student

Field Details
Test Case ID TC_SMS_002
Test Case Title Add New Student
Test Designed
John Doe
By
Test Priority High
Test Category Functional
Module Name Student Management
Field Details
Pre-conditions Admin is logged in, the system is up and running.
Student Name: "John Doe", Roll Number: 12345, Date of Birth: 01/01/2000,
Test Data
Address: "123 Main St"
1. Log in as Admin.
2. Navigate to the "Add New Student" form.
Test Steps
3. Enter the student data into the form.
4. Click on the Save button.
Expected The student should be added successfully, and a confirmation message should
Result appear. The student should appear in the student list.
Actual Result Student was added successfully and appeared in the list.
Status Pass
Defect ID (If
N/A
Any)
Remarks N/A
Execution
2025-04-09
Date
Executed By Jane Smith

Guidelines for Writing Test Cases

1. Test Case ID: Use a structured format to make the ID unique and easy to trace (e.g.,
TC_<Module>_<Sequence>).
2. Test Priority: Define test case priorities:
o High: Critical to functionality, should be tested first.
o Medium: Important but not urgent.
o Low: Optional, should be tested last.
3. Test Category: Categorize your tests based on the type of testing (e.g., functional,
security, performance, etc.).
4. Pre-conditions: Clearly state the necessary setup before the test is executed.
5. Test Steps: Break down the steps to be followed in a sequence. It should be clear and
actionable.
6. Expected Result: Define the expected behavior of the system to meet the requirements.
7. Actual Result: After running the test, document the system's actual behavior.
8. Status: Evaluate whether the test passed or failed based on the comparison of actual vs.
expected results.
9. Defect ID: If a bug is encountered during the test, link it to the defect management
system (e.g., JIRA).
10. Remarks: Add any observations or clarifications.

This Test Case Format ensures that all aspects of the system are thoroughly tested and tracked,
facilitating clear communication between testers, developers, and project managers.

You might also like