[293] in Tooltime
Scopus Acceptance Testing
daemon@ATHENA.MIT.EDU (Steven Wade Neiterman)
Tue Oct 15 15:24:44 1996
Date: Tue, 15 Oct 1996 15:25:57 +0100
To: burke@MIT.EDU, iggy@MIT.EDU, anger@MIT.EDU, legand@mitvma.mit.edu,
sgoldman@MIT.EDU
From: Steven Wade Neiterman <wade@MIT.EDU>
Cc: tooltime@MIT.EDU
Thanks to Larry, Alicia, Art, Bob, Gerry and Steve for "volunteering"
to participate in the acceptance test.
I have enclosed some information (which should also be on the Web at
http://web.mit.edu/tooltime/www).
See you tomorrow (Wednesday 10/16) at 10:00 am in 16-720.
..Steve
---------------------------------------------------------------------
Acceptance Test Plan
Document Contents:
1. Purpose
2. Participants
3. Pre-requisites
4. Format
5. Criteria
6. Deliverable
7. Reference Material
---------------------------------------------------------------------
1. Purpose:
- Acceptance testing is to demonstrate that the system meets it's
intended project requirements in the operational environment.
2. Participants:
- One member from each of the functions will be represented.
This includes Netinstall, Helpdesk, Mainframe, Unix, DCS
and Transmissions.
- Staff testing will take place on Wednesday 10/16 at 10:00 in 16-720.
- Student testing is scheduled on 10/16 3:00 pm in 16-720
3. Pre-requisites:
- Participants are required to read training document, which
describes system navigation and functions.
- Become familiar with the system in advance of testing. This
includes using the system on the test database.
- Prior to acceptance testing, the process of unit testing, beta
testing and "release management" has been completed. The Help
Desk application has gone through seven beta release cycles.
4. Format (55 - 70 minutes):
- Five minute setup, introduction and review of ground rules
- 30 to 45 minutes testing based on "storybook" document
- 20 minutes to write results and final discussion
- The participants will use either a Windows or Power Macintosh
machine for the acceptance test.
5. Criteria:
- Acceptance test participants will follow "storybook" document.
This document is based on evaluating criteria from the Functional
Specification. Below is an except on "Release 1.0 Functionality"
as listed in the Functional Specification.
- Acceptance testing is not looking for bugs, although we
welcome (and request) mail to <tooltime-bugs@mit.edu> with
findings. While the emphasis is on receiving comments for each
scenario in the storybook, participants should be prepared to
record bugs for future resolution.
- Acceptance testing is intended to resolve the question "Can the
consultants use Scopus as the system of record as intended by the
Functional Specification"? Specifically, acceptance testing is
intended to identify items refereed to as "show stoppers", where work
can not continue and there is no work around.
- It is understood that an existing list of enhancements, bug fixes
and problem resolution will continue post release 1.0.
6. Deliverable:
- Findings from the acceptance test will be written and sent to the
project sponsor, Bill Hogue.
7. Reference (see below):
- Release 1.0 Functionality
---------------------------------------------------------------------
From Functional Specification May 31, 1996:
2. Release 1.0 Functionality
At a minimum, the Scopus/HelpDesk implementation ("SCOPUS") will have
similar functionality to the existing FileMaker system. The helpdesk
consultants will be able to continue with business as normal, with the
required training in a new product. The overall goal for the first
implementation of the product is to have the minimum functionality for the
consultants to do their business.
The SCOPUS application will have the ability to:
1. Create new helpdesk log numbers
2. Accept client information in a timely and orderly manner
3. Track the helpdesk problem throughout it's life (i.e., until resolution)
4. Have the ability to escalate problem logs based on time in-house or log type
5. Track other pertinent data that has been determined to be part of the
business model:
- Network information (installations and IP addresses)
- House Call information (on-site hardware/software problem maintenance)
- Mainframe legacy data maintenance (Midas and ADSM tracking)
