TESTING PLAN OUTLINE

PREFACE

The document contains a detailed test plan for the Hall Booking System application to test all the application's use cases, features, and functionalities. The entire test plan outline is divided into 3 sections

• Frontend Tests
• Backend Tests
• Integration Tests Under each test plan, the test suites are written in Italic Headings and the test cases are written under each subcategory.

1. FRONTEND TESTS

UI rendering test cases:

The aim is to:

• Verify that all UI components render correctly on different screen sizes and resolutions.
• Ensure consistent styling across browsers and devices.

User interaction test cases:

The aim is to:

• Test user interactions such as clicks, keyboard inputs, hover effects, and touch gestures.
• Verify that interactive elements (buttons, links, dropdowns) respond as expected.

Form validation test cases:

The aim is to:

• Write a test case for validating invalid data into input fields of forms.
• Verifying proper error messages are displayed and that form can’t be submitted with invalid data.
• Navigation test cases:
• Test cases to check navigation between different pages/routes of the application is working fine.
• Verifying links and navigation buttons work properly and lead to expected destinations.

Responsive Design test cases:

• Test cases to ensure the responsiveness of the application by resizing the browser window and checking how UI elements adapt to different screen sizes.
• Checking responsiveness in different devices(mobiles, laptops etc).

Performance test cases:

• Testing frontend applications based on load times, rendering speeds, and responsiveness to user interactions.
• Try to enhance performance by limiting bottlenecks.
• Cross-Browser compatibility test cases:
• Testing applications across different web browsers(Chrome, Mozilla Firefox, Safari, etc) to ensure consistent behavior and appearance.
• Verifying that the application functions correctly and displays properly in various browser environments.

2. BACKEND TESTS

Test cases on all the database models

The tests on the database models were to be written which included:

• booking
• club
• event
• hall
• itComplaints
• membership
• session
• student
• ticket
• user
• ticketBooking

Test cases on database schema definition

Test cases need to be written to define the structure of the database tables, including tables for halls, booking, admin, users, etc. It may be written in SQL or TypeORM.

Test cases on database connection configuration

• Test cases to ensure the database connection configuration file contains the correct database URL.
• Test cases to mock the database connection to simulate a connection attempt and assert that the correct URL is used.

Test cases on verifying credential encryption

• Test cases to ensure that sensitive credentials(such as username and password) are properly encrypted or stored securely.
• Test cases to mock the database connection initialization and to assert that credentials are encrypted before being passed to the database driver.

Test cases on creating backend API route

• Test cases to send a POST request to create a Booking API route with valid booking data.
• Test cases to check the response status code is 201(Created).

Test cases on get booking Backend API route

Checking the GET request and its response code.

Test cases on middleware functions

• Test cases to mock the authentication middleware to simulate a request with valid or invalid authentication credentials.
• Assertion will be that middleware correctly verifies the authentication credentials and either allows or denies access to the requested route.

3. INTEGRATION TESTS

Test cases on verifying booking creation:

The aim is to:

• Send a POST request to the create booking API route with valid booking data.
• Ensure that the booking controller properly handles the request and interacts with the booking model to create a new booking.
• Assert that the booking is successfully added to the database.
• Verify that the response status code is 201 (Created) and that the returned data contains the newly created booking information.

Test cases on verifying booking retrieval:

The aim is to:

• Insert some test data into the database representing existing bookings.
• Send a GET request to the get bookings API route.
• Ensure that the request is properly handled by the API route and controller.
• Assert that the response status code is 200 (OK) and that the returned data matches the expected format and contains all existing bookings.

Test cases on verifying error handling:

The aim is to:

• Send a request with invalid data or incorrect parameters to various API routes (e.g., create booking, get bookings).
• Ensure that the API routes and controllers handle the errors gracefully and return appropriate error responses.
• Assert that the response status codes are as expected (e.g., 400 for bad request, 404 for not found) and that the error messages are informative and helpful.

Test cases on verifying authentication middleware:

The aim is to:

• Send a request to an authenticated API route with valid authentication credentials.
• Ensure that the authentication middleware properly verifies the credentials and allows access to the requested route.
• Assert that the response status code is as expected and that the route handles the request correctly.