|
|
| Line 1: |
Line 1: |
| = Template = | | = Summary = |
| ; ''To be edited as necessary''
| | ''Provide a brief description of the feature, including links to any relevant documentation or bugs.'' |
|
| |
| == Introduction ==
| |
| ; ''Brief description of the area/feature(s) covered by this document.''
| |
| The primary purpose here is provide enough information about this functional area to a new person that they will be able to achieve a basic understanding of the feature and provide links to the any documentation or engineering docs for further reading is needed. If this is a new feature include which release it is targeted at.
| |
|
| |
|
| == Acceptance Criteria == | | = Status = |
| ; ''Brief description of the minimum acceptance criteria for each branch.''
| | {| |
| * What to do when code is ''not'' riding the trains (ie. verify merged branches do not have the code and that nothing has regressed)
| | |- |
| * What to do when code is riding the trains (ie. verify automation, manual test coverage, metrics in place to qualify)
| | | style="text-align:right" | '''Target Milestone:''' |
| | | ''Firefox version and target release date'' |
| | |- |
| | | style="text-align:right" | '''Bugs:''' |
| | | ''links to key bugs/dependencies (# of blockers)'' |
| | |- |
| | | style="text-align:right" | '''Metrics:''' |
| | | ''links to any metrics'' |
| | |- |
| | | style="text-align:right" | '''Status:''' |
| | | ''current status/branch'' |
| | |- |
| | |} |
|
| |
|
| == Technical Overview == | | = People Involved = |
| ; ''Detailed overview of how the feature is implemented, expected behaviours, and risks/edge-cases.''
| | ''List any people involved and their role on the project.'' |
| | * ''Name (role)'' |
|
| |
|
| == Testing Approach ==
| | = Testing Approach = |
| ; ''High level overview of the testing methodologies used in each type of testing done for this project (Manual and Automated)''
| | == 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? |
|
| |
|
| The purpose of this section is provide guidance on how this area can be tested and what methodologies are most likely to be productive. For example when testing WebRTC the approach for manual testing would be to initiate calls connections between to clients and verify audio and video quality. The automated approach would be to use predictable data sources for audio and video steams allowing you to preform data analysis on the call statistics. Additionally you will want to provide some guidance on what can and can not be tested.
| |
|
| |
| Include:
| |
| * Examples of things to watch for.
| |
| * What are some of common errors and issues that this testing is targeted at finding
| |
| * Filing Bugs
| |
| ** How are bugs reported.
| |
| ** What component(s) should they be filed under
| |
| ** Define keywords, whiteboard tags and other flags or verbage that is expected to be used when reporting bugs
| |
|
| |
| == Get Involved ==
| |
| ; ''How can volunteers and community members become involved in this 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
| |
|
| |
| == Requirements ==
| |
| ; ''What are the 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.
| |
|
| |
| == Related Prefs ==
| |
| ; ''Define any preferences or about:config options that are related to the behavior of this area''
| |
| Describe what pref or option does and what values should be used and how they will change the behavior of the browser. Be sure to include what the default value should be.
| |
|
| |
| == Related Features ==
| |
| ; ''What other features are either directly related too or can be affected by changes made to this feature.''
| |
|
| |
| For instance, changes to the javascript engine can have effects on emscipten and asm.js. WebRTC has dependencies on graphics (Open H.264) and Networking.
| |
|
| |
| == Test Cases == | | == Test Cases == |
| ; ''Define the test cases required to test this feature/area.''
| | ''Define the test cases required, including which tests can/should be automated, framework(s) used, and how often they should be executed.'' |
| 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.
| | * Provide link to repository(ies) for automated tests. |
| * Smoke | | * Smoke |
| * Describe basic smoke tests required to prove minimum acceptance | | * Describe basic smoke tests required to prove minimum acceptance |
| Line 61: |
Line 46: |
| * Exploratory | | * Exploratory |
| * Describe some related areas and user stories that may be useful to explore | | * Describe some related areas and user stories that may be useful to explore |
|
| | |
| == Bug Triage == | | == Bug Triage == |
| Document any bug triage meetings and/or processes, including priorities: | | ''Document any bug triage meetings and/or processes, including priorities:'' |
| * unconfirmed bugs | | * unconfirmed bugs |
| * development bugs | | * development bugs |
| Line 71: |
Line 56: |
| * blocking bugs | | * blocking bugs |
|
| |
|
| == Risks == | | = Getting Involved = |
| ; ''What are the primary areas of risk involved in this area.''
| | ''Provide instructions on the various ways to help with the project.'' |
| For example Graphics has the risk of not being to have a broad enough test bed to provide coverage for edge case testing and may result in unexpected behavior when released to a wider audience.
| | * Links to One and Done tasks |
|
| | * Links to Moztrap tests |
| == Reporting and Status ==
| | * Good First Verify in bugzilla |
| ; ''Describe how are test results reported and provide links to any automated test reports or dashboards.''
| | * Links to any tutorials and other QA introductory material |
| * List milestones and current progress
| | * Contact information and Meetings schedules and information on how to join |
| * Include bug queries for tracked bugs | | * Minimum requirements for becoming involved (Hardware, Software, Skills) |
| * Sign-off status for each release tested. | | ** Describe the required test environment and provide instructions on how to create it. |
| * Metrics to qualify decisions being made. | | ** 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. |