Features/Add-ons/Add-ons Default to Compatible/TestPlan

Silent Update Add-ons Default To Compatible

Feature	Status	Lead engineer	QA Lead	Status
Add-ons Default To Compatible	In Progress	Blair McBride	Virgil Dicu	In Progress

Summary

• As majority of add-ons work from one version to the next without the need for developer maintenance, Firefox will mark addons compatible with new versions of Firefox by default, except for the following:
  • All binary add-ons
  • All strict incompatible add-ons
  • All blacklisted add-ons

• The Feature is planned for Firefox 10.

The feature is enabled in Firefox 11 Nightly and currently disabled in Firefox 10 Aurora. The feature can be enabled by setting the "extensions.strictCompatibility" preference to false in about:config.

Reference

• Feature wiki page - Link

• Bug Tracking:
  • Add-on Manager: Bug 692664
  • AMO: Bug 691834

Non-Goals

• Will not be tested:
  • Add-ons individual functionality after being enabled to default.

Fixed bugs verification

• Verified: bug 693897, bug 693899, bug 702868, bug 700201, bug 693901

• Remaining:
  • bug 695977-to verify after the pref is enabled by default in Firefox 10
  • bug 698653-still investigating

Status-week 11/7/2011-11/14/2011

Implementation work has started on Add-on manager side starting with the following bugs:

• Allow add-ons to opt-in to strict compatibility checking
• Add preference to globally (re)enable strict compatibility checks
• Support detecting binary components, and enable strict compatibility checking when found

TO DO list:

• create 75% basic functionality test cases
• run feature basic functionality test cases on all platforms (Windows XP, Windows 7, Mac OS 10.6, Ubuntu 11.10)
• run feature basic functionality test cases on Firefox 7, 8 and 9, while upgrading from each one to Nightly.
• create test cases for edge areas and different add-on states.

Status-week 11/14/2011-11/21/2011

Latest feature implementation:

• bug 695977
• bug 700201

TO DO list:

• create and run test cases for recently implemented bugs
• provide help for 18 November test day exploratory testing around Add-ons Default to compatible:Testday
• add feature test cases in Litmus

Status-week 11/21/2011-11/28/2011

DONE list:

• started running a weekly exploratory testing on Windows XP
• started adding feature test cases in Litmus
• create and ran test cases for recently implemented bugs
• started verifying fixed bugs-two bugs remaining to be verified: bug 695977and bug 698653

TO DO list for next week:

• run the weekly exploratory on Windows XP
• finish off adding test cases in litmus
• upgrade with heavy add-on profile (more than 30)
• upgrade from lower versions than Firefox 7.0.1

Use Cases to Test

• An add-on can have different states in a Firefox version: compatible-incompatible, enabled/disabled, pending restart, updated/in need of update.
• User installs several types of add-ons on a Firefox version with one or more of the above mentioned states
• When upgrading to a new version, Firefox will automatically set his add-ons to compatible with the new Firefox version, unless the installed add-ons are binary, blacklisted or strictly set to incompatible with the Firefox version.

Edge cases

• Upgrade and verify that installed third party and restartless add-ons are default to compatible or incompatible if binary/blacklisted/strictCompatibility listed
• Upgrade and check behavior for add-ons installed on older Firefox versions (<Firefox 7)
• Upgrade from Firefox4 successively to Firefox 5,6,7,8,9 and 10 and verify that all add-ons are listed as expected.

Test Cases

Test cases based on this feature are listed in the following spreadsheet: Link

Signed-off for Aurora

Signed off for Aurora:

• No major or critical bugs found
• Feature's basic functionality test cases work as expected
• Add-on are enabled and working after update

Sign-off Criteria for Release

• No unresolved major or critical bugs
• Feature's basic functionality test cases work as expected
• Ensure users can upgrade their add-ons successively from one Firefox version to another without any unnecessary change of states (e. g. from disabled to enabled)
• No other issues are triggered by this feature implementation