Testing Ibn Al-Haytham LMS

Ibrahim Habib

Zeyad Mohamed

Mohamed Essam

Youssef Ahmed

Youssef Mahmoud

2025-11-25

Table of contents

• 1 Intro
• 2 System Requirements (Functional Requirements)
• 3 System Requirements (Non-Functional Requirements)
• 4 Testing Strategy
• 5 Testing the System
• 6 Conclusion

1 Intro

1.1 What is Ibn Al-Haytham LMS?

• LMS used by Suez Canal University and other public universities in Egypt.
• Provides course registration, grades, and status tracking.
• Recently updated with a total redesign.

1.2 Objectives

• Test the new version of Ibn Al-Haytham LMS.
• Identify bugs and usability issues.
• Provide feedback for improvements.

2 System Requirements (Functional Requirements)

2.1 Credentials Management

• Users MUST change their default password upon first login.
• Passwords must meet complexity requirements
  • Between 8 and 30 characters.
  • Contains 3 of the following: uppercase letters, lowercase letters, numbers, special characters.
• Passwords can be changed through the “Change Password” option.
• Passwords can be reset by authorized personnel.

2.2 Personal Data Management

• Students can view their personal data.
• Student data can only be modified by authorized personnel.
• Include contact information, high school data, university data, and military status.

2.3 Courses Grades

• Students can view full details of their courses and grades (Course Code, Course Name, Credit Hours, Degree, Grade).
• All grades for all courses for all semesters should be available at all times.
• Each semester should include GPA and Cumulative GPA.
• Each semester should include the number of registered and completed credit hours.
• Zero tolerance for missing or incorrect grades.

2.4 Academic Registration

• Students can only register in the correct time frame.
• The number of registered credit hours must not exceed the allowed limit based on the student’s GPA.
• Students can only register for courses they are eligible for (prerequisites met, not already completed).
• Students can drop courses within the allowed time frame.
• Students can view their current registration status and registered courses at any time.

2.5 Fees

• Students can see a detailed breakdown of their fees.
• Students can view payment history.
• Students can see outstanding balances.
• An extra fee for late payments should be applied automatically if fees are not paid by the deadline.

2.6 Military Data

• Military status must be accurately recorded and displayed.
• Exemptions should be clearly indicated.
• A student can’t change his military status.
• Military data can only be modified by authorized personnel.
• Military education stats should be updated after completing military training.

2.7 Hours Progress

• Students can view their total registered and completed credit hours.
• Students can see how many credit hours are remaining to graduate.
• Students can view a breakdown of credit hours by category (e.g., core, elective).
• All progress data should be accurate and up-to-date.

2.8 Timetables

• Students can view their class schedules for the current semesters.
• Schedules should include course names, times, locations, and instructors.
• Timetables should adapt for each student based on their registered courses.

3 System Requirements (Non-Functional Requirements)

3.1 Performance

• The system should load pages within 3 seconds under normal conditions.
• The system should handle up to 10,000 concurrent users without performance degradation.
• Database queries should be optimized to minimize response times.

3.2 Security

• User data must be encrypted both in transit and at rest.
• The system should implement multi-factor authentication for sensitive operations.
• Students can only access their own data.
• Students cannont access their grades before the official release date.

3.3 Compatibility

• The system should be compatible with major web browsers (Chrome, Firefox, Safari, Edge).
• The system should be responsive and usable on various devices (desktops, tablets, smartphones).
• The system should support screen readers and other assistive technologies for accessibility.

3.4 Maintainability

• All critical changes should take no more than 2 working days to implement.
• All minor changes should take no more than 5 working days to implement.
• All system components should be modular and well-documented to facilitate maintenance.

4 Testing Strategy

4.1 Testing Phases

• Unit Testing: Test individual components.
• Integration Testing: Ensure different modules work together.
• System Testing: Validate the complete system against requirements.
• User Acceptance Testing (UAT): Gather feedback from users

4.2 Testing Methods

• Automated Testing: Use tools to automate repetitive tests.
  • Used everywhere possible
• Manual Testing: Perform exploratory testing and usability assessments.
  • Used for usability testing and complex scenarios

4.3 Testing Steps

1. Tests Definition
2. Automated Tests Implementation
3. Manual Tests Execution
4. Bug Reporting
5. Bug Fixing

5 Testing the System

5.1 Unit Testing

• Requires access to the source code.
• Focus on individual functions and methods.
• Aim to achieve 90% code coverage.
• Should be automated and integrated into the CI/CD pipeline.

5.2 Sample Unit Test Cases (New Password Validation)

• Password length between 8 and 30 characters.
• Password contains at least 3 of the following:
  • uppercase letters
  • lowercase letters
  • numbers
  • special characters

5.3 Sample Unit Test Codes (in Python)

import unittest
from password_validator import validate_password

class TestPasswordValidation(unittest.TestCase):

    def test_valid_password(self):
        self.assertTrue(validate_password("Valid1@Password"))

    def test_short_password(self):
        self.assertFalse(validate_password("Short1@"))

    def test_long_password(self):
        self.assertFalse(validate_password("L" * 31 + "1@a"))

    def test_only_lowercase(self):
        self.assertFalse(validate_password("alllowercase"))

5.4 Integration Testing

• Test interactions between modules (e.g., registration and grades).
• Should be automated where possible.

5.5 Sample Integration Test Case

Verify that course registration updates the student’s timetable.

def test_course_registration_updates_timetable():
    student = students_repository.get_student(student_id=123)
    course = Course(code="CS101")
    student.register_course(course)
    assert course in student.get_timetable().courses

5.6 System Testing

• Validate the entire system against functional and non-functional requirements.
• Should begin on the developer’s side (alpha testing)
• Select a group of end-users to perform beta testing.

5.7 Sample Functional Test Case

Verify that students can view their grades after the official release date.

1. University admin set the grades release date.
2. Login as a student before the release date.
3. Attempt to view grades (should be inaccessible).
4. Login as the same student after the release date.
5. Attempt to view grades (should be accessible).
6. Verify that the displayed grades match the database records.

5.8 Sample Non-Functional Test Case

Verify system handles 10,000 concurrent users.

1. Use a load testing tool.
2. Simulate 10,000 concurrent users accessing the system.
3. Monitor response times and system performance.
4. Ensure all pages load within 3 seconds.
5. Simulate 50,000 concurrent users.
6. Ensure the system remains stable, even if performance degrades.

5.9 Exploratory Testing

• Testers explore the system without predefined test cases.
• Focus on usability, navigation, and overall user experience.
• Document any issues or areas for improvement.
• Expensive in terms of time and effort.

5.10 Example Exploratory Testing Scenarios

• Testing new password change process.
• Change course registration workflow.
• Navigating the updated user interface.
• Change system language settings.
• Calculating GPA and credit hours progress.

5.11 Exploratory Testing Notes Example

Good Points

• GPA calculation is accurate.
• Course registration process is straightforward.
• Both Arabic and English languages are well supported.

Issues Found

• Doesn’t support special characters in passwords.
• Military status information is unclear.
• Interface is hard to understand for new users.

6 Conclusion

6.1 What We Have Done

• Defined functional and non-functional requirements for Ibn Al-Haytham LMS.
• Developed a comprehensive testing strategy.
• Developed plans for various testing phases.
• Showed sample test cases and code snippets.
• Performed exploratory testing on the live system and documented findings.

Acknowledgments

• Dr. Samah Zakaria - For her great QA course and continuous support.
• Dr. Mirhan Hisham - For her valuable hands-on sessions.

Questions?

Thank You!