B2G/QA/WebAPI Test Plan/WebPayment

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
• User scenarios and test cases that involve Marketplace's use of nav.mozPay is out of scope in this test plan - see Krupa Raj for more information on the testing approach there

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. invalid response vs. no response on transaction response confirmation
• Successful vs. unsuccessful authentication
• Valid vs. invalid transaction IDs for a refund
• Masquerading as a valid seller, when in reality the seller is not the one to receive the purchase in app X
• Masquerading as a valid buyer, when in reality the buyer is not the one making the purchase from X account
• Replaying of in-app purchase requests and refunds multiple times

Signoff Criteria

• All basecamp blockers are closed
• All smoke tests and basic functional tests are ran without finding any basecamp blockers

Test Case Management

• Test cases themselves will be documented in a spreadsheet referenced below
• For tracking of test case results that do not run a consistent build run, they shall be tracked as references below in spreadsheet form
• For test cases that intend to be ran repeatedly on builds, they shall be tracked in John's global test suite spreadsheet if any of these payment tests become smoke or extended smoke tests for Firefox OS at large (which will likely be the case down the line)

Infrastructure

• A generic test application is going to be needed that allows for various different JWT requests for payments and refunds
• A mock payment provider will be needed to be able to write automation against for this payment API. Additionally, it will be needed probably to help diagnose problems that are in the API vs. BlueVia's side
• Control over the payment provider test server will be needed to be able understand what's going on server side and be able to affect it as needed (e.g. invoke downtime or incorrect values)
• Marketplace dev server will be needed to be used to register apps for testing to produce the public and private keys for in-app payments

Automation

Tracking bug: bug 777023

• Automation is primarily going to target mozPay's use of the mock payment provider
• The trustworthy UI is not being tested in automation, but the events generated to cause the UI alter would be
• My current hunch is that mochitests could probably be used here for automation

Test Cases and Results

Brain dump of ideas for test cases is below. Work in progress.

• Test that I can make an in-app purchase against the mock payment provider
• Test that I can choose and select between two different payments if multiple JWTs are requested
• Test that I receive a phone call while I'm in the trusted UI, that I can complete the phone call and return to the trusted UI context
• Test that I can be notified with a connection failure if there's no connection while I'm in the trusted UI
• Test that I can leave the trusted UI context back to the homescreen
• Test that I can return back to an existing trusted UI context by entering an app in that context currently
• Test that I can see which apps in task manager are in a trusted UI context vs. not
• Test that I can deny an in-app purchase through the trusted UI context
• Test that I can run multiple trusted UI contexts across different apps for different payments
• Test that I can exit to the task switcher while I'm in the trusted UI context
• Test that I can exit to the lockscreen while I'm in the trusted UI context
• Test that I can return to a trusted UI context from the lockscreen
• Test that I can return to a trusted UI context through the task switcher
• Test that I cannot request a trusted UI context within a background page running
• Test that I get an error and no trusted UI context when I request an invalid payment provider (aud wrong)
• Test that I get an error and no trusted UI context when I request an invalid payment provider (typ wrong)
• Test that I get an error and no trusted UI context when I request an invalid payment provider (typ not specified)
• Test that I get an error and no trusted UI context when I request an invalid JWT (exp non-numerical)
• Test that I get an error and no trusted UI context when I request an invalid JWT (iat non-numerical)
• Test that I get an error and no trusted UI context when I request an invalid JWT (iss non-numerical)
• Test that I get an error and no trusted UI context when I request an invalid JWT (request not specified)
• Test that I get an error and no trusted UI context when I request an invalid JWT (name not specified)
• Test that I get an error and no trusted UI context when I request an invalid JWT (price not specified)
• Test that I get an error and no trusted UI context when I request an invalid JWT (price not valid)
• Test that I get an error and no trusted UI context when I request an invalid JWT (invalid currency)
• Test that I get an error and no trusted UI context when I request an invalid JWT (non-numerical price)
• Test that I get an error and no trusted UI context when I request an invalid JWT (non-numerical defaultPrice)
• Test that I get an error and no trusted UI context when I request an invalid JWT (description not specified)
• Test that I get an error and no trusted UI context when I request an invalid JWT (productdata not a valid URL)
• Test that I get an error and no trusted UI context when I request an invalid JWT (productdata not a valid URL)
• Test that I get an error and no trusted UI context when I request an invalid JWT (iat >= exp)
• Test that I get an error and no trusted UI context when I request an invalid JWT (not valid JSON)
• Test that I get an error when I request two JWTs with the same payment provider
• Test that I can make an in-app payment with no iss specified
• Test that I can make an in-app payment with no iat specified
• Test that I can make an in-app payment with no exp specified
• Test that I can make an in-app payment with a single price with no default price specified
• Test that I can make an in-app payment with UTF-8 characters in the name and description of the request
• Test that I can make an in-app payment with at least two prices specified in a valid locale
• Test that I cannot make an in-app payment with a price specified in an unsupported locale
• Test that I can make an in-app payment with two prices specified with a default price, in which the default price is used due to a locale not specified in prices
• Test that I can make an in-app payment with two prices specified with a default price, in which the default price is not used due to a locale already specified in prices