Admin Payment Link Generation: A Comprehensive Test Plan
This document outlines a comprehensive test plan for the new admin payment link generation feature, designed to ensure its reliability and functionality before merging PR #2g. This feature is crucial as it empowers administrators to generate Stripe checkout links specifically tailored for Mahad students, streamlining the payment process. This article will guide you through the necessary steps, prerequisites, and expected outcomes, ensuring a smooth and efficient testing experience.
Overview of the Admin Payment Link Generation Feature
The admin payment link generation feature is a critical addition to our system, enabling administrators to easily create and distribute payment links to Mahad students. This streamlines the payment collection process and ensures accurate billing. To guarantee the feature's reliability and usability, we've developed this comprehensive test plan. It covers various scenarios, from happy path cases to error conditions and edge cases, ensuring that all aspects of the feature are thoroughly tested.
Before diving into the specifics, it's important to understand the core functionality. The feature allows admins to generate unique Stripe checkout links for students directly from the admin panel. These links are pre-configured with the student's billing information, reducing manual effort and minimizing the risk of errors. This feature is particularly useful for managing student payments, tracking payment status, and ensuring timely collections.
The primary goal of this test plan is to validate that the feature works as expected under various conditions. This includes verifying the accuracy of payment amounts, ensuring proper handling of different student billing configurations, and confirming that error messages are displayed appropriately when issues arise. Additionally, accessibility testing is a key component to ensure the feature is usable by everyone, regardless of their abilities.
By following this test plan, we aim to identify and resolve any potential issues before the feature is deployed to the live environment. This proactive approach ensures a seamless experience for both administrators and students, contributing to the overall efficiency of our payment management system. Remember, a well-tested feature is a reliable feature, and this is what we strive for.
Prerequisites for Testing
Before initiating the tests, it is crucial to ensure that the necessary prerequisites are in place. This includes setting up the local development environment and configuring the Stripe test mode. These steps are essential for simulating the production environment and verifying the feature's functionality without affecting live data. To effectively test the admin payment link generation feature, you'll need to meet the following prerequisites:
- Local Dev Server Running (
npm run dev): Ensure that your local development server is up and running. This environment will serve as the platform for testing the feature in isolation, allowing you to identify and resolve any issues without impacting the production environment. Running the development server ensures that you have access to the latest code and can simulate the actual user experience. - Stripe Test Mode Configured: Stripe test mode must be properly configured to simulate payment processing without real transactions. This involves setting up a Stripe test account and configuring the necessary API keys in your local environment. Stripe's test mode provides a safe and controlled environment for testing payment integrations, allowing you to verify that the payment links generate correctly and that transactions are processed as expected.
- At Least 3 Test Students in Database: You need to have at least three test students in your database, each with different billing configurations. This variety will help you cover a wide range of scenarios and ensure that the feature handles different student profiles correctly. The three test students should include:
- One with a complete billing configuration (graduation status, payment frequency, and billing type set).
- One with an EXEMPT billing type.
- One with an incomplete or missing billing configuration.
These prerequisites ensure that you have a stable and realistic testing environment, enabling you to thoroughly evaluate the admin payment link generation feature and identify any potential issues before it is deployed to production.
Test Cases for Admin Payment Link Generation
The following test cases will guide you through a comprehensive evaluation of the admin payment link generation feature. Each test case focuses on a specific scenario, covering both successful operations and potential error conditions. By systematically working through these cases, you can ensure that the feature functions correctly under various circumstances. These test cases are designed to cover a broad spectrum of scenarios, ensuring the admin payment link generation feature is robust and reliable.
1. Happy Path - Student Detail View
This test case verifies the successful generation of a payment link for a student with a complete billing configuration. It represents the ideal scenario where all prerequisites are met, and the feature should function flawlessly. This is the most common use case, so itโs crucial to ensure this path works seamlessly.
Steps:
- Navigate to
/admin/mahad/cohorts. - Click on any student row to open the detail modal.
- Click the "Payment Link" button in the header.
- In the dialog, click "Generate Payment Link."
- Wait for link generation.
- Click the copy icon next to the URL.
- Open a new incognito/private browser tab.
- Paste and navigate to the URL.
Expected Results:
- [ ] Dialog opens with the student's name in the description.
- [ ] The "Generate Payment Link" button shows a loading state during generation.
- [ ] After generation, the calculated amount displays correctly (e.g., "$120.00/month").
- [ ] A URL field appears with the Stripe checkout URL.
- [ ] The copy button shows a green checkmark after clicking.
- [ ] A toast notification appears: "Payment link copied to clipboard."
- [ ] The URL opens a valid Stripe checkout page with the correct amount.
Screenshot locations: Capture screenshots of the dialog before generation, the dialog after generation, and the Stripe checkout page. These screenshots will serve as visual evidence of the test results.
2. Error Case - EXEMPT Student
This test case focuses on handling students with an EXEMPT billing type. Exempt students should not have payment links generated, and the system should display an appropriate error message. This ensures that the system correctly handles edge cases and prevents unintended payment setups.
Steps:
- Navigate to
/admin/mahad/cohorts. - Find a student with the EXEMPT billing type (or edit one to be EXEMPT).
- Open the student detail modal.
- Click the "Payment Link" button.
- Click "Generate Payment Link."
Expected Results:
- [ ] An error alert appears with red styling.
- [ ] The error message displays: "Exempt students do not need payment setup."
- [ ] No URL field is shown.
- [ ] A "Done" or "Cancel" button is available to close the dialog.
3. Error Case - Incomplete Billing Config
This test case checks the system's behavior when attempting to generate a payment link for a student with an incomplete billing configuration (missing graduation status, payment frequency, or billing type). The system should identify the incomplete information and provide guidance on how to resolve it. This is crucial for maintaining data integrity and preventing billing errors.
Steps:
- Find or create a student with missing billing config (no graduation status OR no payment frequency OR no billing type).
- Open the student detail modal.
- Click the "Payment Link" button.
- Click "Generate Payment Link."
Expected Results:
- [ ] An error alert appears with red styling.
- [ ] The error message mentions the incomplete billing configuration.
- [ ] A "Review billing details" button appears below the error message.
- [ ] Clicking "Review billing details" navigates to the edit page.
4. Quick Action - Table Dropdown (With Defaults)
This test case examines the quick action functionality, where payment links can be generated directly from the student table using default configurations. This streamlines the process for common scenarios and reduces the number of steps required to generate a link. This test ensures that the default configurations are applied correctly and that the database is updated accordingly.
Steps:
- Navigate to
/admin/mahad/cohorts. - Find a student row (any billing config status).
- Click the three-dot menu (โฎ) in the Actions column.
- Select "Generate payment link."
- In the dialog, click "Generate Payment Link."
Expected Results:
- [ ] The dialog opens for the correct student.
- [ ] The link generates successfully (applies default config: NON_GRADUATE, FULL_TIME, MONTHLY).
- [ ] The amount shown should be $120.00/month (default full-time non-graduate rate).
- [ ] After closing, verify the student's billing config was updated in the database:
graduationStatus: NON_GRADUATEbillingType: FULL_TIMEpaymentFrequency: MONTHLY
Verify in Prisma Studio or database:
SELECT graduation_status, billing_type, payment_frequency
FROM program_profile
WHERE id = '<profile_id>';
5. Accessibility Testing
Accessibility testing is a critical component of ensuring that the admin payment link generation feature is usable by everyone, including individuals with disabilities. This test case focuses on keyboard navigation and screen reader compatibility, ensuring that the feature adheres to accessibility standards. This test ensures that the feature is inclusive and can be used by all users, regardless of their abilities.
Keyboard Navigation:
- Open the Payment Link dialog.
- Press Tab repeatedly.
- [ ] Focus moves through: Generate button โ Close/Cancel button.
- [ ] After generation, focus order: Copy button โ Open Link button โ Done button.
- [ ] Escape key closes the dialog.
- [ ] Enter on the Generate button triggers generation.
Screen Reader (VoiceOver on Mac / NVDA on Windows):
- Enable the screen reader.
- Open the Payment Link dialog.
- Navigate through elements.
- [ ] The dialog title is announced: "Payment Link."
- [ ] The description is announced with the student's name.
- [ ] The Copy button announces "Copy link" (or "Copied" after clicking).
- [ ] The amount is announced with currency and period.
6. Edge Cases
Edge cases represent unusual or extreme conditions that can potentially expose vulnerabilities in the system. This test case focuses on verifying rate calculation accuracy for different student configurations and ensuring the system handles multiple link generations correctly. This ensures that the feature is robust and can handle a wide range of scenarios.
Rate Calculation Verification:
| Graduation Status | Payment Frequency | Billing Type | Expected Amount |
|---|---|---|---|
| NON_GRADUATE | MONTHLY | FULL_TIME | $120.00/month |
| NON_GRADUATE | BI_MONTHLY | FULL_TIME | $220.00/2 months |
| GRADUATE | MONTHLY | FULL_TIME | $95.00/month |
| GRADUATE | BI_MONTHLY | FULL_TIME | $180.00/2 months |
| NON_GRADUATE | MONTHLY | PART_TIME | $60.00/month |
| NON_GRADUATE | MONTHLY | FULL_TIME_SCHOLARSHIP | $90.00/month |
- [ ] Test at least 3 different configurations and verify amounts match.
Multiple Link Generation:
- Generate a payment link for Student A.
- Close the dialog.
- Re-open the dialog for the same student.
- Generate again.
- [ ] A new link is generated successfully (different session ID).
- [ ] The old link still works (Stripe sessions valid for 24h).
Regression Testing for Payment Link Generation
Regression testing is crucial to ensure that the new admin payment link generation feature does not negatively impact existing functionalities. This involves re-testing previously verified features to confirm they continue to work as expected after the new feature has been integrated. This proactive approach helps prevent unintended side effects and ensures the overall stability of the system.
The following aspects should be included in the regression testing:
- [ ] Student table still loads correctly.
- [ ] Student detail modal opens/closes properly.
- [ ] Edit functionality still works.
- [ ] Delete student functionality unaffected.
- [ ] Other admin pages load without errors.
By performing these regression tests, we can confidently confirm that the new feature integrates seamlessly with the existing system and does not introduce any regressions.
Sign-off
The sign-off section provides a structured way to document the results of each test case. It includes a table where testers can record whether each test case passed or failed, along with any relevant notes. This ensures accountability and provides a clear overview of the testing progress.
| Test Case | Tester | Pass/Fail | Notes |
|---|---|---|---|
| 1. Happy Path | |||
| 2. EXEMPT Error | |||
| 3. Incomplete Config Error | |||
| 4. Quick Action with Defaults | |||
| 5. Accessibility | |||
| 6. Edge Cases | |||
| Regression |
Related Resources
This section provides links to relevant resources, such as the pull request, feature documentation, and files changed. This ensures that testers have easy access to all the information they need to understand the feature and its implementation. For further information and context, refer to the following:
- PR: #2g (pr2g-mahad-payment-flow)
- Feature: Admin Payment Link Generation
- Files changed:
app/admin/mahad/cohorts/_actions/index.tsapp/admin/mahad/cohorts/_components/students/payment-link-dialog.tsx(NEW)app/admin/mahad/cohorts/_components/students/student-columns.tsxapp/admin/mahad/cohorts/_components/students/student-details-content.tsx
By following this comprehensive test plan, you can ensure that the admin payment link generation feature is thoroughly tested and ready for deployment. Remember to document your findings and collaborate with the development team to address any issues promptly.
In conclusion, testing the admin payment link generation feature thoroughly using this detailed plan will ensure its reliability and efficiency. By addressing various scenarios, from happy paths to edge cases, we guarantee a smooth user experience and maintain data integrity. Don't forget to explore additional resources on Stripe's official documentation for a deeper understanding of payment processing and API integration.