You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.

Skip to main content

You are here: Browser/Composer front-end QA > front-end test plans > Sidebar Test Plan

Client QA Component Test Plan: Seamonkey Project

Sidebar

Written by Shrirang Khanzode
Email shrir@netscape.com

DOCUMENT CHANGE HISTORY

1. COMPONENT

  • Description

2. AREAS TO BE TESTED

  • Component Features
  • Related Areas

3. AREAS NOT TO BE TESTED

  • Undocumented Features

4. APPROACH

  • Strategy
  • Automation
  • Acceptance Testing
  • Functional Testing
  • Usability Testing
  • Stress Testing
  • Regression Testing

5. RESOURCES

  • Software
  • Hardware
  • Data
  • Lab Time
  • Other Tools

6. CONTINGENCIES

7. SIGNOFF APPROVAL

8. REFERENCE MATERIALS

  • Schedule link
  • Specifications link
  • Supported Platforms link
  • Automation

Document Change History:

History
Date Change Description Revision Updated By
May 31, 2000 initial draft 1.0 S. Khanzode
Dec 19, 2000 Updates and additions 1.1 S. Khanzode

* Note - This Test Plan is a "living document"; it can be continually modified to conform to changes during the project.

1.Component

Description

Sidebar provides a place within Netscape's web client software for users to keep connected to what is most important to them. It is a standalone within the browser window and has a variety of tabs for quick access to data.Tabs are like regular web pages in that they are built on HTML and other web standards. Sidebar tabs can deliver up-to-date, dynamic information. Users can easily add and customize Sidebar tabs. Any web site content can be delivered as a tab, enabling one to leverage the existing web content. Testing for Sidebar must be conducted on Windows95, Windows 98, Windows NT, MacOS8.6, and Linux 2.0. Since Sidebar is UI intensive, it will also be tested on a variety of screen resolutions down to 800x600. Testing of Sidebar embedded in other products like Mail, Composer and AIM will be seperate to this testing and groups responsible for those products should test the Sidebar as a component of their testing. Withe the addition of themes to the browser, Sidebar functional testing on these different themes will be the responsibility of the Sidebar QA. Themes testing will basically cover only the very basic things about the Sidebar.

2.Areas To Be Tested

Component Features

  • Opening/Closing
  • Default Setup
  • Re-sizing/Minimizing Panels
  • Scrolling
  • Re-sizing Sidebar Horizontally
  • Content Panels
  • Customize Dialog
  • Add/Remove Panels
  • URL links in panels
  • Add panels thru javascripts
  • Preview Tab

Related Areas :

n/a

3.What Will Not Be Tested

Sidebar testing in other products like Mail, AIM, Composer will be the responsibility of the team that will QA these products.

4.Approach

Strategy

The Sidebar testcases should cover all possible UI tasks. The Sidebar tests should be constructed in such a manner that all platforms are evaluated on an equal suite of tests. Major platforms like Windows95, Windows 98, Windows NT, MacOS8.6, and Linux 2.0 will be covered as a part of testing. . Since Sidebar is UI intensive, it will also be tested on a variety of screen resolutions down to 800x600. Different tests like acceptance, functional, stress and regressions will be used. Acceptance tests will be run on a daily basis and will be the minimal set of tests that should pass before proceeding to functional testing. Blackbox tests will be mainly written from bugs logged and from the UI. All testing for now will be done manually. Testing should be done on all standard themes for the browser.

Automation

At present, no automation is being used for testing purposes.

Acceptance Testing

Acceptance tests should basically cover the following:

  • What's Related panel contents should show up
  • Add | Customize should open a 'Customize' window
  • Open|Close sidebar with the grippy

Functional and Usability Testing

The functional areas and features/functions to test are as follows:

  • General Sidebar Widgets, Controls and Behavior
    • Opening/Closing - Sidebar opening/closing behavior will be tested.
      • Mousing over the grippy open/close widget should change it's color.
      • Clicking once when it's open should close.
      • Clicking once when it's closed should open.
    • Default Setup - The default setup of Sidebar will be tested
      • test that the sidebar comes up open on a clean profile
      • test that the correct default panels come up
      • verify the heights and width of panels are to spec
    • Reload - There is a button to reload panels. This will be tested.
      • Flashes should reload. This is similar to hitting 'Get Messages' in mail even though you have it set to check every x min.
      • Panels should also reload (I think). It is unclear how this will work.
    • Polling - Polling
      • Flash Panels should poll whether or not sidebar is open. This will probably be done with the aim protocol.
      • Normal content panels should not refresh when closed. It is unknown how polling/refresh will work on normal panels.
    • Scrolling - The current plan is to have one scroll bar for sidebar. However, this may change.
    • Re-sizing/Minimizing Panels - The current plan is for Panels to be resized through a dragging mechanism. This will be tested.
    • Re-sizing Sidebar Horizontally - The current plan is for the Sidebar to be resizable horizontally. This will be tested.
      • The state of a panel should be saved on shutdown. Both the size and whether it is open or closed.
    • Links - Links are 'legal' in both content and flash panels and should be tested accordingly.
    • Off-line - It is unclear what level of support Sidebar will have for off-line browsing. Need a spec on this.
      • Application specific panels should load when you are off-line.
      • Panels requiring a network connection should have some type of caching mechanism.
    • 3rd party manipulation - Third parties will be able to create their own panels. This testing is out of the scope of the browser QA group.
    • Drag and Drop - Normal Drag & Drop functionality should exist in Sidebar and will be tested.
      • Links should be able to be dragged out of sidebar into another window
      • Links should probably not be allowed to drag into a sidebar panel.
    • Status bar - There is currently no status bar in the sidebar. If one appears, it will be tested.
    • Preferences - There is currently no sidebar component in prefs panes. If one shows up, it will be tested.
  • Content Panels - The plan is for application specific panels to be tested by the browser QA group.
    • Bookmarks - Bookmarks panel will be tested for consistency with normal Bookmarks UI. It will be Read Only (I believe)
    • What's Related - to be tested by both Netcenter and Client
      • Should have to click on Related Links to get sites
      • Will remain open once opened but
      • Should not query if domain does not change
    • AIM - Testing TBD
    • My News - to be tested by Netcenter
    • Search - Probably tested by Netcenter
    • Other My Netscape Channels - to be tested by netcenter
    • Third Party Channels - no plans to test, except on an adhoc basis
  • Flash Panel (notifications) - This section is a bit bare, as the architecture of notifications is still be worked out.
    • When closed, notifications should still come and be noted by some icon at the bottom of the sidebar.
    • Polling, whether through AIM protocol or some other way, will have to be tested.
    • You should be able to click on Links in the Flash Panel.
    • There will be a mechanism for POPUP's when a notification is received, and that will be tested.
    • Add Flash API - There will be a way to add Flashes through an API. There will be minimal client-side UI to support this that will be tested.
  • Customize Dialogue
    • Launching from Sidebar - There is a Customize button at the top of the Sidebar that will be tested.
    • Current Panels - This is at the top of the Customize Dialogue
      • The list should match that which is seen in the Sidebar (before any have been removed or added)
      • The Reorder Up/Down buttons will be tested
        • Up will be tested, including corner cases, (top and bottom), and with only 1 panel present. Changes should be reflected in sidebar at appropriate time.
        • Down will be tested, including corner cases, (top and bottom), and with only 1 panel present. Changes should be reflected in sidebar at appropriate time.
      • Remove Panels
        • Removing a panel should be reflected in Current Panels immediately
        • Should be reflected in the Sidebar after a Save
      • Customize Panels - You will be able to select a Panel from Current Panels and then Customize it. This will be tested.
    • Add Panels - At the bottom of the Customize is some UI to Add Panels
      • Available Panels - There will be a list of available panels pulled down from Netcenter. Some work will have to be done to test cases where a
    connection is not available.
    • Add Panel - There will be an ADD panel button tested.
      • Adding a panel should be reflected in the Current Panels immediately
      • Adding a panel should be reflected in the Sidebar after a Save
    • Preview Panel - You will be able to preview a panel before adding it. This will be tested.
    • Cancel - There will be a cancel button. If you have not yet hit Saved, changes will not be saved.
      • Try adding a panel but hitting Cancel before Save.
      • Try removing a panel but hitting Cancel before Save.
      • If there is an X close button in the upper right of the customize dialogue, it should act like a cancel.

Stress, Regression Testing

  • Add/ Delete 20-25 panels to Sidebar
  • Rapidly move between tabs in Sidebar
  • Test grippy max width
  • Open/Close Sidebar for a number of times
  • Click random links inside panels in Sidebar ( even before the first one opens)

Reviewing previously written bug submissions and creating a suite of test cases to correspond to those submissions will be of great value in ensuring that previous issues have not been reintroduced. The regression test suite should include tests from the current application and from the 4.x tree. To view the Sidebar testcase matrix, click here.

5.RESOURCES

Software

OS/ System Software

Please see the Seamonkey Platforms link at http://client/seamonkey/prd/seamonkey_platforms.html for a description of the hardware/software to be used in testing.

Hardware

Computers

Please see the Seamonkey Platforms link at http://client/seamonkey/prd/seamonkey_platforms.html for a description of the hardware/software to be used in testing

Data

n/a

Lab Time

n/a

Other Tools n/a

  • Network
  • Remote Connection
  • Off-line

6.CONTINGENCIES

Loss of Test Machine Resources

While highly unlikely there is the possibility that Test Machines could break down. Planning should be done, by each component area to ensure there are reserves of
equipment to be drawn upon.

Bugs

If outstanding bug counts do not drop and cannot be mitigated between QA, Engineering, and Marketing there is the potential that the project schedule may have to slip. The time increment will be agreed to by the project leads.

Builds

There is the potential for build crisises to arise (tree spammage, etc.) which can impact QA and Engineering getting code to use for their work, and therefore adversely affect the schedule. Some planning should be done in this area in anticipation of the most probable things that could go wrong.

7.SIGNOFF APPROVAL

Name                    Date

QA Lead ________________________ / /

Eng Lead ________________________ / /

Automation Lead ________________________ / /

Project Manager ________________________ / /

Product Manager ________________________ / /

Dir. of Engineering ________________________ / /

Dir. of Quality Assurance ________________________ / /

8.REFERENCE MATERIALS