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 > Printing Feature Test Plan

Client QA Component Test Plan: Seamonkey Project

Printing

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
    • Network
    • Remote Connection
    • Off-line

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
August 10, 1999 initial draft 1.0 B.Epperson
August 11, 1999 include comments by reviewers 1.1 B.Epperson
May 30, 2000 updated testplan 1.2 S. Khanzode
Dec 19, 2000 updated testplan 1.3 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

Printing functionality must be thoroughly tested across all tier 1 platforms. Testing must be conducted on Win95, Win98, WinNT, Win2000, Mac 8.51, Mac 8.6 and Linux Redhat 6.1. Testing must be done on networked and local printers.

The initial focus will be to ensure that a set of networked printers are tested across the supported platforms. It will be imperative that we are able to engage assistance from the net community to test local printer functionality. Goals of Printing include:

  1. Printer Functionality
  2. Test all platforms with an equal suite of tests
  3. Support for general printing
  4. HTML element support
  5. Additional Standards Support
    1. CSS
    2. XML
    3. Javascript
    4. Plug-ins
  6. Print Preview Properties Support
    1. Page next
    2. Page previous
    3. Multiple page view
    4. Zoom In
    5. Zoom Out
    6. Print
    7. Close

2.Areas To Be Tested

Component Features

  • Networked printer functionality
  • Local printer functionality
  • Off-line selection
  • Print Preview
  • Forms
  • Frames
  • Tables
  • Images
  • Large textual pages
  • Entities
  • Complex pages -- top 100 sites
  • Meta data
  • Printer Headers/Footers
  • Page source
  • Cross platform parity
  • JavaScript
  • Plug-ins
  • XML
  • CSS

Related Areas:

n/a

3.What Will Not Be Tested

We will not test printing functionality from the Mail/News applications. That level of testing is being supported by the Mail/News QA group. Also, printing testing on composer will need to be supported by the Composer QA.

4.Approach

Strategy

The printing tests should be constructed in such a manner that all platforms are evaluated on an equal suite of tests. In addition, networked printers should be equally tested across platforms. Local printers may or may not be tested on an equal basis, the volume of printers available and the volume of configurations make a complete set of testing virtually impossible. There are specific printer features that are unique for each printer type, in addition there are specific printers that operate with specific platforms, thus achieving cross platform parity is unrealistic. The testing conducted will be done in such a manner, that we will ensure that printer specific features will be tested in that the feature selections are selectable from the dialog and ensure that the selected value instructions are transmitted to the printer. For now, all the testing to be performed for printing is black box testing. Testcases will be run manually. Due to the recently new addition of themes to the browser, printing testing with different themes will be supported by the Printing QA. All of the functionality tests will be run equally with all themes on all platforms.

Automation

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

Acceptance Testing

Acceptance tests should basically cover the following:

  • Basic HTML pages (not within framesets) print correctly
  • Top website homepages must WYSIWYG print
  • www.mozilla.org webpage should print as is

Functional and Usability Testing

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

Printer properties

  • paper
  • orientation
  • print to file
  • range
  • copies
  • collate
  • color/bw
  • scale
  • watermark

    All printer specific functions must be tested, ensuring that all functions can be adjusted and that they 'stick.'

Page Setup

  • Page options (beveled, black text, black lines, last page first, print backgrounds)
  • Margins
  • Header (document title, document location)
  • Footer (page number, page total, date)
  • All page setup options must be editable and functional.

Print Preview properties

  • Page next
  • Page previous
  • Multiple page view
  • Zoom In
  • Zoom Out
  • Print
  • Close

Print Preview functionality must be functional and stable. All functions should respond the same across platforms.

General Printing

  • Print Basic Functional tests
  • Print a sub-set of top 100 sites
  • Print a View Source page
  • Print with SideBar open/closed
  • Postscript Printing
  • Print from 1. toolbar, 2. File | Print, 3. Ctrl-P
  • Printing the basic functional test pages and a sub-set of the top 100 sites will be used to determine if there are any major issues with the printing engine. It will help to establish a baseline for each milestone.

Format and fonts

  • Color printing
  • Font size
  • Font style
  • Variable and fixed font
  • Font formatting should be functional and stable. All format issues should be the same across platforms.

HTML element support

  • Headings
  • Lists
  • Format elements
  • Block elements
  • Tables: simple, complex, extend physical page breaks
  • Forms: simple and complex
  • Frames
  • Entities
  • Images
  • Meta Data: author, expiration date, etc.

    All HTML 4.0 element content should be previewed and printed without error.

Additional standards support

  • CSS Level 1 properties that affect layout and rendering
  • XML generated pages
  • JavaScript: JavaScript rendered pages, embedded JavaScript
  • Plug-ins: print preview and printing plug-in content

All supported and relevant standard objects should be previewed and printed

Non-HTML file type

  • .asp
  • .css
  • .gif
  • .jpg
  • .png

All supported file extensions should be previewed and printed

Stress, Regression Testing

  • Barcode label from UPS
  • Nested tables
  • Printer turned off
  • Network disconnect
  • Timeout

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 functional testcase suite on mozilla website, please go here. To view the testcase matrix for printing, please go 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

n/a