design & implementation of an electronic id system...

Design & Implementation of an Electronic ID System for Inventory Management

2012 – 2013

Test Plan

Version 1.020 October 2012

Luke Engelbert-FentonC. Melissa Vetterling

Adviser: Dr. Ali Pezeshki,

Electronic ID for Inventory

VERSION HISTORY

Version#

ImplementedBy

RevisionDate

ApprovedBy

ApprovalDate

Reason

1.0 Vetterling 10/22/12 Initial Test Plan

UP Template Version: 12/31/07

of 11For ECE 401 – 2012-2013

APAP

Oct 23, 2012

https://signfromreader.echosign.com/verifier?tx=PC9DEUXP464NX7


TABLE OF CONTENTS1 INTRODUCTION ...................................................................................................................... 4

1.1 Purpose of The Test Plan Document .................................................................................. 4

2 COMPATIBILITY TESTING .................................................................................................. 4 2.1 Test Risks / Issues .............................................................................................................. 4 2.2 Items to be Tested / Not Tested .......................................................................................... 4 2.3 Test Approach(s) ................................................................................................................ 5 2.4 Test Pass / Fail Criteria ....................................................................................................... 5 2.5 Test Deliverables ................................................................................................................ 5

3 FUNCTIONAL TESTING ......................................................................................................... 6 3.1 Test Risks / Issues .............................................................................................................. 6 3.2 Items to be Tested / Not Tested .......................................................................................... 6 3.3 Test Approach(s) ................................................................................................................ 7 3.4 Test Pass / Fail Criteria ....................................................................................................... 7 3.5 Test Deliverables ................................................................................................................ 7

4 USER ACCEPTANCE TESTING ............................................................................................ 8 4.1 Test Risks / Issues .............................................................................................................. 8 4.2 Items to be Tested / Not Tested .......................................................................................... 8 4.3 Test Approach(s) ................................................................................................................ 9 4.4 Test Pass / Fail Criteria ....................................................................................................... 9 4.5 Test Deliverables ................................................................................................................ 9 4.6 Test Environmental / Staffing / Training Needs ................................................................. 9

TEST PLAN APPROVAL ......................................................................................................... 10 APPENDIX A: REFERENCES ................................................................................................. 11

of 11For ECE 401 – 2012-2013


1 INTRODUCTION1.1 PURPOSE OF THE DOCUMENT

The document documents and tracks the necessary information required to effectively define the approach to be used in the testing of the project’s product. Its intended audience is the project adviser, and project team. Some portions of this document may on occasion be shared with the client.

2 COMPATIBILITY TESTING2.1 TEST RISKS / ISSUES

There are three primary compatibility concerns with this project:1. Animal Laboratory Environment -

Due to the laboratory environment, the components used to physically identify cages, as well as those used to read the identification, must be safe for use around, and not cause effects that would disrupt studies of animals.

This will be addressed with preliminary research to avoid a design that would not be safe for implementation in the environment.

2. Database Interface - This product must interact with a computer database. Therefore it is necessary that the database interface bei. Well designed to prevent loss of data in the transfer process,ii. Easily accessible for modification of features,iii. Well behaved so that once data has been pulled from or submitted to

the database, the interface ceases to exercise control.

This will be addressed through thorough design and software testing of the interface, at the advice of a computer expert.

3. Autoclaving – All items used for physically identifying the cages, which are not disposable, must be subject to a periodic autoclaving process for cleaning. This involves a high-pressure water bath at temperatures in excess of 240° F.

The intent is to use only disposable technology so that nothing need be subject to the autoclave process. (This does not include the reader).

2.2 ITEMS TO BE TESTED / NOT TESTED

Item to Test Test Description Test Date Responsibility

Safety Confirm no danger to use in labs. 12/15/12 LEF, CMV

Disposable Product Run price simulations with current rates and usage data.

12/15/12 LEF, CMV

Database Interface Use cloned database to confirm that no undue control is retained & no information is lost in transfers.

02/01/13 LEF, CMV

of 11For ECE 401 – 2012-2013


2.3 TEST APPROACH(S)These tests will be performed via simulation. The safety for use around animals can be confirmed using product specifications and current accepted procedures as dictated by the regulatory bodies for animal laboratory tests, with input from Lon Kendall & his team, to ensure no animal tests are negatively impacted by the technology. Any concerns not addressed with this initial approach can be tested through direct measurement of emissions in an unpopulated room.The database interface can be tested with multiple simulations. Use of a cloned database will be involved so that failure of any part of this test will not impact actual data. The specifics of how to test this interface will be developed in more detail as the design progresses. At this time, the anticipation is to test the data handling performance, and ensure that the interface surrenders control when its task is complete. Additionally, mock changes may be implemented to assess the accessibility for future modification.The disposable nature of this product, intended to avoid the need for autoclaving, will be assessed through price simulations. The current usage data and cost rates for investigators can be used, along with the prices of selected design components, to model a one-month, 6-month, 1-year and 5-year price impact study. This study will look at the cost of using the disposable technology and allow the feasibility of such to be assessed.

2.4 TEST PASS / FAIL CRITERIAThe safety for use around animals will be determined based on the industry-accepted standards, as implemented by the regulating bodies.The database interface will be determined based on a factor of safety that will be necessary to maintain sufficient function and minimal risk of error.The price impact of disposable technology will be based upon its compliance with the proposed budget, and the approval of Lon Kendall.

2.5 TEST DELIVERABLESThe successful determination that the solution is safe for implementation in an animal laboratory environment shall be documented, and that document provided to the client for their assurance. The client shall also be provided with the cost model and final analysis. The successful testing of the database interface should be documented, along with the test procedure and any changes that became necessary, but that document may remain internal to the team.

of 11For ECE 401 – 2012-2013


3 FUNCTIONAL TESTING3.1 TEST RISKS / ISSUES

There are several steps the product must successfully complete to be functional according to the design. These are

1. updating from the main database in preparation for a census scan,2. scanning a room in less than 5 minutes

a The room may contain up to 300 cages,b The scan must not identify cages not inside the room being scannedc The scan must alert if

1. Cages are found that should not be in the room,2. Cages are found that are not in the database,3. Cages are not found, which should be located in the room

3. allow user to process the warnings generated in step ii,4. generate a report of the census scan,5. update to the main database as needed.6. allow removal of an id for census via manual operation on the database, as

well as via a scan at the check-out-station.



Cage Scan – Single Cage

Perform a scan of a single cage id, without regards to room location.

12/10/12 CMV

Location Scan – Single Cage

Upon successful single-cage scan, perform scan of a single cage (a) in the expected room location, (b) outside the expected room location. Ensure proper behavior on both with regards to Section 3.1-1(b)

12/15/12 LEF

Update Retrieval Update from main database & perform a comparison to ensure update was successful.

01/03/13 LEF

Alert Test – Two Cage

Perform a two-cage scan in the expected location, and outside the expected location to ensure behavior in accordance with Section3.1-1(c)

01/03/13 CMV; LEF

UI Test I Test procedure for addressing alerts that are generated from the scan to ensure user input is accepted.

01/10/13 CMV

Report Generation Perform simulated census of full-capacity scan and generate report.

01/10/13 LEF

UI Test II Test procedure for addressing alerts to ensure that laboratory personnel are able to operate effectively with the feature.

01/14/13 LEF

of 11For ECE 401 – 2012-2013


Database Update Using cloned database, perform a scan at 20% capacity or greater and ensure proper update to main database.

01/19/13 CMV

ID Removal – Manual

Test removal of RFID via manual entry. Process must be confirmed with successful scan following removal that (a) does not identify the ID as missing if not scanned, and (b) identifies the RFID as unexpected if it is scanned.

01/26/13 LEF; CMV

ID Removal – Check Out Station

Test removal of RFID via scan at the check-out station. Process must be confirmed with successful scan following removal that (a) does not identify the ID as missing if not scanned, and (b) identifies the RFID as unexpected if it is scanned.

02/01/13 LEF; CMV

3.3 TEST APPROACH(S)The tests in this section will be performed with production units and components in a simulated environment. The RFID tags will be scanned into a cloned database but will not be physically attached to cages. This allows for testing with minimal space necessary. The “rooms” will be identified by a radial dimension of space around the RFID and not physically implemented.

3.4 TEST PASS / FAIL CRITERIAThe product must meet all of the specified functional requirements. If it fails to perform on any one of the above tests, the system must generate an error that would notify the user. Error generation should occur less than 10% of the time.

3.5 TEST DELIVERABLESSatisfactory performance on the above tests must be documented sufficient to allow future team members to clearly discern how the test was performed, the bounds of each respective test, the performance on each test iteration, as well as the performance on the successful tests. This documentation should be made available to all team members, and may be made available to the customer at their request.

of 11For ECE 401 – 2012-2013


4 USER ACCEPTANCE TESTING4.1 TEST RISKS / ISSUES

This product must facilitate ease and efficiency of use by the animal laboratory staff with minimal re-training, and minimal interruption to work-flow.

1. This product should be intuitive for users accustomed to the Granite/Topaz software & card-cage system currently in use.

2. If an entry is made in error, it must be quickly and easily reversible to minimize work-flow impact.

3. Users should be able to adopt this product with 2 hours or less of re-training.

4. Issues that arise during use should be addressable with the assistance of a user instruction packet.

5. This product should fit into the current card-cage life cycle without disrupting or altering the sequence of protocol development, card cage assignment, periodic billing, and card cage retirement.



Untrained Acceptance

With the aid of a lab volunteer, test the staff's ability to adopt the product without re-training, in order to assess whether it is intuitive, in reference to 4.1-1.

12/15/12 – 02/01/13

CMV; LEF

Error Correction – Intuitive

With the aid of an untrained lab volunteer, test the staff's ability to navigate error correction features if a faulty entry is entered, in reference to 4.1-1; 4.1-2.

01/15/13 – 02/01/13

CMV; LEF

Error Correction – Instruction

With the aid of a trained lab volunteer, with access to the user instruction packet, assess the ease of error correction, in reference to 4.1-2; 4.1-3; 4.1-4.

02/01/13 – 02/15/13

CMV; LEF

Training With the aid of a lab volunteer, assess their ability to adopt the product for a simulated life-cycle following a training meeting. In reference to 4.1-3; 4.1-5.

02/15/13 CMV; LEF

Integration Using a simulated lab environment and cloned database, at 20% capacity or greater, simulate the entire life-cycle, generating all billings and other documents that would be expected in the normal life-cycle. Ensure that, with the initial training and access to the user instruction packet, staff can operate without disruption to the work-flow. In reference to 4.1-5.

03/08/13 CMV; LEF

of 11For ECE 401 – 2012-2013


4.3 TEST APPROACH(S)Items in 4.1-1:4 can be tested with a simulated environment that need not include cage cards. However, to assess the disruption to work-flow, it will be necessary that the simulation includes RFIDs located in cage-card holders, and on a rack, as would be expected in a laboratory environment. The volunteers will be given the equipment, which has been set up by the team, as well as any training appropriate for the given test. They will then be asked to perform a sequence of tasks (such as a billing census & generate a billing statement), and will subsequently be asked to comment on the process.

4.4 TEST PASS / FAIL CRITERIASuccessful completion of these tests requires two elements. The product must perform according to the functional requirements, and must also be acceptable to the users testing the system.

4.5 TEST DELIVERABLESIn addition to documenting the results of these tests from a design perspective, the team should document and retain the user experience, to include a description of the user (i.e. their familiarity with the current system, level of instruction on the new system), their evaluation of the product, and notes on whether and to what degree they accessed the user instruction packet. In combination with their evaluation and success with the product, this will aid in determining the effectiveness of the user instruction packet.

4.6 TEST ENVIRONMENTAL / STAFFING / TRAINING NEEDSThese tests will require the assistance of individuals who are trained in the system currently in use by the animal laboratory, but initially unfamiliar with the product offered by this project. Later tests will require the assistance of volunteers who have been trained on the product. These tests must be coordinated carefully as there is a small number of individuals at the labs. Once the few individuals at the lab have been trained on the new product, there will not be others available to serve as 'untrained' individuals. Therefore, the team should be careful not to proceed to a subsequent test until they are adequately satisfied with performance of a previous test, and can be assured that they will not hinder one test by commencing the next. The tests listed in section 4.2 are in sequential order for that purpose.

of 11For ECE 401 – 2012-2013


APPROVALThe undersigned acknowledge they have reviewed the Electronic ID for Inventory document and agree with the approach it presents. Any changes to this Requirements Definition will be coordinated with and approved by the undersigned or their designated representatives.

Signature: Date:Print Name: C. Melissa VetterlingRole: Team Member

Signature: Date:Print Name: Luke Engelbert-FentonRole: Team Member

Signature: Date:Print Name: Dr. Ali PezeshkiRole: Team Adviser

Digital copy of signatures shall be treated the same as originals.

of 11For ECE 401 – 2012-2013

Luke Engelbert-Fenton (Oct 22, 2012)Luke Engelbert-Fenton

Oct 22, 2012

Ali Pezeshki (Oct 23, 2012)Ali Pezeshki Oct 23, 2012

Claire.Vetterling

Stamp

Claire.Vetterling

Typewritten Text

22 Oct 2012

Claire.Vetterling

Typewritten Text




Appendix A: ReferencesThe following table summarizes the documents referenced in this document.

Document Name and Version

Description Location

ECE401 EIDI Project Plan Rev 3

Project plan including requirements, team members and timeline.

Electronic ID for Inventory (under Documents tab)

of 11For ECE 401 – 2012-2013

http://www.engr.colostate.edu/ece-sr-design/AY12/inventory/index.shtml

ECE401 EIDI Test PlanEchoSign Document History October 23, 2012

Created: October 22, 2012

By: C. Melissa Vetterling ([email protected])

Status: SIGNED

Transaction ID: PC9DEUXP464NX7

“ECE401 EIDI Test Plan” HistoryDocument created by [email protected] 22, 2012 - 12:20 PM PDT - 71.218.16.226

Document emailed to Luke Engelbert-Fenton ([email protected]) for signatureOctober 22, 2012 - 12:27 PM PDT

Document viewed by Luke Engelbert-Fenton ([email protected])October 22, 2012 - 12:28 PM PDT - 24.8.179.152

Document esigned by Luke Engelbert-Fenton ([email protected])October 22, 2012 - 12:30 PM PDT - 24.8.179.152

Document emailed to Ali Pezeshki ([email protected]) for signatureOctober 22, 2012 - 12:30 PM PDT

Document viewed by Ali Pezeshki ([email protected])October 22, 2012 - 1:53 PM PDT - 129.82.151.130

Document esigned by Ali Pezeshki ([email protected])October 23, 2012 - 12:29 PM PDT - 129.82.151.130

Signed document emailed to Ali Pezeshki ([email protected]), [email protected] and LukeEngelbert-Fenton ([email protected])October 23, 2012 - 12:29 PM PDT