QA/Platform/DOM/Feature Testplan Template

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

Summary

Provide a brief description of the feature, including links to any relevant documentation or bugs.

Status

Target Milestone: Firefox version and target release date
Bugs: links to key bugs/dependencies (# of blockers)
Metrics: links to any metrics
Status: current status/branch

People Involved

List any people involved and their role on the project.

  • Name (role)

Testing Approach

Risk Profile

Describe the risks that exist in the project area and how those risks are mitigated.

  • 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?
  • 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?
  • What is the acceptance criteria for Nightly? Aurora? Beta? Release?
  • How easily can the code be backed out or disabled?
  • What pref(s) exist and how should they be used? How will they change the behavior of the browser? What are their defaults?
  • 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?

Test Cases

Define the test cases required, including which tests can/should be automated, framework(s) used, and how often they 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

Provide instructions on the various ways to help with the project.

  • 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.