You are here: Browser/Composer front-end test cases > File Handling QA > Test documentation for the download manager
Test Documentation for the Download Manager
Maintained by Chris PetersenThis QA document covers front-end testing for the download manager window from the browser (Navigator) application in Mozilla (or Netscape).
What will be tested
Testing will primarily cover the user interface of the download manager window.
- Access to the download manager
- top-level menu: Tools > Download Manager in an application window (Navigator, etc.)
- upon initiating a file download
- Column information available in the download manager
- Toolbar buttons in the download manager
- Test on the main platforms: Win32, Mac OS and Linux
- Overall look and feel:
- Appearance, highlighting/selection, navigation
- Spelling, typos, grammar of any text/descriptions
- Any front-end or back-end preferences?
What will NOT be tested
For other file handling areas, there are QA docs for basic downloading UI and helper applications.
In addition, there are some other areas which are related to downloading in general, but they are either covered by other QA groups, or cannot be covered due to time constraints. also, there are some areas which might seem related (from an end-user perspective), but really aren't. I've listed the possible areas below --along with relevant Bugzilla components which might help narrow down who works on what. (Unless otherwise noted, these components reside under the Browser product.)
- Back-end aspects of downloading/saving files. Some of these bugs would be in File Handling, but some might also be in the Networking components.
- Helper applications, to launch other apps and open files. Some of these bugs would be in File Handling.
- Files can be saved from mail. Bugs belong in either the Mail Back End, or Mail Window Front End components of the MailNews product.
- File picker for selecting the target location of a file to be downloaded.
Issues, references & bug information
There aren't any formal/approved UI/UE specifications for the download manager, but there are a couple of engineering specs:
- Download manager proposal written by Ben Goodger:
http://www.mozilla.org/xpapps/MachVPlan/DownloadMgr.html
- A detailed UI spec written by Matthew Thomas at http://www.mozilla.org/projects/ui/navigator/downloads/. Not sure how much of this will be incorporated into the actual implementation, which is currently based off of Ben's spec.
- Task breakdown/estimates for the download manager: http://www.mozilla.org/xpapps/MachVPlan/Download_Mgr_estimate.html
Once of the biggest issues that affects download UI, including the download manager, is the fact that Mozilla starts downloading the file into a temporary location, rather than directly into the specified target location. This has resulted in a slew of behavioral and appearance issues.
- bug 55690: Spool file should be moved once the user picks a filename (saving a file creates a file before location is chosen)
- bug 129923 (meta): Bugs related to pre-saving files to temp directory
- bug 132456: Download manager appears for files being opened by helper applications
- bug 155426: Download manager broken on Mac OS X (trunk)
Bugs specific to this feature should reside in the Download Manager component of Bugzilla.
- Currently open bugs under Download Manager (Unconfirmed, New, Assigned and Reopened)
- Currently Resolved Fixed bugs under Download Manager (but not yet Verified)
- Bugs otherwise Resolved under Download Manager as Duplicate, WorksForMe, Invalid or Won't Fix (but not yet Verified)
Test coverage & outline
The download manager is a non-modal window which consists of a toolbar, informational columns, a listing of files downloaded or in the progress of downloading, and a status bar at the bottom which displays the location of the selected file.
- Acceptance level (baseline functionality)
- Functional level
- Stress, boundary, negative, etc.
- Ad hoc and regression testing
Acceptance tests
Test access to the download manager.
- Top-level menu: Tools > Download Manager in an application window (Navigator, etc.)
- Platform differences (trunk). Upon iniating a file download on Win32 or Unix, the download manager window will appear by default. However, on Mac OS the download progress dialog appears by default.
Test the buttons in the toolbar (which is collapsable). Varies among the platforms.
- Win32:
- Properties currently displays (or brings to the front) the "regular" download progress dialog for the selected file. Disabled unless download in progress, bug 139606.
- Cancel stops download of selected file.
- Remove from List deletes selected file from the download manager window.
- Launch File opens the selected, downloaded file. Only works if there's a helper application associated for the particular filetype (expected).
- Show in Explorer brings up a new Windows Explorer window, to display the selected file's location.
- Linux:
- Properties: Same as Win32; also disabled unless download in progress, bug 139606.
- Cancel: Same as Win32.
- Remove from List: Same as Win32.
- Show in Browser brings up a new Navigator window, to
display the selected file's location in a directory (file:///) listing.
- Mac OS:
- Properties: Same as Win32; also disabled unless download in progress, bug 139606.
- Cancel: Same as Win32.
- Remove from List: Same as Win32.
- Launch File opens the selected, downloaded file. Only works if there's a helper application associated for the particular filetype (expected).
- Show in Finder brings up a new Mac OS Finder window, to display the selected file's location.
id="columns">Test columns and column picker in the download manager window. You should be able to:
- Select and deselect any of the columns (except that Name is always present)
- Sort (ascending or descending) any of the columns by clicking their headers
- Resize the width of any of the columns
The columns are described below.
- Name is the file's name. Always present.
- Progress is a progress meter when download is in progress.
- It should stop painting if (where applicable) the download is paused by the user.
- When successfully completed, the meter should be replaced with Finished.
- If the download is canceled, the meter should be replaced with Canceled.
- This column is present by default.
- % displays the percentage of the file downloaded. It should be consistent with what's displayed for the progress meter (and vice versa). Once complete, it should display 100.
- Time Remaining displays the estimated time (down to
seconds) remaining for a file's download.
- When finished or canceled, this column is empty.
- This column is present by default.
- Transferred displays the amount in kilobytes of the file
that have been downloaded. Bug 137676
covers an issue of "0KB of 0KB" appearing.
- When finished, it should display <total>KB of <total>KB.
- When canceled, it should display the portion of file downloaded.
- This column is present by default.
- Speed displays the rate of downloading in KB/sec.
- When finished or canceled, this column is empty.
- This column is present by default.
- Time Elapsed displays the amount of time elapsed (down to seconds) of a file's download.
- Source displays the URL from which the file is (or was, if finished or canceled) downloaded.
Functional tests
Functional tests essentially include the acceptance level tasks, as well as a few more tests.
[include prefs, column reordering, multiple deletions, multiple downloads, access keys/keybd nav in listing, etc.]
Stress, boundary, negative, etc.
Stress and boundary testing will be covered as time permits, especially if issues are encountered during ad hoc testing.
eg, closing the regular progress dialog but keeping the dl mgr up, many multiple deletions/downloads, extreme window resizing, etc.
Ad hoc & regression testing
Ad hoc testing is covered by users in the Internet community, as well as casual use. Due to time constraints, regression testing will encompass:
- Verification of Resolved (Fixed ones get priority) bugs as they come in.
- Periodic verification (eg, milestone deadlines) of Big Issues to make sure they're still fixed. This would go hand in hand with the usual testing that occurs during those periods.
- Ad hoc testing with daily builds.