Repository navigation
Software Testing Strategy
This document defines the software testing strategy for SaludVital, a medical appointment management system.
The strategy establishes the testing levels, scope, tools, procedures, and acceptance criteria required to verify that the system meets its functional requirements, protects sensitive information, and maintains the integrity of medical appointment operations.
It serves as a reference for developers and testers throughout the software development lifecycle.
The main objectives of the testing strategy are:
- Verify that the system behaves according to its functional requirements.
- Detect defects before they reach production.
- Validate communication between the frontend, backend, and database.
- Verify authentication, authorization, and access control.
- Ensure the consistency of appointment scheduling, cancellation, and rescheduling.
- Validate error handling and recovery behavior.
- Reduce regressions when new functionality is introduced.
- Establish a consistent process for reporting and resolving defects.
The testing process will follow these principles:
- Early testing: Validate functionality as soon as it becomes available.
- Requirement traceability: Link test scenarios to the corresponding functional requirements.
- Risk-based testing: Prioritize critical workflows, security controls, and medical appointment operations.
- Repeatability: Use documented test cases and controlled test data to obtain reproducible results.
- Isolation: Execute tests in controlled environments without affecting real patient data.
- Regression prevention: Re-execute relevant tests after code changes and defect fixes.
- Evidence-based acceptance: Consider functionality verified only when the required tests have been executed and their results reviewed.
The testing strategy covers the following areas:
- User registration and authentication.
- Role-based access control.
- Patient and doctor management.
- Doctor availability management.
- Appointment scheduling.
- Appointment cancellation and rescheduling.
- Appointment history and authorized information access.
- Administrative operations.
- Notification processing.
- WhatsApp-based appointment management, where implemented.
- Database integrity and transaction consistency.
- Error handling and application reliability.
The exact tests and their implementation status will depend on the functionality available in the current version of SaludVital.
The testing process will use several complementary levels.
Unit tests verify individual functions, methods, and components in isolation.
Examples:
- Registration input validation.
- Authentication and authorization rules.
- Appointment eligibility rules.
- Date and time validation.
- Notification processing logic.
Integration tests verify that related components work correctly together.
Examples:
- Backend services communicating with the database.
- Authentication middleware protecting routes.
- Appointment operations persisting data correctly.
- Notification services interacting with configured providers.
API tests verify endpoint behavior, request validation, response structures, HTTP status codes, and error handling.
Tests should cover valid requests, invalid input, unauthorized requests, missing resources, and unexpected failures.
Functional tests verify that the implemented features meet their specified requirements.
Each test must define its preconditions, input data, execution steps, and expected result.
End-to-end tests validate complete user workflows across the application's relevant components.
Examples include registering an account, scheduling an appointment, and viewing or canceling an eligible appointment.
Security tests verify authentication, authorization, access restrictions, input handling, and protection against exposure of sensitive information.
Database tests verify relationships, constraints, uniqueness, transaction behavior, and the consistency of stored data.
Regression tests verify that previously working functionality remains correct after code changes, defect fixes, and feature integration.
Performance and reliability tests evaluate response times, behavior under expected workloads, and the application's handling of failures.
Specific performance thresholds must be defined when supported by the project's requirements and deployment environment.
Tests must run in a controlled development or testing environment.
The testing process should:
- Use a dedicated test database or isolated test data.
- Avoid real patient information.
- Store credentials and environment secrets securely.
- Prepare reproducible test cases for users, roles, doctors, and appointments.
- Prevent automated tests from sending unintended real notifications.
- Reset or clean up test data when necessary.
Testing tools will be selected according to the technologies used in the SaludVital project.
The proposed tools include:
- Jest: Unit testing for JavaScript functions, business logic, and backend components.
- Supertest: HTTP endpoint testing for the Node.js and Express backend.
- Postman: Manual API testing, request validation, and verification of HTTP responses.
- Pug and HTML: The rendered pages and user interface will be verified through functional and integration tests, including form validation, navigation, and user interactions.
- GitHub Actions: Automated test execution through continuous integration, if configured.
The testing tools must be configured according to the project's actual dependencies and architecture.
Listing a tool in this document does not mean it has already been installed or configured.
This matrix identifies the main test scenarios required to validate SaludVital's critical functionality.
The scenarios define expected behavior. Their inclusion in this matrix does not mean that the corresponding tests have already been implemented or executed.
| ID | Area | Test Scenario | Expected Result | Priority |
|---|---|---|---|---|
| TC-01 | Registration | Submit valid registration data | The account is created successfully. | High |
| TC-02 | Registration | Submit invalid or incomplete data | The request is rejected and validation feedback is provided. | High |
| TC-03 | Registration | Register using an existing account identifier | The system prevents duplicate registration according to the applicable uniqueness rules. | High |
| TC-04 | Authentication | Sign in with valid credentials | The user is authenticated and receives the appropriate response. | High |
| TC-05 | Authentication | Sign in with invalid credentials | Access is denied and an appropriate error response is returned. | High |
| TC-06 | Authorization | Access a protected resource without authentication | Access is denied. | Critical |
| TC-07 | Authorization | Access a resource without the required role or permission | Access is denied. | Critical |
| TC-08 | Appointments | Schedule an appointment in an available time slot | The appointment is created and stored correctly. | Critical |
| TC-09 | Appointments | Schedule an appointment in an unavailable time slot | The system rejects the conflicting appointment request. | Critical |
| TC-10 | Appointments | Reschedule an eligible appointment with the same doctor | The appointment is updated only if the requested slot remains available and the applicable rules are satisfied. | Critical |
| TC-11 | Appointments | Cancel an appointment according to the applicable cancellation rules | The appointment status is updated correctly and its history is preserved. | High |
| TC-12 | Appointments | Reschedule an appointment when the requested slot is no longer available | The operation is rejected without corrupting the existing appointment. | Critical |
| TC-13 | Doctor Availability | Update a doctor's availability | The new availability is stored and subsequent scheduling operations respect it. | High |
| TC-14 | Database | Attempt to store data that violates a database constraint | The invalid operation is rejected and data integrity is preserved. | Critical |
| TC-15 | Notifications | Process an appointment notification request | The notification is processed according to the configured notification workflow. | High |
| TC-16 | Notifications | Simulate an external notification provider failure | The failure is handled according to the notification retry and error-handling design. | High |
| TC-17 | Submit an appointment request through WhatsApp | The request is processed according to the configured integration and appointment rules. | High | |
| TC-18 | Error Handling | Simulate a backend or database failure | The system handles the failure without exposing sensitive technical information or corrupting data. | High |
Each test case must define, as applicable:
- Preconditions and required user roles.
- Test input and data setup.
- Execution steps.
- Expected result.
- Actual result.
- Execution status: Not Run, Passed, or Failed.
- Evidence or defect reference when necessary.
Appointment-related tests must verify the business rules defined in the functional requirements, including appointment eligibility, doctor availability, prevention of conflicting bookings, and consistency of appointment history.
Tests involving WhatsApp and notification providers must distinguish between application logic and external provider behavior.
Specific rules must be taken from the approved functional requirements rather than inferred from this matrix.
Testing may begin when the following conditions are satisfied:
- The functionality or requirement to be tested has been identified.
- The expected behavior and acceptance criteria are defined.
- The code required for the test is available in the testing environment.
- The test environment and required dependencies are configured.
- Suitable test data is available.
- The relevant test cases have been reviewed.
- Required external services are available in a test configuration or can be safely simulated.
If any required condition is not satisfied, the limitation must be documented before testing proceeds.
Testing for a feature may be considered complete when:
- All mandatory test cases for the feature have been executed.
- Test results have been recorded and reviewed.
- All critical test cases have passed.
- No unresolved critical or high-severity defects remain unless an explicit exception has been approved and documented.
- Relevant regression tests have passed.
- Security and authorization requirements have been verified where applicable.
- Database consistency has been verified for operations that modify persistent data.
- Known limitations and outstanding defects have been documented.
A feature must not be considered fully verified solely because its code has been implemented.
When a test fails:
- Record the actual result and compare it with the expected result.
- Document the steps required to reproduce the failure.
- Create or update a defect report.
- Investigate and correct the underlying problem.
- Execute the failed test again after the correction.
- Run related regression tests to verify that the correction has not introduced new defects.
A failed test must not be marked as passed without evidence that the expected behavior has been achieved.
Test execution results must be documented to provide visibility into the quality and verification status of SaludVital.
Each test execution report should include:
- Test case identifier and description.
- Requirement or functionality being validated.
- Test environment and execution date.
- Test status: Passed, Failed, Blocked, or Not Run.
- Expected and actual results.
- Evidence, logs, or screenshots when applicable.
- Related defect or issue references.
- Name or identifier of the person responsible for execution, when applicable.
Test reports must accurately reflect the tests that have actually been executed. Planned tests must not be reported as completed.
The following metrics may be used to evaluate testing progress and identify areas requiring additional attention.
| Metric | Description |
|---|---|
| Test Execution Progress | Percentage of planned test cases that have been executed. |
| Test Pass Rate | Percentage of executed test cases that passed. |
| Test Failure Rate | Percentage of executed test cases that failed. |
| Requirement Coverage | Percentage of identified requirements covered by at least one test case. |
| Defect Count | Number of defects identified during testing, grouped by severity when possible. |
| Regression Test Results | Results of regression tests executed after code changes or defect fixes. |
The metrics should be calculated using the following formulas:
Test Execution Progress
Executed test cases divided by total planned test cases, multiplied by 100.
Test Pass Rate
Passed test cases divided by total executed test cases, multiplied by 100.
Test Failure Rate
Failed test cases divided by total executed test cases, multiplied by 100.
Requirement Coverage
Requirements covered by at least one test case divided by total identified requirements, multiplied by 100.
Blocked and not-run tests must be reported separately. The report must state the denominator used for each metric.
Test results should be reviewed during feature validation and before significant integrations or releases.
The team should use the results to:
- Identify critical failures and unresolved defects.
- Determine whether additional testing is required.
- Track progress against the planned test scope.
- Identify requirements without test coverage.
- Support evidence-based decisions about feature acceptance.
No metric alone is sufficient to establish software quality. Results must be interpreted alongside defect severity, business risk, and the acceptance criteria.
The standard testing workflow is:
- Identify the requirement or functionality to validate.
- Define test scenarios and expected results.
- Prepare the test environment and data.
- Execute the relevant tests.
- Record the results and supporting evidence.
- Report defects with reproduction steps and severity.
- Correct the identified defects.
- Re-run the affected tests.
- Execute relevant regression tests.
- Review the results before accepting the functionality.
Automated tests should be developed for critical business logic, API endpoints, authentication, authorization, and appointment management rules.
The proposed testing tools are:
- Jest: Execute automated JavaScript unit tests.
- Supertest: Validate HTTP endpoints in the Node.js and Express backend.
- Postman: Support manual API validation and automated request collections where appropriate.
Frontend tests should verify rendered HTML/Pug pages, form validation, navigation, and user-visible responses using tools compatible with the project's actual implementation.
GitHub Actions may be configured to execute automated tests when code is pushed or a pull request is opened.
A proposed workflow should:
- Install project dependencies.
- Configure the required test environment.
- Execute the available automated test suites.
- Report failures to the development team.
- Prevent a successful test result from being reported when required tests fail.
The workflow must use the project's actual scripts and configuration. It must not depend on tests or tools that have not been implemented or installed.
Automation should prioritize:
- Authentication and authorization.
- Registration validation.
- Appointment scheduling and conflict prevention.
- Appointment cancellation and rescheduling rules.
- Database transaction consistency.
- Error handling for critical operations.
External notification providers should be mocked or tested in a dedicated environment to prevent unintended messages during automated execution.
This section defines the proposed automation strategy. Automated tests and continuous integration must be reported as implemented only after their configuration and execution have been verified.
Each identified defect should include:
- A descriptive title.
- Steps to reproduce the issue.
- Expected behavior.
- Actual behavior.
- Environment and relevant test data.
- Severity and priority.
- Supporting logs, screenshots, or other evidence when available.
A defect should be considered resolved only after the correction has been reviewed and the relevant test has passed.
A feature may be considered ready for acceptance when:
- Its required test cases have been executed.
- Expected results have been verified.
- No unresolved critical defects remain.
- Relevant security and authorization checks have passed.
- Database consistency has been verified where applicable.
- Required regression tests have passed.
- Test results and outstanding limitations have been documented.
Additional acceptance conditions may be established for individual features according to their risks and requirements.
This strategy must be reviewed when significant changes are introduced to the system architecture, technology stack, functional requirements, or testing process.
New critical defects and lessons learned from testing should be used to improve the test suite and testing procedures.
The Software Testing Strategy establishes a consistent approach to verifying the quality, security, reliability, and correctness of SaludVital.
It provides a foundation for designing test cases, prioritizing critical functionality, managing defects, and evaluating whether implemented features satisfy their requirements.