Skip to end of metadata
Go to start of metadata

Release Package QA Test Plan

Environments

BrowserVersion
ChromeLatest Stable Release
FirefoxLatest Stable Release
Internet ExplorerLatest 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


Configurations

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

________________________________________________________

Protocol
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

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

Protocol
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