QA/WebVR

< QA
Revision as of 16:17, 11 July 2017 by CristiComo (talk | contribs) (Polishing up the document.)

Approvals Required / Received

The following individuals are required to/have approved this Test Plan:

Name Title Department Approval Date Method
QA Manager Product Integrity Date Email
Software Engineer Engineering Date Email
EPM Product Management Date Email


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
07/23/2017 1.0 Cristian Comorasu Created first draft

Overview

Purpose

The purpose of this document is to describe the WebVR feature from a testing perspective, including the following details:
  • Scope, focus areas and objectives of testing
  • Owners and points of contact for areas of responsibility
  • Strategy and types of testing
  • 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
See https://wiki.mozilla.org/QA/MozVR for other test plans.

Scope

This wiki details the testing that will be performed by the project team for the webVR 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

Developer contacts: Kearwood Kip Gilbert
QA contacts: Cristian Comorasu (:CristiComo), Cornel Ionce (:cornel_ionce)

Testing summary

Scope of Testing

In Scope

The current testing scope is to ensure that the WebVR:

  1. does not have regressions in performance or latency
  2. is stable
  3. is reliable ( visibility )

Out of Scope

Detail what is out of scope from a testing perspective for the project team. Note: if usability testing is not in the scope of testing feature.

Requirements for testing

Environments

Testing will be performed on following OSes (x64 infrastructures):

  • Windows 10
  • Windows 8.1

Hardware

The minimum system requirements for Windows OS are:

  • Graphics
    • GTX 970 equivalent or greater
    • AMD 290 R9 equivalent or greater
    • Quadro k600 or newer
  • CPU
    • Intel i5-4590 equivalent or greater
    • AMD FX 8320 or greater
  • 8GB+ RAM
  • Compatible HDMI 1.3 video output
  • 2x USB 3.0 ports
  • Windows 7 SP1 or newer, plus the DirectX platform update

Devices

  • Oculus VR Rift HD (for pc) + Oculus Touch Controlllers
  • HTC Vive (for pc)

Testing will be performed on a machine with the following specifications:

    • GPU: MSI GeForce® GTX 1050 2GT OC, 2GB GDDR5
    • CPU: AMD FX-8320 3.50 GHz
    • RAM: 16 gb DDR3 @ 1600mhz

Channel dependent settings (configs) and environment setups

Nightly

text

Beta

text

Test Strategy

Risk Assessment and Coverage

ID Description / Threat Description Covered by Test Objective Magnitude Probability Priority Impact Score
RAC-1 Risk description 1 TO-1 2-Moderate 1-Unlikely 3-High 6
RAC-2 Risk description 2 TO-1 3-High 3-Almost Certain 3-High 27
RAC-3 Risk description 3 TO-2 2-Moderate 2-Possible 3-High 12

Values:

  • Magnitude: 1- Low , 2-Moderate, 3-High
  • Probability: 1-Unlikely, 2-Possible, 3-Almost Certain
  • Priority: 1 - Low, 2-Medium, 3-High

Impact Score Breakdown:

  • An impact value of 1, 2, 3, 4 would describe an area which although should be covered there aren't expected any discoveries of critical issues.
  • An impact value of 6, 8, 9, 12 would describe an area in which we expect to find issues but those issues are not expected to be critical.
  • An impact value of 18 or 27 would describe an area on which it is likely to find issues and those issues to be critical or blockers.

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 RAC Owners
1 WebVR The visual efects and user happy flow. The feature is smooth and visualy reliable. Manual,Regression, Performance, Usability RAC-1, RAC-2, RAC-3 Desktop Team
2

Builds

Test Execution Schedule

The following table identifies the anticipated testing period available for test execution.

Project phase Start Date End Date
Start project TBD TBD
Study documentation/specs received from developers 07.12.2017 TBD
QA - Test plan creation 07.12.2017 TBD
QA - Test cases/Env preparation 07.13.2017 TBD
QA - Nightly Testing TBD TBD
QA - Beta Testing 07.14.2017 TBD
Release Date TBD TBD

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 TestRail/ Google docs
Test case execution TestRail
Bugs management Bugzilla

Status

Overview

Track the dates and build number where feature was released to Nightly (TBD)
Track the dates and build number where feature was merged to Release/Beta (TBD)


References

  • List and links for specs
 List and links for available specs - documents, user stories, specifications (TBD)
  • Meta bug: TBD

Testcases

Test Areas

Test Areas Covered Details
Private Window NO -
Multi-Process Enabled NO -
Multi-process Disabled YES -
Theme (high contrast) NO -
UI
Mouse-only operation NO -
Keyboard-only operation NO -
Display (HiDPI) YES TBD
Interaction (scroll, zoom) NO -
Usable with a screen reader NO -
Usability and/or discoverability testing YES TBD
RTL build testing NO -
Help/Support
Help/support interface required YES TBD
Support documents planned(written) YES -
Install/Upgrade
Feature upgrades/downgrades data as expected YES TBD
Does sync work across upgrades NO TBD
Requires install testing YES TBD
Affects first-run or onboarding NO TBD
Does this affect partner builds? Partner build testing NO -
Enterprise Raise up the topic to developers to see if they are expecting to work different on ESR builds
Enterprise administration NO -
Network proxies/autoconfig NO -
ESR behavior changes NO -
Locked preferences NO -
Data Monitoring
Temporary or permanent telemetry monitoring NO -
Telemetry correctness testing NO -
Server integration testing NO -
Offline and server failure testing NO -
Load testing NO -
Add-ons
Addon API required? NO -
Comprehensive API testing NO -
Permissions YES TBD
Testing with existing/popular addons NO -
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 YES TBD
Privilege escalation testing YES TBD
Fuzzing YES TBD
Web Compatibility depends on the feature
Testing against target sites YES TBD
Survey of many sites for compatibility YES TBD
Interoperability depends on the feature
Common protocol/data format with other software: specification available. Interop testing with other common clients or servers. YES TBD
Coordinated testing/interop across the Firefoxes: Desktop, Android, iOS NO -
Interaction of this feature with other browser features NO -

Test suite

Full Test suite - TBD - testcases should be added under Firefox Desktop project link
Smoke Test suite - TBD - if available/needed.
Regression Test suite - TBD - if available/needed.

Bug Work

Meta bug: [TBD]

Logged bugs ( blocking 12345 )

Bugzilla query error

Query options must be valid JSON.1


Bug fix verification
Full Query
ID Priority Component Assigned to Summary Status Resolution Target milestone
15069 P3 Networking jefft File type url not correctly parsed and created VERIFIED FIXED M13

1 Total; 0 Open (0%); 0 Resolved (0%); 1 Verified (100%);

Sign off

Criteria

Checklist

  • 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
    • Full Test suite, link to TestRail - Tests Runs and Results link
    • Daily Smoke, if needed/available
    • Regression Test suite, if needed/available


Merge to Beta 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)
Testing Infrastructure setup
Test Plan Creation
Test Cases Creation
Automation Coverage
Performance Testing
All Defects Logged
Critical/Blockers Fixed and Verified
Metrics/Telemetry
Basic/Core functionality Nightly testing
QA mid-Nightly Signoff Email to be sent
QA Nightly - Full Testing
QA pre-Beta Signoff Email to be sent
QA Beta - Full Testing
QA pre-Release Signoff Email to be sent