Software Testing & Quality Assurance | UBTCE311 Pimpri Chinchwad University Harshal | Roll No. E - 10 | Division E | Sem 6 Page N/A PIMPRI CHINCHWAD UNI VERSITY Department of Computer Science & Engineering SOFTWARE TESTING AND QUALITY ASSURANCE UBTCE311 – Practical Examination Document Multi - Domain Case Studies: IEEE - Style Test Documentation Student Name Harshal Roll Number E - 10 Division E Semester 6th Semester – Academic Year 2025 – 26 Course Code UBTCE311 Document Type STQA Case Study – Multi - Domain Testing Date April 2026 Domains Covered: Hospital Management | Banking | Library Management | Student Management | E - Commerce Software Testing & Quality Assurance | UBTCE311 Pimpri Chinchwad University Harshal | Roll No. E - 10 | Division E | Sem 6 Page N/A TABLE OF CONTENTS Domain 1: Hospital Management System Section 2 Domain 2: Banking System Section 3 Domain 3: Library Management System Section 4 Domain 4: Student / College Management System Section 5 Domain 5: E - Commerce System Section 6 Each domain is independently structured covering: Problem Statement, Introduction, Objectives, System Modules, Testing Strategy, Unit Testing, Integration Testi ng, System Testing, Web Application Testing, Automation Testing, Test Case Design Techniques, Defect Reporting, and Conclusion. Software Testing & Quality Assurance | UBTCE311 Pimpri Chinchwad University Harshal | Roll No. E - 10 | Division E | Sem 6 Page N/A DOMAIN 1: HOSPITAL MANAGEMENT SYSTEM 1. Problem Statement A large multi - specialty hospital faces critical challenges in man aging patient registrations, doctor schedules, medical records, billing, and pharmacy inventory using manual paper - based processes. These inefficiencies lead to data loss, appointment conflicts, billing errors, and compromised patient care. A software - base d Hospital Management System (HMS) is required to digitize and streamline all hospital operations. This document outlines the testing strategy applied to validate that the HMS functions correctly, reliably, and securely across all modules. 2. Introduction 2.1 Overview The Hospital Management System (HMS) is a web - based application designed to automate and integrate all hospital administrative and clinical operations. It serves patients, doctors, nurses, receptionists, pharmacists, and hospital administrators through rol e - specific dashboards. 2.2 Purpose The purpose of this document is to define the testing strategy, test cases, defect reporting, and quality metrics for the HMS to ensure that the delivered system is defect - free and meets all functional and non - functional requirements. 2.3 Scope The scope covers testing of all seven core modules: Patient Registration, Appointment Scheduling, Doctor Management, Medical Records (EMR), Pharmacy, Billing, and Admin/Reporting. Both functional and non - functional testing is includ ed. 3. Objectives • Verify that patient registration and authentication work correctly. • Validate appointment booking logic including conflict detection. • Ensure medical records are stored, retrieved, and updated accurately. • Test billing calculations including insurance deductions and GST. • Validate pharmacy inventory management and prescription linkage. • Confirm role - based access control restricts unauthorized operations. • Perform load and stress testing to ensure system stabili ty under peak usage. 4. System Modules • Patient Registration Module: Handles new patient registration, login, profile management, and medical history storage. • Appointment Scheduling Module: Manages booking, rescheduling, and cancellation of doctor appointme nts with conflict checks. • Doctor Management Module: Maintains doctor profiles, specializations, availability, and consultation history. • Electronic Medical Records (EMR): Stores diagnoses, prescriptions, lab reports, and treatment history per patient. • Pharm acy Module: Tracks medicine inventory, links prescriptions, manages stock alerts and expiry tracking. • Billing & Payments Module: Generates itemized bills, processes payments, applies insurance, and produces receipts. • Admin & Reports Module: Provides hospit al - wide analytics, user management, and audit logs. 5. Testing Strategy Software Testing & Quality Assurance | UBTCE311 Pimpri Chinchwad University Harshal | Roll No. E - 10 | Division E | Sem 6 Page N/A Testing follows a V - Model approach aligned with IEEE 829. Unit testing validates individual modules in isolation. Integration testing verifies interactions between dependent modules (e .g., Appointment → EMR → Billing). System testing covers complete patient workflows end - to - end. Web application testing covers UI, form validation, session management, and security. Automation testing uses Selenium WebDriver for regression of critical path s. Types applied: Functional Testing, Regression Testing, Boundary Value Analysis, Equivalence Partitioning, Security Testing, Performance Testing, and UAT. 6. Unit Testing 6.1 Modules Under Unit Test Patient Registration, Appointment Scheduling, Billing C alculator, Pharmacy Inventory, Doctor Schedule Validator. TC ID Description Input Expected Output Actual Output Status TC - HMS - U01 Register new patient with valid data Name: John Doe, DOB: 12/05/1990, Phone: 9876543210, Blood Group: B+ Patient registered, unique Patient ID P1001 generated, confirmation SMS sent Patient ID P1001 generated; SMS sent Pass TC - HMS - U02 Register patient with duplicate phone number Phone: 9876543210 (already exists) Error: 'Phone number already registered. Please login.' Error displayed as expected Pass TC - HMS - U03 Book appointment with available doctor slot Patient: P1001, Doctor: Dr. Mehta (Cardiology), Date: 15 - Apr - 2026, Slot: 10:00 AM Appointment ID A2045 created; slot marked unavailable; notification sent Appointment A2045 created successfully Pass TC - HMS - U04 Book appointment on already - occupied slot Doctor: Dr. Mehta, Date: 15 - Apr - 2026, Slot: 10:00 AM (booked) Error: 'Selected slot is unavailable. Please choose another time.' Error shown, no duplicate booking created Pass TC - HMS - U05 Calculate bill with 18% GST and 30% insurance deduction Consultation: Rs.500, Lab: Rs.2000, GST: 18%, Insurance: 30% Gross: Rs.2500, GST: Rs.450, Subtotal: Rs.2950, Insurance deduction: Rs.885, Net payable: Rs.2065 Net payable Rs.2065 displayed correctly Pass TC - HMS - U06 Pharmacy: dispense medicine against valid prescription Prescription ID: Rx - 7801, Medicine: Amoxicillin 500mg x10, Stock: 150 Stock reduced to 140; prescription marked dispensed; patient receipt printed Stock updated to 140; dispensed flag set Pass TC - HMS - U07 Pharmacy: attempt to dispense out - of - stock medicine Medicine: Insulin 100IU, Current stock: 0 Error: 'Insulin 100IU is out of stock. Please raise a purchase request.' Stock alert displayed; dispensing blocked Pass 7. Integration Testing 7.1 Module Interactions Key integration flows: (1) Patient Registration → Appointment Scheduling: Patient account must exist before booking. (2) Appointment → EMR: Doctor must access patient EMR during consultation. (3) Doctor's Prescription in EMR → Pharmacy: Prescription flows automatically to pharmacy queue. (4) All services → Billing: All charges from consultation, lab, and pharmacy consolidate into one bill. Software Testing & Quality Assurance | UBTCE311 Pimpri Chinchwad University Harshal | Roll No. E - 10 | Division E | Sem 6 Page N/A TC ID Scenario Expected Result Actual Result Status TC - HMS - I01 Patient registers, then books appointment successfully Appointment created and linked to Patient ID P1001; doctor notified Appointment linked correctly; notification delivered Pass TC - HMS - I02 Doctor accesses patient EMR during consultation, updates diagnosis and raises prescription Diagnosis saved in EMR; prescription Rx - 7802 auto - queued in Pharmacy module EMR updated; Rx - 7802 visible in pharmacy queue Pass TC - HMS - I03 Pharmacy dispenses medicine; billing module auto - generates consolidated bill Bill includes consultation Rs.500 + pharmacy Rs.300; total Rs.800 Bill of Rs.800 generated and sent to patient portal Pass TC - HMS - I04 Admin disables a doctor account; system prevents new appointments for that doctor Booking attempt for disabled doctor shows: 'Doctor is currently unavailable' Appointment blocked; error message shown Pass 8. System Testing 8.1 End - to - End Scenarios System testing validates complete hospital workflows from a patient's first visit through discharge and billing. TC ID Scenario Expected Result Actual Result Status TC - HMS - S01 Full patient lifecycle: Registration → Appointment → Consultation → Prescription → Pharmacy → Bill → Discharge Patient receives discharge summary; bill paid; EMR updated with complete visit record All stages completed; discharge summary generated; payment receipt issued Pass TC - HMS - S02 Emergency patient admission bypassing standard appointment flow Patient admitted directly; emergency flag set; EMR opened immediately; alert sent to on - call doctor Emergency admission processed in under 30 seconds; on - call doctor alerted Pass TC - HMS - S03 Admin generates monthly revenue report Report shows total revenue, department - wise breakdown, outstanding payments for the month Accurate report generated and exported to PDF Pass TC - HMS - S04 Pharmacist triggers a low - stock alert and generates purchase order Alert email sent to procurement; PO - 2026 - 04 created with medicine details and quantity required Email sent; purchase order created with correct details Pass 9. Web Application Testing 9.1 UI and Usability All forms render correctly across Chrome, Firefox, and Edge. Navigation menus collapse properly on mobile. Date pickers reject manual text entry. 9.2 Form Validation Software Testing & Quality Assurance | UBTCE311 Pimpri Chinchwad University Harshal | Roll No. E - 10 | Division E | Sem 6 Page N/A Phone number field accepts only 10 - digit numeric input. Age field rejects negative values and values above 120. Email field validates standard RFC format. Password fields enforce minimum 8 characters with one uppercase, one digit, and o ne special character. 9.3 Session Handling Sessions expire after 15 minutes of inactivity. Concurrent login from two devices triggers a security alert and terminates the earlier session. CSRF tokens are validated on all form submissions. 9.4 Security Testi ng • SQL Injection: Input ' OR '1'='1 in login fields — blocked by parameterized queries. • XSS: Script tag <script>alert('xss')</script> in patient name — sanitized and not executed. • Unauthorized URL access: Direct URL to /admin/reports without login — redire cted to login page with HTTP 401. • Brute force: 5 incorrect login attempts — account locked for 15 minutes; email alert sent. TC ID Scenario Expected Result Actual Result Status TC - HMS - W01 Patient login with correct credentials Dashboard loaded with patient's appointment history and profile Dashboard displayed correctly Pass TC - HMS - W02 SQL injection in login username field Error: 'Invalid credentials' shown; no database error exposed Login blocked; generic error shown Pass TC - HMS - W03 Session expiry after 15 minutes idle User redirected to login page; session token invalidated Redirected to login after timeout Pass TC - HMS - W04 Receptionist accesses Doctor Management settings (unauthorized) Access denied: 'You do not have permission to view this page' 403 Forbidden page displayed Pass 10. Automation Testing Selenium WebDriver with Python and TestNG framework automates regression testing of critical workflows. • Automated Scenario 1 – Patient Login & Appointment Booking: Script navigates to HMS portal, enters valid credentials, selects a doctor and available slot, submits booking, and asserts appointment confirmation message and ID appear on screen. • Automated Scenario 2 – Billing Calculation Verification: Script creates a test patient visit with predefined services, triggers bill generation, extracts totals from the UI, and asserts amounts match expected values (including GST and insurance) within ±Rs .1 tolerance. • Automated Scenario 3 – Admin Report Generation: Script logs in as admin, navigates to Reports, selects current month, downloads PDF, and asserts the file size is greater than 0 KB and file name follows the pattern report_YYYY_MM.pdf. 11. Test Case Design Techniques 11.1 Boundary Value Analysis (BVA) Applied to patient age field: Valid boundaries are 0 – 120. Test values: - 1 (invalid), 0 (valid minimum), 1 (valid), 120 (valid maximum), 121 (invalid). Applied to appointment time: Valid slots 09:00 – 17:00; test at 08:59 (reject), 09:00 (accept), 17:00 (accept), 17:01 (reject). 11.2 Equivalence Partitioning (EP) Blood group field: Valid partition {A+, A - , B+, B - , AB+, AB - , O+, O - }; invalid partition {XY, 123, empty string}. One test case per partition suffices to achieve coverage. 11.3 Decision Table Testing Software Testing & Quality Assurance | UBTCE311 Pimpri Chinchwad University Harshal | Roll No. E - 10 | Division E | Sem 6 Page N/A Used for billing logic: combinations of outpatient/inpatient status, insurance availability (yes/no), and emergency flag (yes/no) produce a matrix of 8 billing rule scenarios, each tested independently. 12. Defect Reporting 12.1 Defect Lifecycle New → Assi gned → In Progress → Fixed → Retest → Closed (or Reopened if fix is insufficient). Critical defects block the build until resolved. Defect ID Description Severity Priority Status Assigned To DEF - HMS - 001 Duplicate appointments allowed for same doctor slot when two users book simultaneously (race condition) Critical P1 – Urgent In Progress Backend Dev DEF - HMS - 002 Bill PDF export fails when patient name contains special characters (e.g., O'Brien) Medium P2 – High Fixed – Retesting Backend Dev DEF - HMS - 003 Low - stock alert email not triggered when stock falls to exactly 1 unit (off - by - one) High P1 – Urgent Closed Dev Team 13. Conclusion The Hospital Management System underwent rigorous multi - level testing including unit, integration, system, and web application testing. A total of 7 unit test cases, 4 integration test cases, 4 system test cases, and 4 web application test cases were execu ted with a pass rate of 95%. Three defects were identified, of which one critical defect (race condition in appointment booking) is under resolution. The system demonstrates readiness for UAT pending resolution of open defects. Testing confirms that the HM S correctly handles patient workflows, enforces role - based security, and produces accurate billing and pharmacy outputs. Software Testing & Quality Assurance | UBTCE311 Pimpri Chinchwad University Harshal | Roll No. E - 10 | Division E | Sem 6 Page N/A DOMAIN 2: BANKING SYSTEM 1. Problem Statement A national cooperative bank currently operates on legacy systems that process fund t ransfers, account management, and loan disbursements through isolated desktop applications with no real - time synchronization. This results in transaction failures, duplicate entries, incorrect balance updates, and high vulnerability to fraud. A modern core banking web application is required. This document outlines the comprehensive testing strategy for the Core Banking System (CBS) to validate correctness, security, and data integrity across all operations. 2. Introduction 2.1 Overview The Core Banking System (CBS) is an online banking application enabling customers to manage accounts, transfer funds, apply for loans, and view transaction history. Bank staff can manage customer KYC, approve transactions above thresholds, and generate com pliance reports. 2.2 Purpose This document defines the test strategy, test cases, and defect management approach to ensure the CBS operates reliably, securely, and in compliance with RBI guidelines. 2.3 Scope Scope includes Account Management, Fund Transfe r (NEFT/RTGS/IMPS), Loan Module, Fixed Deposits, ATM/Card Services, and Admin/Compliance Reporting. 3. Objectives • Validate that account balances update atomically during fund transfers (no partial updates). • Ensure transaction rollback occurs correctly when any step in a transfer fails. • Verify that interest calculations for savings, FD, and loans are mathematically accurate. • Test OTP - based two - factor authentication for all financial transactions. • Confirm that daily transaction limits are enforced per account type. • Validate fraud detection alerts trigger on suspicious patterns. 4. System Modules • Account Management Module: Create/update/close savings, current, and NRE accounts; KYC verification; pass book generation. • Fund Transfer Module: NEFT, RTGS, IMPS transfers with real - time balance deduction and credit. • Loan Management Module: Loan applications, eligibility checks, EMI calculation, disbursement, and repayment tracking. • Fixed Deposit Module: FD cr eation, maturity calculation, premature withdrawal with penalty. • ATM/Card Services Module: Debit card issuance, PIN management, card blocking/unblocking. • Admin & Compliance Module: AML reports, RBI returns, user access management, audit trails. 5. Testing Strategy Testing adheres to a risk - based approach, prioritizing financial transaction modules due to their direct monetary impact. Unit testing validates individual calculation functions (interest, EMI). Integration testing verifies the Account → Transacti on → Ledger pipeline. System testing runs end - to - end customer journeys. Security testing focuses heavily on authentication, session management, and injection attacks given the financial sensitivity of data. Software Testing & Quality Assurance | UBTCE311 Pimpri Chinchwad University Harshal | Roll No. E - 10 | Division E | Sem 6 Page N/A 6. Unit Testing 6.1 Modules Under Unit Test Inter est Calculator, EMI Calculator, Balance Deduction Engine, OTP Generator, Daily Limit Checker. TC ID Description Input Expected Output Actual Output Status TC - CBS - U01 Open new savings account with valid KYC documents Name: Priya Shah, PAN: ABCDE1234F, Aadhaar: 1234 - 5678 - 9012, Initial deposit: Rs.10,000 Account No. SB - 20260001 created; balance Rs.10,000; KYC status: Verified Account created; balance Rs.10,000 confirmed Pass TC - CBS - U02 IMPS fund transfer within daily limit with sufficient balance From: SB - 20260001, To: SB - 20260099, Amount: Rs.5,000, OTP: 482910 Debit Rs.5,000 from sender; Credit Rs.5,000 to receiver; Transaction ID TXN - 78234 generated Transfer successful; both balances u pdated correctly Pass TC - CBS - U03 Fund transfer exceeding account balance Account balance: Rs.3,000, Transfer amount: Rs.8,000 Error: 'Insufficient balance. Available balance: Rs.3,000' Transfer rejected; error message shown; balance unchanged Pass TC - CBS - U04 EMI calculation for home loan Principal: Rs.20,00,000, Rate: 8.5% p.a., Tenure: 20 years (240 months) EMI = Rs.17,356 per month (verified with standard formula) System calculated EMI: Rs.17,356 Pass TC - CBS - U05 FD maturity amount calculation with quarterly compounding Principal: Rs.1,00,000, Rate: 7% p.a., Duration: 2 years, Compounding: Quarterly Maturity amount = Rs.1,14,888 (A = P(1+r/n)^nt) System shows Rs.1,14,888 — correct Pass TC - CBS - U06 OTP validation: expired OTP (older than 5 minutes) OTP: 391045 generated 7 minutes ago Error: 'OTP expired. Please request a new OTP.' Expired OTP rejected; new OTP prompt shown Pass TC - CBS - U07 Block debit card via customer portal Card No. last 4 digits: 4892, Reason: Lost Card status set to BLOCKED; transaction attempted after blocking is declined Card blocked; test debit declined with 'Card is blocked' message Pass 7. Integration Testing 7.1 Module Interactions Critical flows: Fund Transfer → Ledger → Notification (all three must succeed atomically). Loan Application → Credit Score Check → Approval → Disbursement to Account. FD Creation → Account Debit → FD Certificate Generation. TC ID Scenario Expected Result Actual Result Status TC - CBS - I01 Fund transfer from savings to savings updates ledger and sends debit/credit SMS to both parties Sender receives SMS 'Debit Rs.5,000 Ac SB - 20260001'; Receiver receives credit SMS; ledger entry created Both SMS delivered; ledger shows correct debit - credit pair Pass Software Testing & Quality Assurance | UBTCE311 Pimpri Chinchwad University Harshal | Roll No. E - 10 | Division E | Sem 6 Page N/A TC ID Scenario Expected Result Actual Result Status TC - CBS - I02 Loan disbursement credited to linked savings account Loan of Rs.5,00,000 approved; amount credited to account SB - 20260001 within 30 minutes Balance updated from Rs.10,000 to Rs.5,10,000; loan account LA - 2026001 created Pass TC - CBS - I03 Transaction rollback when NEFT transfer fails midway (receiver bank unreachable) Full Rs.15,000 refunded to sender within 2 hours; failure SMS sent; transaction marked FAILED in history Refund processed; status FAILED; SMS received Pass TC - CBS - I04 Admin freezes account; all debit transactions decline, credits allowed Debit attempt: 'Account is frozen. Contact your branch.'; Credit NEFT of Rs.2,000 succeeds Debit blocked; credit allowed; account status shows FROZEN Pass 8. System Testing TC ID Scenario Expected Result Actual Result Status TC - CBS - S01 End - to - end home loan journey: Application → Document Upload → Eligibility Check → Approval → Disbursement → EMI Auto - debit Loan disbursed to account; first EMI deducted on scheduled date; EMI schedule visible in dashboard All stages completed; disbursement and EMI deduction verified Pass TC - CBS - S02 FD premature withdrawal with penalty deduction FD of Rs.50,000 for 2 years broken after 8 months; penalty 1% applies; maturity calculated for 8 months Maturity reduced; penalty Rs.500 deducted; Rs.52,750 credited to account Correct penalty applied; balance updated Pass TC - CBS - S03 Daily transfer limit enforcement across multiple transactions Customer makes IMPS transfers: Rs.50,000 + Rs.30,000 + Rs.25,000 (total Rs.1,05,000; limit Rs.1,00,000) First two succeed; third partially or fully blocked with 'Daily limit reached' message Limit enforced; third transfer blocked Pass TC - CBS - S04 Admin generates AML suspicious transaction report for auditor Report lists all transactions above Rs.10 lakh in April 2026 with customer PAN details Report generated; 3 transactions flagged; exported to encrypted PDF Report generated correctly with correct flagging Pass 9. Web Application Testing 9.1 Security Focus Banking applications require the highest security standards. The following were tested: HTTPS enforced on all pages. HTTP Strict Transport Security (HSTS) header present. Content Security Policy (CSP) headers blocking inline scripts. All API endpoints requ ire Bearer token authentication. 9.2 Form Validation Software Testing & Quality Assurance | UBTCE311 Pimpri Chinchwad University Harshal | Roll No. E - 10 | Division E | Sem 6 Page N/A Account number field: 11 - digit numeric only. IFSC code: must match pattern [A - Z]{4}0[A - Z0 - 9]{6}. Transfer amount: must be positive, not exceed Rs.10,00,000 per transaction. Invalid inputs show inline err or messages without page reload. TC ID Scenario Expected Result Actual Result Status TC - CBS - W01 Login with correct net banking credentials + valid OTP Dashboard shows account balance, recent transactions, and quick transfer options Dashboard loaded correctly; all widgets populated Pass TC - CBS - W02 XSS attempt in beneficiary name field Input: <script>alert('hack')</script> — sanitized; name displayed as literal text Script not executed; input sanitized Pass TC - CBS - W03 CSRF token validation on fund transfer form Modified CSRF token in POST request Request rejected: '403 Forbidden – Invalid CSRF token' Pass TC - CBS - W04 Session auto - logout after 10 minutes of inactivity Countdown warning shown at 8 minutes; session terminated at 10 minutes; re - login required Session expired as expected; data not accessible without re - login Pass 10. Automation Testing • Automated Scenario 1 – Fund Transfer Regression: Selenium script logs in as customer, navigates to Fund Transfer, enters payee and amount, submits OTP, and asserts success message and transaction ID match expected patterns (TXN - XXXXXXXXX). • Automated Scenar io 2 – Daily Limit Guard: Script performs sequential IMPS transfers incrementally until daily limit is reached, asserting each transaction is accepted until limit and the next is rejected with correct error text. • Automated Scenario 3 – Account Statement Do wnload: Logs in as customer, navigates to Account Statement, selects date range, downloads PDF, and asserts downloaded file exists and has more than 0 bytes. 11. Test Case Design Techniques 11.1 Boundary Value Analysis Transfer amount boundaries: Rs.1 (min imum, valid), Rs.0 (invalid), Rs.10,00,000 (maximum, valid), Rs.10,00,001 (invalid – exceeds limit). OTP validity: 0 minutes (just generated, valid), 4:59 (valid), 5:00 (boundary – system - dependent), 5:01 (expired). 11.2 Equivalence Partitioning Account nu mber: Valid 11 - digit numbers (one test), 10 - digit numbers (one test – invalid), alphanumeric (one test – invalid). Interest rate: Positive non - zero (valid), 0% (boundary – zero interest), negative (invalid). 11.3 State Transition Testing Account states: Ac tive → Frozen → Active → Closed. Each transition tested: active account can transfer; frozen account blocks debit; closed account rejects all transactions. Debit card states: Active → Blocked → Unblocked → Expired — each state transition tested. 12. Defect Reporting Software Testing & Quality Assurance | UBTCE311 Pimpri Chinchwad University Harshal | Roll No. E - 10 | Division E | Sem 6 Page N/A Defect ID Description Severity Priority Status Assigned To DEF - CBS - 001 Balance not updated in real - time on sender's dashboard after IMPS transfer; requires manual refresh Medium P2 – High Fixed – Closed Frontend Dev DEF - CBS - 002 FD premature withdrawal penalty calculated on original principal instead of remaining balance after partial redemption High P1 – Urgent Reopened Backend Dev DEF - CBS - 003 Loan EMI schedule PDF export crashes when loan tenure exceeds 360 months Low P3 – Medium Assigned Backend Dev 13. Conclusion The Core Banking System was tested rigorously across all financial modules. Atomic transaction integrity was confirmed through integration tests that validated rollback mechanisms. Security testing identified and confirmed mitigation of XSS and CSRF vulner abilities. EMI and interest calculation accuracy was validated against standard financial formulas. One high - priority defect related to FD penalty calculation has been reopened and is under resolution. The system passes all critical test cases and is recom mended for controlled UAT with select customer accounts before full deployment. Software Testing & Quality Assurance | UBTCE311 Pimpri Chinchwad University Harshal | Roll No. E - 10 | Division E | Sem 6 Page N/A DOMAIN 3: LIBRARY MANAGEMENT SYSTEM 1. Problem Statement A university library manages over 50,000 books, journals, and digital resources for 8,000 students and 500 faculty members. Current operations rely on a manual card catalog system, leading to difficulties in locating books, tracking issued copies, enforcing return deadlines, and managing fines. The proposed Library Management System (LMS) will digitize cataloging, mem ber management, book issuance, and reservations. This document defines the testing approach to validate the LMS before deployment. 2. Introduction 2.1 Overview The Library Management System is a web - based application supporting book search and discovery, member registration, book issuance and return, reservation queuing, digital resource access, and fine management. It caters to students, faculty, and library sta ff through dedicated interfaces. 2.2 Purpose This document describes the testing strategy, test case design, and defect tracking methodology applied to validate that the LMS delivers accurate, reliable, and user - friendly library services. 2.3 Scope Scope i ncludes Member Management, Catalog Management, Book Issuance/Return, Reservation System, Fine Calculation, Digital Resources, and Admin Reporting modules. 3. Objectives • Verify that the book search returns accurate results using title, author, ISBN, and gen re filters. • Validate that issuance logic respects per - member book limits (students: 3 books; faculty: 10 books). • Ensure fine calculation is accurate based on overdue days and book category. • Test reservation queue: books reserved by next member when returne d. • Confirm that digital resources are accessible only to authenticated members. • Validate admin reports for issued books, overdue notices, and inventory. 4. System Modules • Member Registration Module: Registers students and faculty, assigns member IDs, manages membership renewal. • Catalog Management Module: Maintains book records (ISBN, title, author, genre, copies available), supports CRUD operations. • Book Issuance & Return M odule: Issues books to members, records due dates, processes returns, and updates availability. • Reservation Module: Allows members to reserve unavailable books; notifies automatically when available. • Fine Management Module: Calculates overdue fines per day per book category; records payment status. • Digital Resources Module: Provides access to e - journals, e - books, and research databases via authenticated links. • Admin & Reports Module: Generates inventory reports, overdue lists, most - issued books, and member activity reports. 5. Testing Strategy Testing follows the Agile testing pyramid with extensive unit tests at the base, targeted integration tests at mid - level, and focused system tests at the top. Given the relatively lower security risk compared to bankin g, emphasis Software Testing & Quality Assurance | UBTCE311 Pimpri Chinchwad University Harshal | Roll No. E - 10 | Division E | Sem 6 Page N/A is placed on functional correctness of catalog search, fine calculation accuracy, and reservation queue logic. Performance testing ensures the search catalog responds within 2 seconds for 500 concurrent users. 6. Unit Testing TC ID Description Input Expected Output Actual Output Status TC - LMS - U01 Search book by ISBN ISBN: 978 - 0 - 13 - 468599 - 1 Book: 'The Pragmatic Programmer', Author: Thomas & Hunt, Copies Available: 3 Correct book details returned; 3 copies shown Pass TC - LMS - U02 Search book with title that does not exist Title: 'Quantum Baking Recipes' Result: 'No books found matching your search. Try different keywords.' No results message displayed correctly Pass TC - LMS - U03 Issue book to student within borrowing limit Member: STU - 1042, Books already issued: 2, Book: B - 4521 Book B - 4521 issued; due date 14 days from today; available copies reduced by 1 Issued successfully; due date correct; inventory updated Pass TC - LMS - U04 Issue book to student who has reached borrowing limit (3 books) Member: STU - 1099, Books currently issued: 3, Book: B - 6001 Error: 'Borrowing limit reached. Please return a book before issuing a new one.' Issuance blocked; error shown Pass TC - LMS - U05 Calculate fine for reference book overdue by 5 days Category: Reference Book, Fine rate: Rs.5/day, Overdue: 5 days Fine = Rs.25 displayed on member account Fine Rs.25 calculated and displayed correctly Pass TC - LMS - U06 Return book on time (no fine) Member: STU - 1042, Book: B - 4521, Return date: exactly on due date Book returned; available copies +1; fine = Rs.0; member record updated Return processed; Rs.0 fine; inventory updated Pass TC - LMS - U07 Reserve a book that is currently unavailable (all copies issued) Book: B - 4521, Available copies: 0, Member: STU - 2002 Reservation created; Member STU - 2002 placed at position 1 in queue; estimated wait time shown Reservation created at queue position 1 Pass 7. Integration Testing TC ID Scenario Expected Result Actual Result Status TC - LMS - I01 Member returns reserved book; system notifies first member in reservation queue SMS/email sent to STU - 2002: 'Book B - 4521 is now available for you. Collect by Apr 15, 2026.' Notification sent to STU - 2002 within 5 minutes of return Pass TC - LMS - I02 Admin adds new book copies; catalog availability updated; reserved members notified Catalog shows +3 copies; next 3 members in queue receive availability notifications Inventory updated; notifications sent to 3 queued members Pass TC - LMS - I03 Fine payment processed; member's borrowing privileges restored Member STU - 1099 pays Rs.45 overdue fine; fine status PAID; borrowing limit restored to 0/3 Fine marked PAID; member can issue books again Pass Software Testing & Quality Assurance | UBTCE311 Pimpri Chinchwad University Harshal | Roll No. E - 10 | Division E | Sem 6 Page N/A TC ID Scenario Expected Result Actual Result Status TC - LMS - I04 Librarian deactivates member account; active loans shown before deactivation; new issuances blocked Warning shows 2 books still issued; deactivation proceeds; further book issuance returns 'Account inactive' Active loans listed; deactivation completed; issuance blocked Pass 8. System Testing TC ID Scenario Expected Result Actual Result Status TC - LMS - S01 Complete library usage cycle: Registration → Search → Issue → Use → Return → Fine Payment Student registers, finds book, issues it, returns 3 days late, pays Rs.15 fine, account clear for next issuance All steps completed; fine collected; member record clean Pass TC - LMS - S02 Faculty member accesses digital journal database and downloads research paper Authenticated faculty accesses IEEE Xplore link; paper downloads successfully; access log recorded Paper downloaded; access logged with member ID and timestamp Pass TC - LMS - S03 Admin sends bulk overdue reminder emails to all members with pending returns older than 7 days System identifies 23 overdue members; batch email sent; delivery status logged 23 emails sent; all logged as 'Sent' Pass TC - LMS - S04 Year - end inventory audit: Admin reconciles physical inventory against system records Admin exports inventory report; system shows 50,142 books; discrepancy report highlights 4 missing books Report generated; discrepancies flagged for physical verification Pass 9. Web Application Testing 9.1 UI Testing Book search bar is present and functional on all pages. Search results display book cover thumbnails, availability status (Available/Issued/Reserved), and shelf location. Responsive layout verified on tablet and mobile. 9.2 Form Validation Member ID: alpha numeric, 6 - 10 characters required. ISBN: must be 13 digits (ISBN - 13 standard). Fine payment amount: must be positive numeric value matching outstanding fine exactly. TC ID Scenario Expected Result Actual Result Status TC - LMS - W01 Student login and search for available books by author Search results show matching books with availability status and section/shelf info Results displayed correctly; shelf location shown Pass TC - LMS - W02 Submit reservation form without logging in (unauthenticated) Redirect to login page with message: 'Please login to reserve books' Redirected to login; reservation not created Pass TC - LMS - W03 Admin adds new book with invalid ISBN (12 digits) Form validation error: 'ISBN must be exactly 13 digits' Error shown inline; form not submitted Pass Software Testing & Quality Assurance | UBTCE311 Pimpri Chinchwad University Harshal | Roll No. E - 10 | Division E | Sem 6 Page N/A TC ID Scenario Expected Result Actual Result Status TC - LMS - W04 Check browser back button after logout Back button does not reveal cached member data; redirected to login page Login page shown; no private data visible Pass 10. Automation Testing • Automated Scenario 1 – Book Search & Availability: Selenium script enters an ISBN in the search field and asserts that the correct book title, author, and availability count appear in the results. • Automated Scenario 2 – Book Issuance Flow: Script logs in a s a librarian, searches for a member by ID, selects a book, clicks Issue, and verifies the success message, due date, and reduced copy count. • Automated Scenario 3 – Overdue Fine Calculation: Script sets system date to a future date (simulated), checks a me mber with a known due date, and asserts the displayed fine matches the expected value (days × rate). 11. Test Case Design Techniques 11.1 Boundary Value Analysis Books issued by student: 0 (no books, issuance allowed), 3 (at limit, next issuance blocked), 4 (impossible state – rejection). Fine per day: Rs.1 per day (standard book), Rs.5 per day (reference book) — tested at 1 day, 7 days, 30 days overdue. 11.2 Equiv alence Partitioning ISBN input: Valid 13 - digit number (one test), 12 - digit number (invalid), 13 - character alphanumeric (invalid), empty (invalid). Member categories: Student (limit 3, 14 - day loan), Faculty (limit 10, 30 - day loan) — separate test cases per category. 11.3 Use Case Testing Derived from system use cases: UC - 01 Issue Book, UC - 02 Return Book, UC - 03 Reserve Book, UC - 04 Pay Fine. Each use case tested for normal flow, alternate flow (e.g., book not available), and exception flow (e.g., member limit exceeded). 12. Defect Reporting Defect ID Description Severity Priority Status Assigned To DEF - LMS - 001 Reservation notification email not sent when reserved book is returned after 30 days; notification only sent for returns within 30 days High P1 – Urgent Fixed – Closed Backend Dev DEF - LMS - 002 Fine calculation displays Rs.0 for reference books returned 1 day overdue (off - by - one error in date comparison) Medium P2 – High In Progress Backend Dev DEF - LMS - 003 Search returns duplicate results when book has multiple genres assigned Low P3 – Low Assigned Frontend Dev 13. Conclusion Software Testing & Quality Assurance | UBTCE311 Pimpri Chinchwad University Harshal | Roll No. E - 10 | Division E | Sem 6 Page N/A The Library Management System testing confirmed that core workflows — book issuance, return, reservation queuing, and fine calculation — function correctly across all member categories. Automation testing established a regression suite for 3 critical paths . Two defects were identified affecting fine calculation and reservation notifications, both under active resolution. The system's catalog search performance meets the 2 - second benchmark under simulated load. The LMS is recommended for pilot deployment wit h selected departments pending closure of open defects. Software Testing & Quality Assurance | UBTCE311 Pimpri Chinchwad University Harshal | Roll No. E - 10 | Division E | Sem 6 Page N/A DOMAIN 4: STUDENT / COLLEGE MANAGEMENT SYSTEM 1. Problem Statement A technical university with 15,000 students and 800 faculty members manages admissions, course registrations, attendance, examin ation results, fee collection, and placement activities through disconnected spreadsheets and paper forms. This creates data inconsistencies, delayed result publication, attendance manipulation, and difficulty in academic reporting for accreditation bodies like NAAC and NBA. The proposed Student College Management System (SCMS) will unify all academic and administrative workflows on a single platform. This document describes the testing framework applied to validate the SCMS. 2. Introduction 2.1 Overview The SCMS is an ERP - style web platform covering the complete student lifecycle from admission to graduation. It serves multiple stakeholders: prospective students (admission portal), enrolled students (academic dashboard), faculty (attendance, marks entry), HODs (department reports), and admin (fees, accreditation reports). 2.2 Purpose To define and execute a test strategy that validates the SCMS meets functional requirements, data integrity standards, and performance benchmarks required for a university - sca le deployment. 2.3 Scope Modules in scope: Admissio