Apps/ID and Payments/Test Plan
Contents
- 1 Purpose
- 2 Feature Ownership
- 3 Other Resources
- 4 Testing Scope
- 5 Risk Management
- 6 Testing Lifecycle
- 7 Infrastructure
- 8 Test Case Management
- 9 Automation
- 10 Dogfooding
- 11 Test Data
- 12 Open Questions
- 13 Resources
Purpose
The document intends to provide a high level overview of the testing that's needed for testing the identity flow, the client-side payments implementation, the marketplace payments integration, and other notable areas that affect payments and identity.
Feature Ownership
Feature | QA Lead |
Marketplace Integration | Krupa Raj |
WebPayment Web API and Trustworthy UI | Jason Smith |
Identity | Primary: John Morrison
Secondary: Jason Smith |
Other Resources
Resource | Lead |
Security | Raymond Forbes |
Load Testing and High Availability | Alex, Tarek, Hanno |
Testing Scope
In Scope
Functionality
- All consumer-facing marketplace interactions during payment flow
- All Navigator.mozPay flows, including paid applications and in-app payments
- All trustworthy UI Gaia flows
- All identity flows, including areas inside and outside of marketplace
Software Qualities
- Security testing for any marketplace, trustworthy UI, and identity flow against the known threat model
- Performance testing more to validate user responsiveness throughout the various marketplace, trustworthy UI, and identity flows, especially on slow connections
- Availability and resilience testing for the marketplace payment provider with bango integration to ensure fault tolerance is handled and downtime is minimized
- Localization testing specifically targeting v1 locales to verify that various character sets and text presentation in the various functional flows align with the locale
- Location testing to validate that no surprising problems are seen in the functional flows when operating directly in target countries
Out of Scope
- Mozilla QA team is not responsible for making sure all Bango dataflows work as expected.
- Mozilla QA team is not responsible for making sure all TEF dataflows work as expected.
Risk Management
The open risks are summarized below from a quality perspective.
Rank | Risk | Indicator | Prevention | Mitigation |
1 | Unstable b2g builds halt, regress, or slow down testing of the payments and identity flow | Smoke test bustage on trunk, repeated regressions on payments and identity flow | Automation is in place early and often to ensure regressions are caught before check ins are made to the main tree | Raise awareness quickly when bustage occurs that affects the payment and identity flow and work quickly to get those bugs fixed |
2 | Resource unavailability during the Holiday season | Developers, Testers and Product resources being on PTO around the Holiday season. | Propound atheism to team members | Bake the period of unavailability into our schedule planning |
Testing Lifecycle
Overview
The following section gives an overview of the lifecycle that shall be followed to test the different major pieces involved in this feature set and how it works towards testing the full flow.
Validate the Web Payment API with the Mock Payment Provider
Summary
The first phase of testing aims to ensure that the basic mozPay Web API with the trustworthy UI is setup correctly independently of the marketplace integration. At the end of this phase upon signoff, we should feel confident that major client-side issues related to the mozPay Web API and trustworthy UI are caught and addressed quickly, resulting in this portion of the implementation to be stable as an independent entity.
Status
Test pass completed. Only a couple blocker bug followups and verifications needed before signoff can be completed.
Owner
Jason Smith
Entry Criteria
- Need to be feature complete in the implementation on the web payment API
- Need to be feature complete in the implementation of the trustworthy UI
- Need to have defined user stories that affect trustworthy UI and web payment Web API directly
Exit Criteria
- All basecamp blocking bugs need to be fixed and verified
- Test pass for this phase specifically needs to be ran and not catch any basecamp blocking bugs
Validate the Identity Integration with Trustworthy UI Independently of Marketplace
Summary
The second phase of testing aims to ensure that the identity integration pieces (client and server) work independently of the marketplace-specific flows. At the end of this phase upon signoff, we should feel confident that the persona integration on-device and server side changes have issues caught early and effectively, resulting in the identity pieces being stable independently of the marketplace payment flows.
Status
Ramp-up completed and initial exploratory testing done to understand the feature set. Brainstorming test plan has been done. Currently working on integrating perspectives from identity QA, trustworthy QA, and general b2g QA to facilitate a more disciplined test plan.
Owners
Jason Smith & John Morrison
Entry Criteria
- Need to be feature complete in the on-device changes of the identity DOM and Gaia changes
- Need to be feature complete in the identity server side changes required (e.g. unverified emails)
- Need to be feature complete in the implementation of the trustworthy UI
- Need to have defined user stories that affect trustworthy UI and identity
Exit Criteria
- All basecamp blocker bugs need to be fixed and verified
- A test pass is ran on the DOM ID and trustworthy identity work and finds no basecamp blocker bugs
- A test pass is ran on the identity server side (regression and new feature work) and finds no basecamp blocker bugs
- Gaia smoke tests in relation to identity do not experience bustage for at least one week
- Dogfooding of the identity flow for at least one week reveals no basecamp blocking bugs
Validate the Payments Support on Marketplace
Overview
QA will vet all the Payment userflows for different usertypes : End-user, Developer, App Reviewer and Admins. The aim here is to catch and fix all issues earlier in the development cycle. Tests will be run to ensure that the Marketplace works seamlessly with the client and Identity pieces. We will also ensure that Developer and review centric features are tested and relatively bug-free.
Status
TBD
Owner
Krupa Raj
Entry Criteria
- Feature is testable and has landed on the dev server (marketplace-dev.allizom.org)
- QA has access to relevant test accounts for Bango
- QA is enabled to test on the dev server with fake money
- QA has access to all relevant mocks and specifications docs from UX
- All the necessaries Hardware requirements and SLAs are in place
Exit Criteria
- All basecamp blockers are fixed and verified
- All P1-P3 bugs are fixed and verified
- The entire Payments flow is polished and user-friendly
- All the major user stories have been tested with real money
- All user stories have been implemented/validated
Infrastructure
- Mock payment provider exists to allow testing of the web payment web api and trustworthy UI independently of marketplace
- Various sites making use of persona can be reused to test the identity flow on device
- Marketplace staging server can be used to test the marketplace integration into the client-side payments and identity flow with Bango
Test Case Management
Test cases for each major feature in the payments and identity flow shall be managed in MozTrap. On-device test cases can be found under the B2G product with the tag of payments&id. Marketplace test cases can be found in the Marketplace product with the tag of payments.
Automation
Marionette front-end automation in Gaia is the target for doing automation from the quality side. The automation aims to broken into these distinct areas:
- The web payment api, trustworthy UI, and mock payment provider
- The identity api and trustworthy UI
- The marketplace integration with trustworthy UI
Development repository for these tests can be found here.
Dogfooding
Overview
Dogfooding by b2g test drivers shall be broken into these phases:
- Identity enabled on trunk for persona and trustworthy UI dogfooding
- Marketplace full payments and identity flow with Bango integration with real money
Identity and Trustworthy UI
Summary
Opens the doors to general b2g test drivers to try out the persona integration into Firefox OS with the trustworthy UI. The dogfooding aims to target both general use by test drivers and at least one focused dogfooding session.
Owner
Jason Smith
Dependencies
- Need to be feature complete on identity and trustworthy UI features that existing persona sites already make use of for client and server
- Need to have any dogfooding blockers fixed and verified for client and server
- Need to have a test pass ran to find no dogfooding blockers for client and server
Crowdsourcing in Brazil
Summary
After feature-complete across all components, we would like to have some testing done "out in the wild" - as in, with real money in our target countries. This may include contracting with a Brazilian company or mobilizing our Brazilian community or both. The idea is that they will use Firefox OS phones on the Telefonica carriers with real money and test our Payments flow. Details are still TBD.
Owner
Krupa Raj
Test Data
These are the requisite data for testing the end-to-end payments flow
- Access to Bango test server (?)
- Multiple test credit cards (Visa, Mastercard, Discovery, AMEX)
- SIM cards to test carrier billing (?)
Open Questions
- What infrastructure does Bango have available for QA to take advantage of?
- Is there any payment API that exists for testing with fake money?
Resources
- Apps Id and Payments Landing Page
- FF OS v1 Application Status and Use Cases
- Old Test Plan Notes
- TBD - System Test Plan & Timeline: Blue Via
- TBD - Integration Test Plan & Timeline: Blue Via > Bango