QA/Date Time Input Types
Revision History
This section describes the modifications that have been made to this wiki page. A new row has been completed each time the content of this document is updated (small corrections for typographical errors do not need to be recorded). The description of the modification contains the differences from the prior version, in terms of what sections were updated and to what extent.
| Date | Version | Author | Description |
|---|---|---|---|
| 08/02/2016 | 1.0 | Cynthia Tang | Initial draft |
Overview
Purpose
Detail the purpose of this document. For example:
- The test scope, focus areas and objectives
- The test responsibilities
- The test strategy for the levels and types of test for this release
- The entry and exit criteria
- The basis of the test estimates
- Any risks, issues, assumptions and test dependencies
- The test schedule and major milestones
- The test deliverables
Scope
This wiki details the testing that will be performed for Date/Time Input Types project. It defines the overall testing requirements and provides an integrated view of the project test activities. Its purpose is to document:
- What will be tested
- How testing will be performed
Ownership
Engineering Program Manager: Wesley Huang
Engineers: Jessica Jong(platform: DOM/layout part), Scott Wu (front-end: xul element/html content)
UX Designers: Morpheus Chen, Tina Hsieh
Visual designer: Helen Huang
TDC QA: Cynthia Tang, William Hsu
QA:
Rares Bologa - PM for QA team
Testing summary
Scope of Testing
In Scope
This project is to enable the feature on Desktop that HTML input fields should contain a date or time or allow users to select a week in a year.
The project aims to provide basic input/pickers (date, month, time, date time, and week) for web authors and at the same time to meet HTML standard criteria including "Preset Value", "Preset List", "Step", and "Max/Min".
Other than the functions listed above, the project shall also take care of localization (incl. the different format per locale) and accessibility (Input = Cursor Only, Cursor+Keyboard, or Keyboard only). RTL currently is not in the scope.
Last but not least, as per the current scope, only Gregorian calendar is considered.
The scope of our testing is the Date/Time Input Types and its functionality. The testing effort for Date/Time Input Types will be invested on the following areas:
- Release Acceptance testing
- Compatibility testing - Backward compatibility
- Continuous integration
- Destructive testing (Forced-Error Test)
- Functional vs non-functional (Scalability or other performance) testing
- Performance testing
- Regression testing
- Usability testing
Out of Scope
Following areas/features are considered out of scope and will not be considered as testing zones to be handled in this test plan.
- Accessibility testing (UX will deal with it)
- L10N test (L10n team will deal with it)
- Scan security hole (Security team will deal with it. If any patches exist security concern, we will add "sec-review" flag on the bug)
Requirements for testing
Environments (TBC)
Testing will be performed on following OSes:
- Windows XP (x32)
- Windows Vista (x32 & x64)
- Windows 7 (x32 & x64)
- Windows 8.1 (x32 & x64)
- Windows 10 (x32 & x64)
- Ubuntu 14.04 (x32 & x64)
- Ubuntu 15.04 (x32 & x64)
- Fedora 23 (x64)
- Mac OS X 10.9
- Mac OS X 10.10
- Mac OS X 10.11
Test Strategy
Test Objectives
This section details the progression test objectives that will be covered. Please note that this is at a high level. For large projects, a suite of test cases would be created which would reference directly back to this master. This could be documented in bullet form or in a table similar to the one below.
| Ref | Function | Test Objective | Evaluation Criteria | Test Type | Owners |
|---|---|---|---|---|---|
| 1 | Install Activity stream add-on | Verify that the add-on is correctly installed | Add-on UI changes are present in the browser | Manual | Eng Team |
| 2 | Timeline functionality and content | Verify all Timeline tab options and related pages content | 1. Open the activity stream tab 2. Check "All" page content 3. Check "Bookmarks" page content 4. Check "Downloads" page content 5. Check "Tabs" page content 6. Check Search (Filter) functionality and other Timeline associated features |
Manual | Eng Team |
| 3 | New Tab functionality and content | Verify that Activity Stream content is displayed in a new tab | Activity stream user content is displayed in each new tab opened | Manual | Eng Team |
| 4 | Bookmarks & history | Verify that profile / account bookmarks and history are correctly imported in the add-on | All the previous stored data is displayed on the add-on pages | Manual | Eng Team |
| 5 | Share functionality | Verify that Activity Stream content can be saved and shared | 1. Access the "Share" menu 2. Save page to pocket, share page trough most common services and system share services 3. Manage services |
Manual | Eng Team |
| 6 | Awesomebar | Verify the changes implemented on the Awesomebar for the Activity Stream add-on | TBD | Manual | - |
| 7 | Disable / Re-enable Activity Stream add-on | Verify that the add-on can be disabled and enabled without any issues | 1. Disable Activity Stream add-on 2. Verify that the browser UI returned to default functionality on the affected areas 3. Verify all saved content is kept after add-on disabling 4. Re-enable Activity Stream add-on and verify that the browser has changed back to the Activity Stream UI 5. Verify that all saved content is kept after re-enabling |
Manual | Eng Team |
| 8 | Uninstall Activity Stream add-on | Verify that the UI changes are reverted and browser returns to default | 1. Uninstall the Activity Stream add-on 2. Verify that the browser UI returned to default functionality on the affected areas 3. Verify that all saved content is kept after the uninstall |
Manual | Eng Team |
Builds
Since Activity Stream is an add-on, you can install it from the following links:
Or you can install it trough Test Pilot experiments page. Note that the add-on only works on Firefox versions 45.x and up.
Test Execution Schedule
The following table identifies the anticipated testing period available for test execution.
| Project phase | Start Date | End Date |
|---|---|---|
| Start project | 02/15/2016 | - |
| Study documentation/specs received from developers | 07/15/2016 | 02/16/2016 |
| QA - Test plan creation | 08/02/2016 | |
| QA - Test cases/Env preparation | 02/18/2016 | 08/16/2016 |
| QA - Nightly Testing | ||
| QA - Aurora Testing | ||
| QA - Beta Testing | ||
| Release in Test Pilot Date | ||
| Release Date |
Testing Tools
Detail the tools to be used for testing, for example see the following table:
| Process | Tool |
|---|---|
| Test plan creation | Mozilla wiki |
| Test case creation | Google docs, MozTrap |
| Test case execution | TBC |
| Bugs management | Bugzilla |
Status
Overview
Track the dates and build number where feature was released to Nightly Track the dates and build number where feature was merged to Aurora Track the dates and build number where feature was merged to Release/Beta
Testing risks and mitigation
TESTING RISK
Risks can be organized into these categories.
- Test planning and scheduling : It may occur when there is no separate test plan, but rather highly incomplete and superficial summaries in other planning documents. Also, test plans are often ignored once we are written. Regarding the schedule, the schedule of testing is often inadequate for the amount of testing that should be performed in TDC, especially when testing is primarily manual.
- Stakeholder involvement : The wrong mindset would introduce wrong thought of testing, having wrong testing expectations, and having stakeholders who are inadequate committed to and supporting of the testing effort. Therefore, we must align expectations with reality between stakeholders before we kick off testing.
- Process integration : It often occurs when testing and engineering processes are poorly integrated. We sometimes take a "one-size-fits-all" approach taken to testing, regardless of the specific needs of the project.
- Test communication risk : This problems often occurs when test documents are not maintained or inadequate communication.
RISK MITIGATION
QA team would like to use following flow to address risk.
- Risk Identification: Risks can be identified using a number of resources. E.g., project objectives, risk lists of past projects, prior knowledge, understanding of system architecture or design, prior bug reports, and complaints. For example, if certain areas of the system are unstable and those areas are being developed further in the current project, it should be listed as a risk. It is good to document the identified risks in detail so that it stays in project memory and can be clearly communicated to project stakeholders.
- Risk Prioritization : If a risk is fully understood, it is easy for us to prioritize a risk by two measures. (1) Risk Impact and (2) Risk Probability are applied to each risk. Risk Impact is estimated in tangible terms or on a scale (e.g., 10 to 1 or High to Low). Risk Probability is estimated somewhere between 0 (no probability of occurrence) and 1 (certain to occur) or on a scale (10 to 1 or High to Low). For each risk, the product of Risk Impact and Risk Probability gives the Risk Magnitude. Sorting the Risk Magnitude in descending order gives a list in which the risks at the top are the more serious risks and need to be managed closely.
- Risk Treatment : Each risk in the risk list is subject to one or more of the following Risk Treatments.
- Risk Avoidance : For example, if there is a risk related to a new feature, it is possible to postpone this feature to a later release.
- Risk Transfer : For example, if the risk is insufficient security testing of a feature, it may be possible to borrow the other expertise (Engineer) to perform the security testing.
- Risk Mitigation : The objective of Risk Mitigation is to reduce the Risk Impact or Risk Probability or both. For example, if the QA team is new and does not have prior system knowledge, a risk mitigation treatment may be to have a knowledgeable team member join the team to train others on-the-fly.
- Risk Acceptance : This happens when there is no viable mitigation available due to reasons such as resources. For example, if all testers are at the same place, risk acceptance means no another QA resource. When holiday comes, some tests will be stopped and it may be a concern in the project.
References
- UX Specification: https://goo.gl/dHLYZe
- Program WIKI: https://wiki.mozilla.org/TPE_DOM/Date_time_input_types
- QA test strategy: https://docs.google.com/document/d/1YK5ePlHa3QfvaVhF4eYy922CmAt1Hkw3cWbYaOZm9AI/edit?usp=sharing
- Meta: Bug 1269956 [meta] Implement all time and date related input types
- HTML specs
- Locale: https://dxr.mozilla.org/mozilla-central/source/intl/icu/source/data/locales/ar.txt
Testcases
Overview
- Summary of testing scenarios
Test Areas
| Test Areas | Covered | Details |
|---|---|---|
| Private Window | YES | |
| Multi-Process Enabled | YES | |
| Multi-process Disabled | YES | |
| Theme (high contrast) | NO | |
| UI | ||
| Mouse-only operation | YES | |
| Keyboard-only operation | NO | |
| Display (HiDPI) | NO | |
| Interraction (scroll, zoom) | YES | |
| Usable with a screen reader | N/A | e.g. with NVDA |
| Usability and/or discoverability testing | YES | UX team will help with it |
| Help/Support | ||
| Help/support interface required | TBD | Make sure link to support/help page exist and is easy reachable. |
| Support documents planned(written) | TBD | Make sure support documents are written and are correct. |
| Install/Upgrade | ||
| Feature upgrades/downgrades data as expected | N/A | |
| Does sync work across upgrades | YES | |
| Requires install testing | NO | |
| Affects first-run or onboarding | N/A | |
| Does this affect partner builds? Partner build testing | N/A | yes/no options, add comment with details about who will lead testing |
| Enterprise | Raise up the topic to developers to see if they are expecting to work different on ESR builds | |
| Enterprise administration | N/A | |
| Network proxies/autoconfig | N/A | |
| ESR behavior changes | N/A | |
| Locked preferences | N/A | |
| Data Monitoring | ||
| Temporary or permanent telemetry monitoring | N/A | List of error conditions to monitor |
| Telemetry correctness testing | N/A | |
| Server integration testing | N/A | |
| Offline and server failure testing | N/A | |
| Load testing | N/A | |
| Add-ons | If add-ons are available for testing feature, or is current feature will affect some add-ons, then API testing should be done for the add-on. | |
| Addon API required? | N/A | |
| Comprehensive API testing | N/A | |
| Permissions | N/A | |
| Testing with existing/popular addons | N/A | |
| Security | Security is in charge of Matt Wobensmith. We should contact his team to see if security testing is necessary for current feature. | |
| 3rd-party security review | N/A | |
| Privilege escalation testing | ? | |
| Fuzzing | ? | |
| Web Compatibility | depends on the feature | |
| Testing against target sites | NO | |
| Survey of many sites for compatibility | NO | |
| Interoperability | depends on the feature | |
| Common protocol/data format with other software: specification available. Interop testing with other common clients or servers. | NO | |
| Coordinated testing/interop across the Firefoxes: Desktop, Android, iOS | ? | |
| Interaction of this feature with other browser features | Yes |
Test suite
- Full Test suite - [Full Functional test suite]
- Smoke Test suite - [Smoke test suite]
- Regression Test suite - N/A (using scenarios from Full Functional for now)
Bug Work
Meta: Bug 888320 - [meta] Firefox Download Panel UX Redesign
51 Total; 11 Open (21.57%); 38 Resolved (74.51%); 2 Verified (3.92%);
Sign off
Criteria
Check list
- All test cases should be executed
- Has sufficient automated test coverage (as measured by code coverage tools) - coordinate with RelMan
- All blockers, criticals must be fixed and verified or have an agreed-upon timeline for being fixed (as determined by engineering/RelMan/QA)
Results
Nightly testing
List of OSes that will be covered by testing
- Link for the tests run
Merge to Aurora Sign-off
List of OSes that will be covered by testing
- Link for the tests run
- Full Test suite
Checklist
| Exit Criteria | Status | Notes/Details |
|---|---|---|
| Testing Prerequisites (specs, use cases) | [IN PROGRESS] | |
| Testing Infrastructure setup | NO | |
| Test Plan Creation | [IN PROGRESS] | |
| Test Cases Creation | [IN PROGRESS] | |
| Full Functional Tests Execution | [NOT STARTED] | |
| Automation Coverage | [NOT STARTED] | |
| Performance Testing | [NOT STARTED] | |
| All Defects Logged | [NOT STARTED] | |
| Critical/Blockers Fixed and Verified | [NOT STARTED] | |
| Daily Status Report (email/etherpad statuses/ gdoc with results) | [NOT STARTED] | |
| Metrics/Telemetry | N/A | |
| QA Signoff - Nightly Release | Email to be sent | |
| QA Aurora - Full Testing | ||
| QA Signoff - Aurora Release | Email to be sent | |
| QA Beta - Full Testing | ||
| QA Signoff - Beta Release | Email to be sent |