Release Package QA Test Plan


ChromeLatest Stable Release
FirefoxLatest Stable Release
MS EdgeLatest Stable Release
Safari [fluid:1]Latest Stable Release

[fluid:1] keyboard a11y can be slightly improved if you select the "all controls" option from "Keyboard Shortcuts" under the "Keyboard & Mouse" settings. May also need to use "option + tab" for tab navigation.

General QA Guidelines

On This Page

QA Tests


Distribution configurations to test

  • NPM Module
  • Individual files
  • infusion-all.js
    • minified
    • source
  • infusion-custom.js
    • minified
    • source

Test configuration

Test each of the distribution configurations.

Testing Tasks

The infusion-all.js and infusion-custom.js configurations should be tested with modified release bundles that have individual dependencies replaced with a reference to the single concatenated JavaScript file. (See Release Process - Tag, Package and Test the Release for more information on how to create these bundles)

Unit Test


Navigate to the following html file and execute all of the unit tests.

Run all unit tests by launching the html files from the following location

  • tests/all-tests.html

Ad-hoc Tests

Improvised tests for quickly discovering critical issues, and uncovering ones that may be outside of formalized testing.

Attempt to use the tool in various situations, using your imagination and freedom to explore the interface and interactions. Can use the other test types as a guide.

All test plans:
Testing Fluid Components

Ideas for future Testing of the Release Package

Method Pros Cons
Manually change all dependencies to InfusionAll.js
  • Manually ensure that all files have dependencies changed
  • Doesn't require any additional files or new samples be developed
  • Error prone
  • Time consuming (40 files * 2 packages = 80 places to change)
Minimal set of sample pages that we manually change (e.g. mock-ups)
  • Will reduce the time and error
  • Will provide examples of fluid components working together on a single page
  • May clutter the example page
  • Still have the risk of error wehn manually change the dependencies
Automated process to modify the dependencies on each page
  • Will eliminate most of the risk of error
  • Fast
  • Will have to be executed on the test system instead of the final bundle being posted
  • Introduces another layer, which may be a source of errors
The build process builds 4 different bundles, 2 using InfusionAll.js and 2 that don't
  • Part of the bundling process
  • Fast
  • Should elminate the risk of most errors
  • Will build additional bundles that will likely only be used for testing.
  • InfusionAll.js in the bundles posted, haven't really been tested
Minimal set of test files that actually link to InfusionAll.js in the repository
  • Can test InfusionAll.js from the build site if needed
  • No risk of error
  • Overhead to maintain and update
  • Developers would require InfusionAll.js on their system in order for these examples to work

  • No labels