VVP
1. Introduction and Overview
1.1 Purpose of this Document
The purpose of the Verification and Validation document, is to provide a plan for testing of the eWallet project.
1.2 Scope of the Development Project
This project implements an electronic wallet. A smart card is used to
electronically implement various functions of a normal wallet. It can
contain driver's license information, credit card account information
(so that credit card purchases may be made with it), an electronic
cash purse that functions similar to the University of Utah ID card,
medical insurance information, and more. In order to view information
on the eWallet or use the eWallet to make a purchase, the cardholder
will first need to authenticate via a biometric or PIN.
Along with consolidating all your cash, credit cards, drivers license,
medical insurance cards, etc onto one card - all of the functionality
is now protected with a fingerprint or PIN number. If the eWallet is
lost or stolen, the theif will not be able to gain access to any of
the stored information. This is a huge advantage to carrying a
conventional wallet where cash, credit card numbers, and personal
information (ssn, address) are easily aquired when the wallet is lost
or stolen.
1.3 Definitions, Acronyms, and Abbreviations
| Term |
Definition |
| eWallet |
Electronic Wallet |
| Java |
programming language designed to develop applications, especially ones for the Internet, that can operate on different platforms |
| POS |
A business or place where a product or service can be purchased. |
| Smart Card |
A plastic card containing a computer chip and enabling the holder to purchase goods and services, enter restricted areas, access medical, financial, or other records, or perform other operations requiring data stored on the chip. |
| SRS |
Software Requirements Specification |
| SSN |
Social Security Number |
1.4 References
1.5 Overview of Document
This is the Verification and Validation Plan for eWallet
by Team Silent Mission.
- Section 1.0
of the document introduces the purpose of the document, presents
terminology and references that will be used in the project
documentation, and defines the scope of the project.
- Section 2.0
of the document updates the planning for reviews, audits, and
walkthroughs.
- Section 3.0
of the document describes the test planning for individual software
components. This section will describe the expected behaviors.
- Section 4.0
of the document describes the testing for the eWallet project
as a whole.
- Section 5.0
of the document discusses the procedures for defect tracking.
This includes a brief discussion of the too, the team's procedures
for reviewing defect reports on a regular basis, and the team's
process for assigning responsiblility for a defect to specific
individuals. This section also discusses severity codes.
- Section 6.0
of this document discusses traceability from SRS to SDS. This
section is used to show the specific connections betwween the SRS
and SDS.
- Sectiton 7.0
of this document is the test-requirements cross-reference matrix,
which shows how every requirement listed in the SRS will be
tested.
- Section 8.0
of the document discusses the acceptance test and preparation for
delivery.
2. Reviews, walkthroughs, inspections, and audits
We will periodically have meetings, walkthroughs, and audits. We will review previous documentation and results from weekly changes to examine our progress. We will compare this progress to the mandated milestones and adjust accordingly. During the meetings, we will also evaluate the quality of current products.
Before a document is due, our team will meet to review content and provide feedback to each other. This will help ensure the best quality document that we can provide. When possible we will utilize outside sources to review our documentation.
When we begin to develop the software, our technical leader will provide all team members with a walkthrough of his/her work. After a walkthrough, a review team will run inspections on the product. The review team will record the results and inform the technical leader weekly of new defects.
There are three scheduled releases for our team project.
Reviews for our documents will take place within a week prior to the due date. If need be, we will schedule more reviews to ensure a quality product.
Walkthroughs will take place about every two weeks. This schedule is very tentative however due to unforeseen technical problems that could arise. More walkthroughs may be needed as required by the technical leader.
Inspections of the software will initially take place about every two weeks. As with the walkthroughs, more inspections may be run if the team feels fit.
There are three scheduled releases of the project throughout the semester. The first release will be conducted by March 11. The second release of the project will be audited by April 1. The last release will be conducted on the final version of the project by April 15. The final audit will be scheduled April 28.
3. Component test plans and procedures
This section describes the test planning for each of our individual components. Any time the actual output of a test case does not match the expected output, the team will create an incident report within the defect tracker.
3.1 Component Test Strategy Overview
- Testing Process: Each of the individual components will be thorougly tested and then as they are integrated together another level of testing will be done to ensure integration was successful. Unit tests derived from the testing process will be saved and re-run as components are extended and integrated.
- Requirements Traceability: Test cases will be built upon requirements defined in the SRS to ensure all outlined requirements are successfully met.
- Items or Components Tested: The POS and Banking components will initially be tested together, and the biometric authentication will initially be tested by itself, as will the enrollment component, medical data, and insurance information.
- Testing Schedule and Resources: Each individual component will be tested after it's completion, and once it is integrated with other components the new component system will then be tested again to assure everything is linked properly.
- Test Recording Procedure: We will store/save our unit tests as a record of testing.
- Hardware and software requirements: We must test our banking application/applet against various browser distros, as well
3.2 Component Test Group: Card Transactions
- Test case group identification
This test group encompasses transactions made to the card: adding or spending
eWallet cash, adding/editing/removing credit card transactions, as well as
retrieving credit card account information for a purchase.
- Features to be tested
Successfully debiting and crediting the cash purse on the card. Adding, removing,
and editing the credit card accounts stored on the card, and retreiving credit
card account information, as well as current amount of electronic cash available.
- Testing approach
- Strategy: Test each individual test case everytime a modification is made to the card component with the theory
being that if we run through all our test cases every time we modify we will catch any bugs/errors that may affect
components unexpectedly.
- Pass/Fail criteria
Tests pass if the card reflects the correctly modified amount, and fails if any other amount is reported. With respect to credit card accounts if the card correctly reports back the credit card accounts and their correct information this is a pass - in any other case the test has failed.
- Individual test cases:
- Credit eWallet Cash
- Debit eWallet Cash
- Add credit card account
- Delete credit card account
- Modify credit card account
3.3 Component Test Group: Database Connection
- Test case group identification
The database connections are made when user wants to add money to their eWallet.
A database connection is made to retreive their current bank balance.
- Features to be tested
Logging into the database via a browser applet
- Testing approach
- Strategy: Test each individual test case everytime a modification is made to the card component with the theory
being that if we run through all our test cases every time we modify we will catch any bugs/errors that may affect
components unexpectedly.
- Pass/Fail criteria
Can the browser applet (assuming a network connection) connect to the db? Can username
and password validation happen successfully? Can data successfully be queried?
- Individual test cases:
- Applet connects to remote database
- Correct username and password will successfully log into db
- Incorrect username and password will give error message and not log in
- Once logged in - account data can be successfully queried via the browser applet.
3.4 Component Test Group: Fingerprints
- Test case group identification
Any kind of authentication with our system takes place with biometrics stored on
the eWallet.
- Features to be tested
Fingerprint capture and authentication
- Testing approach
- Strategy: Test each individual test case everytime a modification is made to the card component with the theory
being that if we run through all our test cases every time we modify we will catch any bugs/errors that may affect
components unexpectedly.
- Pass/Fail criteria
Can a fingerprint scan be stored correctly? Can it be read back correctly? And
can we perform a match with another scan?
- Individual test cases:
- Scan fingerprint/be able to capture scan from fingerprint reader
- Store fingerprint successfully onto eWallet
- Perform a match of fingeprint scan stored on card with a new scan captured
from a reader
3.5 Component Test Group: Photo and Personal Information
- Test case group identification
These tests are for the component responsible for capturing, storing, and reading
back a photo and the user's personal information (name, address, medical information,
drivers license information, etc).
- Features to be tested
Photo capture, text information capture, storing this information on eWallet
and being able to retrieve it back.
- Testing approach
- Strategy: Test each individual test case everytime a modification
is made to the card component with the theory
being that if we run through all our test cases every time we modify
we will catch any bugs/errors that may affect
components unexpectedly.
- Pass/Fail criteria
Can we capture a photo into a file using a digital camera? Can we store this file
on eWallet and then read it back off the card? Can we store and read back personal
informatio we capture in a form and store on the card?
- Individual test cases:
- Capture image onto harddrive with digital camera
- Compress image
- Store image on eWallet and read back off card
- Capture text data using a form
- Store text data on card and read back off card
4. System test plans and procedures
This section describes testing the software product as a whole
4.1 System Strategy Overview
Testing will occur during each stage of development. As new components are added or linked all tests for those components will be re-run, along with any new tests (to test component linkage) to assure as we progress in development we handle all problems as they are introduced, rather than at the end. Tests have been defined for each requirement and whether or not these tests are successful will determine if the requirement has been statisfied. Tests will be stored in the CVS repository so they are easy to rerun for anyone working on a particular component. An index file of each test and what it does will also be available.
Hardware requirements include the hardware mentioned in previous documentation: smart card reader, smart cards, digital camera, fingerprint scanner. The Eclipse IDE will serve as the software environment from which we run tests.
4.2 System test case description
The system test cases are build upon the component cases, and successfully running through all component cases (in the order in which they are listed above) will constitute a system test.
5. Defect Tracking Plans
If a defect has been reported, the team member who discovered it
should make sure that the rest of the team is aware of the issue; when
the problem is acknowledged, the team will discuss how to attack the
problem and whom to assign the task.
Multiple reported defects will be handled in a severity order. Each
defect reported should have a severity code attached to it. The codes
are as follows:
- - Severity 1 / Critical - A failure in the product is detected, and a
work-around does not seem to exist.
- - Severity 2 / High - A failure in the product is detected, but a
work-around is possible.
- - Severity 3 / Medium - There is no failure caused by the defect, but
the product produces inaccurate results.
- - Severity 4 / Trivial - There is no failure caused by the defect, and
there is an easy work-around. These defects are often aesthetic change
requests.
Criticals will be handled first, followed by Highs, then Mediums, then
finally the Trivials, down the order.
6. Traceability from SRS to SDS
| Requirement |
SRS |
SDS |
| Card Enrollment |
3.2.2 |
3.3 |
| Stored Value |
3.2.3 |
3.2 |
| Add/Remove Credit Card |
3.2.4 |
3.3 |
| Stored Value Purchase |
3.2.5 |
3.2 |
| Adding Drivers License |
3.2.6 |
3.4 |
| Viewing Drivers License |
3.2.7 |
3.5 |
| Adding Medical Insurance |
3.2.8 |
3.4 |
| Viewing Medical Insurance |
3.2.9 |
3.5 |
7. Test Requirements Cross Reference Matrix
| Identifier |
Description |
SRS |
Test Method |
System Functionality |
|
Card Enrollment |
Allows a user to enter personal, bank, finger and photo information on card and database |
3.2.2 |
Inspection |
Java Swing, Database, Card Technology |
|
Add Stored Value(eCash) |
Add money from a bank account to card |
3.2.3 |
Inspection |
Java servlets, card technology, applets |
|
Add/Remove Credit Card Accounts |
Interface to Add/Remove credit cards from card |
3.2.4 |
Inspection |
Applets, card technology |
|
Stored Value Purchase |
Make a purchase at a store using a POS |
3.2.5 |
Inspection |
Card Technology, POS |
|
Adding Drivers License |
Adds a drivers license to the card |
3.2.6 |
Inspection |
Card Technology, Java Swing |
|
Viewing Drivers License |
Interface to view drivers licnese. |
3.2.7 |
Inspection |
Card Technology, Java Swing |
|
Adding Medical Insurance |
Adds medical infromation to card |
3.2.8 |
Inspection |
Card Technology, Java Swing |
|
Viewing Medical Insurance |
Interface to view medical information. |
3.2.9 |
Inspection |
Card Technology, Java Swing |
8. Acceptance Test and preparation for delivery
8.1 Procedure By Which The Software Product Will Be Acceptance Tested
- - Our product will be tested in accordance with our Validation and
Verification Plan (VVP) to identify errors
- - Our time will ensure that all design specifications are adhered to
in our SRS and SDS documents
- - Each component will be tested first subjectively by the part of the
group that designed the component and then objectively by the rest of
the group
- - After components are tested successfully, then they will be
integrated and each system test will be tested by every member of the
group.
8.2 Specific acceptance criteria
- - A replication of our system and component tests generates correct results.
- - The original requirements are met and represented by all test cases
listed in this report.
- - The webpage's and application's functionality works across multiple
platforms and browsers.
8.3 Scenario by which the software product will be installed
- - A CD will be created to install components that are developed to be
used by a client.
- - The client will also be provided with a URL that points to the parts
of the project that are on the internet.