Firefox/Stub Attribution/Test Plan: Difference between revisions
< Firefox | Stub Attribution
Jump to navigation
Jump to search
No edit summary |
|||
| Line 105: | Line 105: | ||
== References == | == References == | ||
* Whiteboard flows/diagrams: | |||
** [https://wiki.mozilla.org/File:Stub-attribution-organic.JPG Organic] | |||
** [https://wiki.mozilla.org/File:Stub-attribution-campaign.jpg Campaign] | |||
* [https://wiki.mozilla.org/Firefox/Stub_Attribution Stub Attribution wiki] | * [https://wiki.mozilla.org/Firefox/Stub_Attribution Stub Attribution wiki] | ||
* [https://docs.google.com/document/d/1H59-4zfw0OAFyqfJw71dI0jD7Z-NLvLyowPw6pNhAVs/edit?ts=56e9d8db Stub Attribution Project Plan] (Google Doc) | * [https://docs.google.com/document/d/1H59-4zfw0OAFyqfJw71dI0jD7Z-NLvLyowPw6pNhAVs/edit?ts=56e9d8db Stub Attribution Project Plan] (Google Doc) | ||
* [https://docs.google.com/document/d/1Y8PYGk6IK19N4-2IqoBK3Eiq9BPc6vV0pfGGiqmYOjM/edit#heading=h.72syj6m0u12d Stub Attribution project's checkin notes] (Google Doc) | * [https://docs.google.com/document/d/1Y8PYGk6IK19N4-2IqoBK3Eiq9BPc6vV0pfGGiqmYOjM/edit#heading=h.72syj6m0u12d Stub Attribution project's checkin notes] (Google Doc) | ||
Revision as of 04:16, 8 November 2016
Stub Attribution Test Plan
Dependencies (tools/systems):
- Firefox client code (Stub Installer)
- Bouncer - GitHub
- Mozilla.org (Bedrock) - GitHub
- Stub Downloader service - GitHub
- Telemetry
- Caveat: Telemetry data lags 3 weeks, even after the switches have been flipped
Acceptance Criteria
In order to begin testing, the following are needed:
Bugzilla query error
Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 406 [1] => Not Acceptable ) ) 1
- a staged or dark-launched Mozilla.org instance ready with Download-button logic and passed-in attribution_code (from bug 1279291), which:
- ...uses the AJAX service to sign Stub-Attribution URLs with a SHA-246 HMAC hash (bug 1278981)
- Bouncer (download.mozilla.org) logic updated to ignore attribution_code for XP users
- Firefox stub installer binaries - PENDING in Firefox 50 builds shipping November 15th - which include the stub attribution_code's post-signing data capability available and pointed to...
- production-ready stubdownloader.prod.mozaws.net service/instance
Open Issues
TODO
- determine what additional test-automation coverage we might need to add to the end-to-end Bouncer tests
Questions:
- How (or can we even?) establish a reasonable performance metric around downloading the stub installer, currently?
- ...so we can measure against this baseline when we test the dynamic vs. cached-downloads Stub-Attribution Service
- All (supported) Windows platforms, or?
- Which IE + Windows versions should get the Stub Attribution (SHA-256)
- By the looks of bug 1304538, IE 6-8 should get SHA-1
- So they're not eligible for this, right?
- By the looks of bug 1304538, IE 6-8 should get SHA-1
- How to test (all five?) codes/fields?
- Source
- Medium
- Campaign
- Content
- "Referrer" alone?
- Which specific browsers (vendors + versions) properly support it/if have it enabled, we'll honor the setting?
- Which locale(s)?
- Entry-points on Mozilla.com. Which page(s)? Or all download pages?
- https://www.mozilla.org/en-US/firefox/all/
- https://www.mozilla.org/en-US/firefox/new/?scene=2 (and do the ?scene=[] parameters matter?)
- Should the attribution code(s) be present on Download buttons when JavaScript is disabled?
- How/who checks the Telemetry ping from the client? Via Dashboard?
- Do we need to cover the upgrade-path scenario? i.e.:
- user downloads and installs using the special stub installer w/tracking code
- we verify correct pings, etc.
- user upgrades later to a newer version of Firefox (pave-over install)
- do we still check for this ping?
- How about the successfully installed, then uninstalled case: check to see that client no longer sends ping?
- Should we test/what should happen in the double-install case? (Install, then install again w+w/o uninstalling the 1st binary.)
- Similarly, what about the a) install stub w/attribution b) upgrade to a later version of Firefox case?
Testing Approaches
Manual Tests:
- Positive (happy-path) Tests:
- Do Not Track disabled
- Click an ad banner or link which has an attribution (source? medium? campaign? content? referrer?) code
- Verify that the URL which takes you to a Mozilla.org download page contains a stub_attcode with a valid param
- Verify that the same valid stub_attcode param/value gets passed to the Mozilla.org Download Firefox button
- Download and install the stub installer
- Verify (how?) that upon successful installation, the stub installer sends a "success!" ping with the same stub_attcode param/value
- Do Not Track disabled
Regression Testing
- All browsers available on Windows XP/Vista (test IE 6, IE 7, Chrome) except for Firefox should still get the SHA-1 stub installer
Negative Testing
- Ensure other installers/binaries don't have/pass on the URL param/stub code
- e.g. Mac, Linux, full Firefox for Windows installers
Performance Testing
Load/Soak Tests
- Against Bouncer
- Against Stub Downloader service
- Tool(s):
- Loads Broker - most likely
- Loads v2?
- Locust?
- Tool(s):
- Against Mozilla.org?
Fuzz/Security Testing
- Purpose:
- Surface potential incorrectly-handled errors (tracebacks/HTTP 5xx, etc.) and potential security issues
- Likely using OWASP ZAP, either manually and/or via the CLI, using Docker/Jenkins
- Against Bouncer
- Against Stub Downloader service
- Against Mozilla.org
Test Automation Coverage:
- What will the Bedrock unit tests cover?
- Where/how frequently will they run? With each pull request/commit/release?
- What will the Bouncer tests cover?
- Where/how frequently will they run? With each pull request/commit/release? On a cron?
References
- Whiteboard flows/diagrams:
- Stub Attribution wiki
- Stub Attribution Project Plan (Google Doc)
- Stub Attribution project's checkin notes (Google Doc)