Verification and Validation Plan

Version 1.0
25 February, 2005

Moki Team Home Page

Table of Contents

1.0 Introduction
1.1 Purpose of this Document
1.2 Scope of the Development Project
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview of Document
2.0 Reviews, Walkthroughs, Inspections, and Audits
2.1 Procedures for Reviews, Walkthroughs, Inspections, and Audits
2.2 Schedule of Reviews, Walkthroughs, Inspections, and Audits
3.0 Component test plans and procedures
3.1 Component test strategy overview
3.2 Test group for all components

3.2.1 Test group for all components: Content
3.2.2 Test group for all components: Access Restriction
 3.2.3 Test group for all components: Database Modification Interfaces
 3.2.4 Test group for all components: User Limit
 3.2.5 Test group for all components: Accessibility
3.2.6 Test group for all components: Database Availibility
 3.2.7 Test group for all components: Browser compatibility
4.0 System Test Plans and Procedures
4.1 System Test Strategy Overview
4.2 Code Verification
4.3 Link Integrity
4.4 System Connectivities
4.5 Function Verification
5.0 Defect Tracking Plans
6.0 Traceability from SRS to SDS
7.0 Test-Requirements Cross-Reference Matrix
8.0 Acceptance Test and Preparation for Delivery
8.1 Procedure By Which The Software Product Will Be Acceptance Tested
8.2 Specific Acceptance Criteria
8.3 Scenario By Which The Software Product Will Be Installed

Change Log


1.0 Introduction

1.1 Purpose of this Document

The purpose of the Verification and Validation Plan is to allow the testers and implementers to ensure that the project meets the needs and expectations of the client. This document will outline the testing plans.

1.2 Scope of the Development Project

We are designing RivX, some software to be used by outdoor recreational expedition businesses for scheduling expeditions and storing data relating to those expeditions and the customers of the business.

1.3 Definitions, Acronyms, and Abbreviations

Event  The system manages events for outdoor recreation companies. These events could include a river expedition, hiking tours, bike tour, backpacking trip, etc.
Java An object oriented programming language designed for portability.
JavaBeans Certain types of Java classes that allow for simple access of data members.
JSP JavaServer Pages. Provide simple development of HTML web pages with Java programming language functionality.
MokiMac  A river expedition company whos needs inspired our project. MokiMac website
MySQL The type of database server and database communication we will be using.
Page A web page, part of our system that represents a different section of the system.
RivX  The name of our system inspired by MokiMac River Expeditions Inc.
Servlet A class of the Java programming language that provides efficient web server application design.
SDS Software Design Specification.
SQL A programming language that allows user to read, write, or remove data in a database.
SRS Software Requirements Specification 
Web-based Parts of the system that can be accessed through the Internet via a web browser.
VVP Acronym for the Verification and Validation Plan

1.4 References

We will draw on the experience of past team projects, courses, and professional work. Our team has and will use the following resources for process guidelines in defining software requirements:

Courses:

  • CS 3500 - Software Practices
  • CS 3960-01 - Team Software Engineering
  • CS 6961 - Designing Complex Software

Books and Articles:

People:

  • Quist, Richard & Annie. Industry, Requirements, and Customer consultants. MokiMac River Expeditions.
In creation of this document, we also referenced a previous document of our own:

1.5 Overview of Document

The Verification and Validation Plan is organized into nine sections: the introduction and overview, the reviews, walkthroughs, inspections, and audits, the component test plans and procedures, the system test plans and procedure, the defect tracking plans, the traceability from SRS to SDS, the test-requirements cross-reference matrix, the acceptance test and preparation for delivery, and additional information. Section three details the overview of component tests and the component test case descriptions. Section four details the overview of the system test strategy and the system test case descriptions. Section eight is divided into three parts. Section 8.1 discusses the procedure by which the software product will be acceptance tested. The specific acceptance criteria is detailed in section 8.2. In section 8.3, the scenario by which the software product will be installed is described.
back to table of contents

2.0 Reviews, Walkthroughs, Inspections, and Audits

2.1 Procedures for Reviews, Walkthroughs, Inspections, and Audits

For any document, we will follow the process described in section 2.2, the organizational structure.  We have clearly defined roles for the documentation, namely: content manager, style manager, reviewer, and quality assurance.  The documentation will be created by each member of the team, and then it will go to the content manager to ensure all required information is present.  The style manager will ensure that it is consistent with the required format and is well-organized.  This draft will then be delivered to the reviewer to ensure well-written work, and finally, it will be reviewed again to ensure the overall document is up to par.

Throughout the development of the software, we will each review other team members?work.  The developer will provide other team members with a walkthrough of the progress he has made.  At this point, a review team will inspect the portion of the software being reviewed, and inform the developer of the results.  At this time, they will report any defects or problems each week as progress continues on the project.

We will have three releases of our project, alpha, beta, and final.  For each of these releases, an audit will be conducted by an outside source (i.e., not a member of our team).  This objective feedback will allow us to make any necessary corrections and changes (in the first two releases) to provide the best possible solution for our client.

2.2 Schedule of Reviews, Walkthroughs, Inspections, and Audits

The document review process will take place a few days prior to the specific document’s due date.  We will be prepared to provide more extensive reviews (more than our planned review process) if the document requires.

Our tentative plan is to have a walkthrough every two weeks.  This is flexible as need arises to perform either a greater or lesser number of these walkthroughs with other team members.  This will be determined by the individual developers or based on feedback from the entire team.

With each walkthrough, we will have an inspection, as described in the review process in the previous section.  As with the walkthroughs, either the developer or the team can determine that either more or less inspections are necessary.

There are three scheduled audits throughout the semester. The first audit will be conducted on the alpha release of the project by March 11. The beta version of the project will be audited by April 1, and the audit on the final release will be completed by April 22.

back to table of contents

3.0 Component Test Plans and Procedures

3.1 Component Test Strategy Overview

Testing process:

  • Phase 1: Verify that the webpage contains correct content
  • Phase 2: Verify that user has to log in to access pages which modify the database
  • Phase 3: Verify that the user can easily maintain the information stored in the database
  • Phase 4: Verify that 4-8 user can connect to the website at the same time
  • Phase 5: Verify that the website can be accessed at any time
  • Phase 6: Verify that access to database is available from the web server
  • Phase 7: Verify that the website is compatible with listed browsers

Requirements traceability:

All webpages must meet the following requirements:
  • Must contain appropriate content (SRS sections 3.2.1 through 3.2.6)
  • Only people with the access key will be able to edit the database (SRS section 3.4)
  • The Program should be easily maintainable (SRS section 3.4)
  • 4-8 can connect to the site at the same time (SRS section 3.3)
  • Access to the website can be at anytime (SRS section 3.4)
  • Access to database must be available from the web server (SRS section 2.5)
  • Must be compatible with listed browsers(SRS section 2.5)

Items or components tested:

  • "Trip" page
  • "Billing" page
  • "Schedule" page
  • "Employee/Guide" page
  • "Customer/Party" page
  • "Equipment" page
  • "Login" page

Testing schedule and resources:

  • The testing schedule will be known in the future.  Testing will use the following resources:
    • Testing team
      • Johnathan Cazier, Shawn Crabb, Kyungseog Oh, Gib Reimschussel
    • Resources 
      • SRS, VVP Documents

Test recording procedures:

  • The test results will be recorded as a webpage and a simple text file.  The simple text results will be from a team member recording results of a checklist.

Software requirements:

  • Compatible Internet Browser

Constraints: None

3.2 Test Group for all components

Test case group identification
 Test case group 3.2:
This test case group applies to the following components:
  • All webpages on the Moki Team Project website
Features to be tested

 

  • Must contain appropriate content (SRS sections 3.2.1 through 3.2.6)
  • Only people with the access key will be able to edit the database (SRS section 3.4)
  • The Program should be easily maintainable (SRS section 3.4)
  • 4-8 can connect to the site at the same time (SRS sections 3.3)
  • Access to the website can be at anytime (SRS section 3.4)
  • Access to database must be available from the web server (SRS section 2.5)
  • Must be compatible with listed browsers(SRS section 2.5) grammar (SRS section 3.5)
Testing approach
 Test case strategies and techniques:
  • Content will be checked by ensuring all components listed in SRS sections 3.2.1 through 3.2.6 are included in the website
  • Access to the website will be ensured by ensuring that anyone accessing the website will be required to login with a valid username and password before accessing any other web pages in the site
  • Maintainibility will be shown by whether or not the user can modify the database through the interface provided on our website
  • To check that 4-8 users can connect to the site at the same time we will have at least 4 machines with 4 people try to connect to our site at the same time
  • To check that access to the website can be at anytime we will try accessing the website at various times during the day
  • To check that the database is available from the web server we will execute one the interfaces on the website that requires connecting to the database
  • Browser compatibility will be determined with the aid of a checklist of required browsers.  This test will be conducted through manual testing.
Analysis methods:  The results will be used to determine whether or not our website is accessible to the right people at the right times, with the necessary content.

Test case rationale:  Webpages have many issues with accessing the website at anytime and also having access to the database at anytime, and that access should be restricted to a certain set of users.
Pass/Fail criteria
 The following criteria must be met for each webpage tested:
  • All content listed in SRS sections 3.2.1-3.2.6 can be found on the website
  • Login is requried to access webpages on the site
  • Interfaces are provided to modify the information in the database
  • At least 4 users to connect to the website at the same time
  • Website must be accessible at one time in the morning, one time in the afternoon, and one time in the evening
  • When executing an interface on the website that uses the database, the connection will be successful and will return the appropriate results
  • Each webpage must be compatible with the browsers given in the checklist.
 

3.2.1 Test case for all components: Content

Input
 All webpages included in the website
Output
 All components listed in SRS 3.2.1-3.2.6 are found on the website
Environment
 The compliance test will take place on the Internet through a web browser
Special procedures

N/A
Precedence and dependencies
 Webserver and database server are both running and accessible. 
References
 N/A


3.2.2 Test case for all components: Access Restriction

Input
 Login web page
Output
 User is only allowed to access other pages if login was accepted
Environment
 The compliance test will take place on the Internet through a web browser
Special procedures
 N/A
Precedence and dependencies
 Webserver and database server are both running and accessible. 
References
 N/A


3.2.3 Test case for all components:  Database modification interfaces

Input
 All webpages included in the website
Output
 Interfaces are provided to modify the information in the database
Environment
 The compliance test will take place on the Internet through a web browser
Special procedures
 N/A
Precedence and dependencies
 Webserver and database server are both running and accessible. 
References

N/A


3.2.4 Test case for all components: User Limit

Input
 N/A
Output

At least 4 users can use the website at the same time without any conflicts
Environment

The compliance test will take place on the Internet through a web browser

Special procedures
 N/A
Precedence and dependencies
 Webserver and database server are both running and accessible. 
References

N/A



3.2.5 Test case for all components: Accessibility

Input
 All webpages in the website
Output
 Website is accessible at one time in the morning, one time in the afternoon, and one time in the evening
Environment
 The compliance test will take place on the Internet through a web browser
Special procedures
 N/A
Precedence and dependencies

N/A
References

N/A



3.2.6 Test case for all components: Database Availibility

Input
 All webpage on the website
Output
 All webpages that use a database connection will be successful
Environment
 The test will take place on the Internet through a web browser
Special procedures
 Each webpage will be viewed in a web-browser and its properties will be compared against the above checklist.
Precedence and dependencies
 Webserver is running and accessible. 
References
 N/A


3.2.7 Test case for all components: Browser compatibility

Input
 All webpages in website
Output
  • The following list shows several browsers with which the website must be compatible:
    • Mozilla 1.3.1 and up
    • Netscape Navigator 6.0 and up
    • Internet Explorer 5.0 and up
Environment
 The test will take place on the Internet through each listed web browser
Special procedures
 Each webpage will be viewed by each web-browser in the above list. 
Precedence and dependencies
 Internet connection and listed browsers available
References
 N/A

back to table of contents

4.0 System Test Plans and Procedures

4.1 System Test Strategy Overview

Our basic test strategy is trial and error. Since we are creating web based application, we will simply test system by giving inputs to the fields, and clicking the links.We will also demo our first version of system to client and get feedback on the system to make that it conforms to the client's specifications.

The system is composed of multiple components. Each component must be working correctly, and must be able to interact with all of the other components for the system to function properly.

Testers will record the date and the environment they use to test the product, including hardware, operating system, and web browser. For each test, testers will also record the test number, procedure followed, expected result, whether the test passes, and if the test fails, a failure description.

Minimum system requirement is Windows O/S above 98 with Microsoft Internet Explorer or Netscape Navigator. Also there must be web server and database server that can be connected from local machine. 

The format for test groups is noted below:

Module Type Type(s) of module to which the test applies
Purpose/Function Purpose of the test
Test Procedure Actions taken by the performer of the test
Expected Result Expected outcome of test procedure

4.2 Code Verification

Module Type Code files, including HTML, Java Servlets, and JSP
Purpose/Function To ensure the correctness of the code
Test Procedure Inspect code and/or use validation tools to check correctness of code
Expected Result Valid codes

4.3 Link Integrity

Module Type Links
Purpose/Function To ensure links are correct
Test Procedure Click each link to navigate through the system
Expected Result Each link connects to the intended location

4.4 System Connectivities

Module Type Connection with web and database server
Purpose/Function To ensure connection is set up with application
Test Procedure

Input values in the field and check whether the input is correctly submitted to database
Retrieve customer, trip, and employee information from database, and check whether they are correctly received
Expected Result Request and Retrieve action to database work properly

4.5 Function Verification

Module Type Functionality of each page
Purpose/Function To ensure each page works properly as intended
Test Procedure

Create bogus info and submit to database
Retrieve information from database
Schedule trips with given customer and trip information
Expected Result Each link connects to the intended location

 
back to table of contents

5.0 Defect Tracking Plans

Finding Defects
To ensure quality in the product, the team must be able to find and be notified of defects. We have configured the Tomcat server to log the maximum debugging information during development and will investigate these logs as needed. We also configured the system to send the team an email when Exceptions are thrown with the error information.

Tracking and Prioritizing
All defects will be tracked in an HTML file in a table with the following columns: Priority, Description, Date Found, Found By, Date Resolved, Resolved By.

  • Severity 1 / Critical - The defect must be addressed immediately -- the whole system is compromised by it and may slow development. exist.
  • Severity 2 / High - The defect is several but isolated to a tier or sub section of the system. Development will only slow in this section.
  • Severity 3 / Medium - The defect must be addressed before the product can be delivered, but will not slow development.
  • Severity 4 / Trivial - These defects will be resolved as time permits.
back to table of contents

6.0 Traceability from SRS to SDS

Description SRS SDS

Managing trip scheduler, guide, and event.

3.2.1 Manage the details of an event; i.e. river expedition, hiking tour, etc.

 3.2 Trip Class
3.5 Guide Class
3.6 Boat Class
3.9 Trip Page

Manage customer informations.

3.2.2 Manage the details of an event participant (customer)

3.4 Customer Class

Print reports for various purpose from company side.

3.2.3 Print various reports

3.7 Hours Worked Class
3.8 GenerateReports Class
3.12 Employee/Guide Page

Print billing information for each trip.

3.2.4 Print invoices for billing

3.8 GenerateReports Class
3.10 Billing Page

View and Schedule events.

3.2.5 Provide a view of scheduled events

3.11 Schedule Page

Email events to customers

3.2.6 Email event participants (customers)

3.4 Customer Class
back to table of contents

7.0 Test-Requirements Cross-Reference Matrix

The following table, known as the test-requirements cross-reference matrix, shows how every requirement listed in the SRS will be tested.

Requirement Identifier
 Requirement Description
 Requirement Test Method
 Requirement Variables
 Requirement Variable Ranges
 Requirement Functionality
 Comments
SRS sections 3.2.1 through 3.2.6 Must contain appropriate content inspection and demonstration N/A N/A Necessary Funcitonality N/A
SRS section 3.4 Only people with the access key will be able to edit the database
 inspection and demonstration N/A N/A Security  N/A
SRS section 3.4 The Program should be easily maintainable inspection and demonstration N/A N/A Maintainance N/A
SRS section 3.3 4-8 can connect to the site at the same time
 inspection and demonstration # users connecting 4-8 Ensures a minimum of 4-8 can connect at the same time
 N/A
SRS section 3.4
 Access to the website can be at anytime inspection and demonstration N/A N/A Accessibility N/A
SRS section 2.5
 Access to database must be available from the web server inspection and demonstration N/A N/A Database Availibility N/A
SRS section 2.5
 Must be compatible with listed browsers
 inspection and demonstration N/A N/A Browser Compatibility N/A

back to table of contents

8.0 Acceptance Test and Preparation for Delivery

8.1 Procedure By Which The Software Product Will Be Acceptance Tested

The team will follow the following for declaring the system complete:
  • The team will ensure the system adheres to the design specifications in the SRS and SDS documents.
  • All defects reported (see section 5.0 of this document) will be resolved or acceptable work arounds found.
  • We will develop our product through several milestone versions to find and correct any defects in our product.
  • Moki Mac will view the products during various stages of development and we will refactor as required.

8.2 Specific Acceptance Criteria

Moki Mac has determined the following requirements for the system:
  • The product should have a similar user flow the client's existing system and provide the same functionality.

The team has the following additional goal:
  • Improve the usability over the existing system by providing a single menu from which to perform system tasks.

8.3 Scenario By Which The Software Product Will Be Installed

The software will be installed on a Linux or Apple server by a member of the team. The client will need no additional software installed since the system is accessed through a web browser.
back to table of contents

Change Log

version date description
1.0 25 Feb 2005 -The Verification and Validation Plan document is created.
back to table of contents