QA -ETC Payment for Applications with "Payment Due" Status

[rstens]

🧭 Exploratory Testing Charter: Payment for Applications with "Payment Due" Status

🎯 Purpose

Explore the payment flow for applications marked as "Payment Due" to ensure hosts can complete payments smoothly, update application statuses, and handle errors effectively.

---

🔍 Key Areas to Explore

1️⃣ Payment Access and Status Updates

• Trigger: Host accesses an application marked "Payment Due".
• Expected Outcome:
  • Payment Option: Visible only when the application status is "Payment Due".
  • Status Change on Success:
  • Host’s status: Updated from "Payment Due" to "Pending Approval".
  • Examiner’s status: Updated from "Payment Due" to "Paid".
  • Payment confirmation screen displayed upon success.

🌟 Scenarios:

• Payment Available:
  Given the application has "Payment Due" status,
  When the host opens the application,
  Then the system displays the option to make a payment.

• Successful Payment:
  Given the host clicks "Pay Now" and completes the payment,
  Then the system updates the:

  • Host’s status to "Pending Approval".
  • Examiner’s status to "Paid".
  • A payment success confirmation screen is shown.

---

2️⃣ Handling Already Paid Applications

• Trigger: Host views an application that is already paid.
• Expected Outcome:
  • Payment option hidden for non-"Payment Due" applications.
  • Display a message confirming payment has already been made.

🌟 Scenario:

• No Payment Required:
  Given the host views an application not in "Payment Due" status,
  Then the system hides the payment option and shows a message that no further payment is required.

---

3️⃣ Error Handling During Payment Process

• Trigger: Payment gateway returns an error or times out.
• Expected Outcome:
  • The system retains the "Payment Due" status.
  • Prompt the host to try payment again with appropriate messaging.
  • Provide seamless error handling and prevent accidental status changes.

🌟 Scenarios:

• Payment Gateway Failure:
  Given the payment attempt fails or the gateway times out,
  Then the system retains the "Payment Due" status and prompts the host to retry the payment.

---

4️⃣ Payment Receipt and Certificate Download

• Trigger: Host completes payment or views the application details.
• Expected Outcome:
  • Provide a section for the host to download the payment receipt and certificate.
  • Filing history should not be visible to the host.

🌟 Scenarios:

• Receipt and Certificate Download:
  Given the host completes payment,
  When they access the application details,
  Then they can download the payment receipt and certificate.

---

5️⃣ Accessibility Testing

Ensure compliance with accessibility standards for keyboard navigation, screen readers, and low-vision users.

🌟 Scenarios:

• Keyboard Navigation:
  Given a keyboard user navigates the payment process,
  Then all interactive elements are accessible and actionable using Enter/Space.

• Screen Reader Support:
  Given a screen reader user accesses the payment screen,
  Then all content is structured with appropriate labels and headings.

---

6️⃣ Global Usability & Error Management

• Confirm the design behavior when the payment API fails and ensure it matches UX expectations.
• Test for mobile responsiveness and seamless performance.

---

🔑 Business Rules Summary

• Payment Availability:

  • Payment is only available when the application is in "Payment Due" status.
  • Hide the payment option for applications already paid.

• Status Updates:

  • Host’s status changes to "Pending Approval" upon payment.
  • Examiner’s status changes to "Paid" upon payment.

• Error Handling:

  • Retain "Payment Due" status if the payment fails or times out.
  • Provide error messaging and prompt retry.

• Receipt and Certificate:

  • Allow download of payment receipt and certificate.
  • Remove filing history from the host view.

---

🛠️ Exploration Checklist

• [ ] Verify that the "Pay Now" option appears only for "Payment Due" applications.
• [ ] Ensure status updates occur correctly for both host and examiner upon payment.
• [ ] Test the payment confirmation screen upon successful payment.
• [ ] Validate error handling behavior for payment failures and timeouts.
• [ ] Confirm payment option is hidden for non-"Payment Due" applications with appropriate messaging.
• [ ] Ensure hosts can download payment receipts and certificates after payment.
• [ ] Validate accessibility compliance for keyboard, screen reader, and low-vision users.
• [ ] Test mobile responsiveness and seamless payment flow across devices.
• [ ] Verify error messaging design when the payment API fails.

---

🚀 Goal

Ensure a smooth, accessible payment process for hosts with clear status updates, reliable error handling, and easy access to receipts and certificates.

[rstens]

Tester:

• [ ] Done

Session 1: Payment Access and Status Updates

• Focus: Validate that payment options are available only for "Payment Due" applications and confirm accurate status updates post-payment.
• Scope: Ensure the host's status changes to "Pending Approval" and the examiner’s status to "Paid" after successful payment.
• Goal: Confirm smooth payment access with clear status transitions.

Documentation

• Time Spent:
• What did you Test?
• Any Observations You Want to Share?
• Bug Report References:

---

[rstens]

Tester:

• [ ] Done

Session 2: Handling Already Paid Applications

• Focus: Verify that the payment option is hidden for applications already paid and appropriate messages are displayed.
• Scope: Ensure non-"Payment Due" applications correctly show that no further payment is required.
• Goal: Prevent unnecessary payment attempts on applications with "Paid" status.

Documentation

• Time Spent:
• What did you Test?
• Any Observations You Want to Share?
• Bug Report References:

---

[rstens]

Tester:

• [ ] Done

Session 3: Error Handling During Payment Process

• Focus: Test the system's response to payment gateway errors or timeouts.
• Scope: Ensure the "Payment Due" status is retained upon failure, and the host receives a prompt to retry payment.
• Goal: Provide a seamless error-handling experience to prevent accidental status changes.

Documentation

• Time Spent:
• What did you Test?
• Any Observations You Want to Share?
• Bug Report References:

---

[rstens]

Tester:

• [ ] Done

Session 4: Payment Receipt and Certificate Download

• Focus: Confirm that receipts and certificates are available for download after successful payment.
• Scope: Ensure these documents are accessible from the application details view while keeping the filing history hidden from the host.
• Goal: Provide easy access to receipts and certificates for hosts post-payment.

Documentation

• Time Spent:
• What did you Test?
• Any Observations You Want to Share?
• Bug Report References:

---

[rstens]

Tester:

• [ ] Done

Session 5: Accessibility Testing

• Focus: Validate accessibility standards compliance for keyboard navigation, screen readers, and low-vision users.
• Scope: Ensure that all interactive elements are accessible and that content is structured correctly for assistive technologies.
• Goal: Provide an inclusive experience for all users during the payment process.

Documentation

• Time Spent:
• What did you Test?
• Any Observations You Want to Share?
• Bug Report References:

---

[rstens]

Tester:

• [ ] Done

Session 6: Global Usability & Error Management

• Focus: Confirm mobile responsiveness and system behavior during API failures.
• Scope: Test the design’s response to payment API failures, matching UX expectations, and ensure smooth performance on mobile devices.
• Goal: Ensure usability across devices with robust error management.

Documentation

• Time Spent:
• What did you Test?
• Any Observations You Want to Share?
• Bug Report References:

---

[rstens]

Tester:

• [ ] Done

Session 7: Business Rules Validation

• Focus: Validate that payment availability and status updates follow the defined business rules.
• Scope: Confirm that payments are only allowed for "Payment Due" applications and that status changes occur as expected.
• Goal: Ensure the system adheres to all business rules and expectations.

Documentation

• Time Spent:
• What did you Test?
• Any Observations You Want to Share?
• Bug Report References: