QA/D3D9 Fallback Preference

From MozillaWiki
< QA
Jump to: navigation, search

Revision History

This section describes the modifications that have been made to this wiki page.

Date Version Author Description
10/14/2016 1.0 Michelle Funches Created first draft

Overview

Purpose

The purpose of this document is to detail the testing for the D3D9 Fallback Preference System AddOn. The testing of this add-on is a part of Go Faster and enables Mozilla to implement System AddOn where the preference can easily be flipped.

Scope

This wiki details the testing that will be performed by SV Las Vegas for the D3D9 Fallback Preference System Addon. 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: D3D9 Fallback Preference v1.0 System AddOn - Release 49.0.1
  • How testing will be performed: Manual testing ensuring Multiprocess is Enabled
  • Combine System AddOns D3D9 Fallback Preference 1.0 & Asynchronous Plugin Rendering 1.0
  • Basic Web Compatibility

Ownership

Mozilla Development
Brad Lassey
Kirk Steuber
Felipe Gomes
Kartikaya Gupta

QA Engineering Softvision Las Vegas
Michelle Funches
Abe Masresha
Grover Wimberly IV
Justin Williams
Kanchan Kumari

Testing summary

Scope of Testing

In Scope

What will be tested:

  • Independent: D3D9 Fallback Preference System AddOn, Adobe Beta 23
  • Combined: D3D9 Fallback Preference 1.0 & Asynchronous Plugin Rendering 1.0.

Testing for issues where there have been graphics glitches.

Out of Scope

Testing will not include iOS or Android devices.
Testing will not include Macintosh or Linux as Direct X is not applicable for Macintosh or Linux.
Testing will not include Macintosh or Linux as DirectX is not applicable.


Requirements for testing

Environments

Testing will be performed on the current Release Firefox 49.0.1 with the AddOns installed.

Testing will focus on Windows OS where DirectX is applicable. Platforms include:
Windows 7
Windows 8.1
Windows 10
Testing will include Firefox 32-bit and Firefox 64-bit.

Test Strategy

Test Objectives

Ref Function Test Objective Evaluation Criteria Test Type Owners
1 D3D9 Fallback Preference 1.0 The objective the test is trying to demonstrate the addon functions as desired The criteria that will be evaluated to demonstrate the test is successful and there are not graphic/rendering issues. Manual SV-Vegas Eng Team


Test Execution Schedule

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

Project phase Start Date End Date
Start project 10/13/2016 10/14/2016
Study documentation/specs received from developers 10/13/2016 10/14/2016
QA - Test plan creation 10/13/2016 10/14/2016
QA - Test cases/Env preparation 10/13/2016 10/14/2016
Release firefox 49.0.1 with the AddOn installed 10/13/2016 10/14/2016

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 Doc
Test case execution Google Doc
Bugs management Bugzilla


Risk analysis

Bug 1309330


References

Test Cases

Overview

Testing is to focus on Multiprocess enabled. The System AddOn will change the pref. Testing will ensure the AddOn does what it is designed to do and basic Web Compatibility does not produce graphical issues.

Test Areas

Test Areas Covered Details
Private Window Done
Multi-Process Enabled Done
Multi-process Disabled N/A
UI
Interaction (scroll, zoom) Done
Usability and/or discover-ability testing Done
Web Compatibility
Testing against target sites Done
Survey of many sites for compatibility Done

Test suite

System AddOn Link to Test Results
D3D9 Fallback Preference v1.0 Full Test suite link
Asynchronous Plugin Rendering v1.0 & D3D9 Default Fallback v1.0 Combined Test suite link

Bug Work

Tracking bug

Bug fix verification
Bug No Summary Status Firefox Version
None
Logged bugs

Bug
Bug


Sign off

Criteria

Check list

  • All test cases should be executed
  • All Blocks and Critical bugs must be fixed and verified or have an agreed-upon timeline for being fixed (as determined by engineering/RelMan/QA)