B2G/QA/WebAPI Test Plan/WebPayment
< B2G | QA | WebAPI Test Plan
Jump to navigation
Jump to search
WebPayment
Summary
Lead | Jason Smith (irc: jsmith) |
API Description | Allows for monetary payments for a virtual good |
API Developer | Fernando Jimenez Moreno |
API Project Page | WebPayment |
API Tracking Bugs | Bug 767818 |
API Status | Landed |
Strategy
- API testing to ensure the JS API handles general valid and invalid input cases with the right success/error callbacks
- JWT generation testing to analyze the different values allowed to be used in calling nav.mozPay and its resulting effects
- End-to-End functional testing with mozPay and trustworthy UI - Ensure that end to end flows integrating across BlueVia, Marketplace, and Firefox OS fit together as a whole
- Availability and Resilience end-to-end testing - Many distributed components are involved in the web payments in mozPay, so we should be able downtime of a component or problems that a component in the process generates gracefully
- Penetration Testing - There's trust on identification, receipt expiration, etc involved here, so we'll need to test for risks that could occur in any of those factors
Edge Cases
- Multiple payments chained together
- Different payment providers (i.e. JWT typ), valid vs. invalid
- Payment Provider Server Downtime or Failure
- Invalid JWT requests
- Switching app contexts post the call of mozPay
- Interception and altering of content to be rendered within trustworthy UI chrome
- Valid vs. invalid application keys
- Expired vs. Non-Expired Payment Requests and Refunds
- Different country codes
- Different locale text with JWT request
- Optional vs. required parameters for JWT request
- Default pricing vs. locale-specific pricing
- Different country currencies
- Completed vs. Canceled Purchases
- Marketplace Server Downtime or Failure
- Registered application for in-app payments vs. non-registered
- Valid vs. invalid postback and chargeback URLs on successful payments and refunds
- Default price vs. no default price
- Valid vs. invalid amounts
- Application server response vs. no response on transaction response confirmation
- Successful vs. unsuccessful authentication
- Valid vs. invalid transaction IDs for a refund
Signoff Criteria
- All basecamp blockers are closed
- All smoke tests and basic functional tests are ran without finding any basecamp blockers
Test Case Management
Infrastructure
Automation
Smoke Tests
Basic Functional Tests
Exploratory Tests
Open Questions
- Does the trustworthy UI provide any context of where the HTML 5 content served inside the UI is from? In other words, how do I know the content I've received is safe or not? Is the URL of the content shown in the trustworthy UI to mitigate this?
- How exactly does the identity pieces affect the in-app payments flow? I've noticed it's stated it's the responsibility of the "payment provider" - from the context of mozPay, is that a black box then?
- What's the purpose of productdata? How does it affect the in-app purchase?
- How exactly does the application server send the 200 OK with the order ID back to the payment provider?