QA/Platform/DOM/IndexedDB in Workers

From MozillaWiki
< QA‎ | Platform‎ | DOM
Jump to: navigation, search

Summary

IndexedDB is an API for client-side storage of significant amounts of structured data, which also enables high performance searches of this data using indexes. The intent of the work here is to add this to the Web Worker API, an API that allows creating a background task that can easily send messages back to its parent object. Implementation of this feature is being tracked in bug 701634.

Status

Target Milestone: Firefox 37 (March 31, 2015)
Bugs: 701634 (0 blockers)
Metrics:  ?
Status: [ON TRACK] (In Beta)

People Involved

  • Anthony Hughes (QA)
  • Ben Turner (Developer)
  • Kyle Huey (Code Reviews)

Testing Approach

Risk Profile

  • Where is the spec documented and how can we check to make sure the code is adhering to the spec?
  • What are some of common errors and issues that manual testing should target?
    • None, add automated tests instead
  • What are some of common errors and issues that automated testing is targeting? and where can we find those tests?
  • When filing bugs, how are they to be reported? What component(s) should they go under? What information makes a bug particularly actionable? What keywords, tags, flags, or other verbiage is expected when reporting bugs? What is the criteria for a bug to track a release? What is the criteria for a bug to block a release?
    • Core :: DOM : IndexedDB
  • What is the acceptance criteria for Nightly? Aurora? Beta? Release?
  • How easily can the code be backed out or disabled?
    • Very hard to back out. Can be disabled via pref, see below.
  • What pref(s) exist and how should they be used? How will they change the behavior of the browser? What are their defaults?
    • 'dom.indexedDB.enabled' can be set to false to disable indexedDB in workers (and on the main thread)
  • What other code/features are directly or indirectly affected by the code? What about if the code has to be backed out or pref'd off?
    • No platform code depends on this yet.

Test Cases

Define the test cases required to test this feature/area.

Include which tests can and should be automated, which framework used and how often the should be executed. * Provide link to repository(ies) for automated tests.

  • Smoke
  • Describe basic smoke tests required to prove minimum acceptance
  • Functional
  • List each major functional area to be tested and basic concepts for testing
  • End-to-end User Stories
  • Describe primary use cases
  • Exploratory
  • Describe some related areas and user stories that may be useful to explore

Bug Triage

Document any bug triage meetings and/or processes, including priorities:

  • unconfirmed bugs
  • development bugs
  • fixed bugs
  • regressions
  • tracking bugs
  • blocking bugs

Getting Involved

  • Links to One and Done tasks
  • Links to Moztrap tests
  • Good First Verify in bugzilla
  • Links to any tutorials and other QA introductory material
  • Contact information and Meetings schedules and information on how to join
  • Minimum requirements for becoming involved (Hardware, Software, Skills)
    • Describe the required test environment and provide instructions on how to create it.
    • If special skills are required, provide links to any tutorials that may be available on the subject.
    • If special hardware is required, provide steps on how to verify that the testers systems meet the minimum requirements.