Verification and Validation Results

Version 3.0
14 April 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 Summary of Results

2.1 Reviews, inspections walkthroughs and audits
2.2 Test Results

3.0 Results From Reviews, Walkthroughs, Inspections, and Audits

3.1 Reviews
3.2 Walkthroughs
3.3 Inspections
3.4 Audits

4.0 Results From Testing

4.1 Summary of Component Test
4.2 Summary of Integration Test / Testing Product as a Whole

5.0 Evaluation of the Process
5.1 Evaluation of Test Cases
5.2 Results From Defect Tracker
5.3 Lessons Learned

6.0 Outcome of Acceptance Test and Delivery
7.0 Summary of Open Issues
8.0 Additional Information

Change Log


1.0 Introduction

1.1 Purpose of this Document

The Verification and Validation Results (VVR) document reflects the results of the various testing activities that are described in the Verification and Validation Plan (VVP) document. The VVR is used to ensure the quality of the product. All team members use this document to evaluate both the product and the process.

1.2 Scope of the Development Project

This project is meant to be a tool to help outdoor recreational expedition companies stay organized and capable of meeting the needs of its customers. Software currently being used is out of date, and needs to be updated. This project will also allow the functionality of customer interaction through the web. Currently, customers cannot interact with the companies through their websites. This will increase business while decreasing the workload of the employees of the company to use this project.

1.3 Definitions, Acronyms, and Abbreviations

JAVA  An object oriented programming language for use with server and jsp pages
Event  The system manages events for outdoor recreation companies. These events could include a river expedition, hiking tours, bike tour, backpacking trip, etc.
MokiMac  A river expedition company whos needs inspired our project. MokiMac website
JSP Java Server Page displays all necessary pages with html and servlets.
RivX  The name of our system inspired by MokiMac River Expeditions Inc.
SDS Software Design Specification
SRS Software Requirements Specification 
Web-based Parts of the system that can be accessed through the Internet via a web browser.

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

Section Purpose
Section 1 Introduction of this VVR document
Section 2 Summary of the testing results as a whole.
Section 3 Results from reviews, walkthroughs, inspections, and audits
Section 4 Results from the testing (for each component)
Section 5 Evaluation of the product as a whole and for each component, including the lessons learned from the testing.
Section 6 The outcome of acceptance test and delivery
Section 7 Summary of the incidents and solutions
Section 8 Additional information (if applicable)
back to table of contents

2.0 Summary of Results

2.1 Reviews, inspections walkthroughs and audits

Reviews have been conducted by each individual team member every time a new feature is created. Walkthroughs are conducted frequently by each individuals and via e-mail messages. Inspections are conducted by each team member.

2.2 Test Results

There was only minor problems that was discovered during testing. All of the other tests completed successfully.
back to table of contents

3.0 Results From Reviews, Walkthroughs, Inspections, and Audits

3.1 Reviews

Since each team member has been working for a subpart of the project, the review process has been performed mainly by sub team members every time they added new features into the product. Also, when it is needed, other members have reviewed the new features and have discussed for improvement. For documentation, all members have reviewed initial versions of the documentation for any errors either in class or by e-mail.

3.2 Walkthroughs

The walkthroughs have been conducted as often as possible either in meeting or by e-mail. After we created new features, all team members addressed their concerns and participated in a run-through procedure in order to ensure functionality of the product.

3.3 Inspections

The inspections have been conducted by all team members. All team members have tested a working version of the product. There need to demonstration to client and get feedback to improve some of functionality and GUI.

3.4 Audits

The audit process have been carried out by Management team each week. The management team have kept checking a progress and TA has evaluated how closely we follow the requirements of the project.
back to table of contents

4.0 Results From Testing

The following are the tests we performed and a description of the results.

4.1 Summary of Component Tests

4.1.1 Content
Test description Verify all required pages are available.
Expected result All pages will be complete
Actual result The following pages have completed:
  • Trips
  • Party
  • Customers
  • Boats
  • Line Items
  • Scheduled Trips
  • Employees
  • Personal Information
  • Reports
  • Reservation 
  • Login/Logout

4.1.2 Access Restrictions
Test description Certain pages and sections of the site are for an administrative user. All pages of the project are meant to only be viewed by those users with accounts (user names and passwords).

The test will be performed by typing the URL to known project jsp's into a web browser's address bar and trying to access administration pages after loggin in as a non-admistrative user.
Expected result The pages accessed without logging in will redirect the user to a log in page. Users logged in without adminstrative rights should not be able to access admistrative pages (will also redirect to a log in page).
Actual result The project jsp pages behaved as anticipated.

4.1.3 Database Modification Interface
Test description All database interactions happen through one Java class (RivXDB) that acts as an interface between the application Java classes and jsp's and the MySQL database.

The class will be tested by running each of the classes functions for SQL INSERT, UPDATE, DELETE, and SELECT statements. The results will be verified by viewing the state of the MySQL database after each function is called. Now that our system is up and running the results can be seen in the updating of our jsp form pages.
Expected result Creating or editing information through the system with reflect the data entered or altered.
Actual result Data persists -- saved to and retrieved from the database as expected.

4.1.4 User Limit
Test description Verify the site works as desired when four users are connected and modifying the same information at once.
Expected result The behavior of the system will be no different that if only one user were access it.
Actual result The system performed as expected.

4.1.5 Accessibility
Test description Webserver is accessible. The server will be visited at various times throughout the day.
Expected result The requested jsp's from the system will be available.
Actual result Our development server has occasion outages because it uses one of our teammeber's home Internet connection that resets speradically. When these resets occur, the connection cannot be restored without authentication.

4.1.6 Database Availability
Test description Verify The database is available at any time so that system's database requests are answered.
Expected result The database will always be available.
Actual result Our development server has occasion outages because it uses one of our teammeber's home Internet connection that resets speradically. When these resets occur, the connection cannot be restored without authentication.

4.1.7 Browser Compatability
Test description Verify the jsp pages look the same in the following browsers:
  • Mozilla 1.3.1 and up
  • Netscape Navigator 6.0 and up
  • Internet Explorer 5.0 and up
Expected result All pages will appear and behave the same in all browsers.
Actual result The pages performed as expected. We suspect with later versions and development of the layout, this goal may become harder to achieve. Does not work with Safari brower.

4.1.8 Feature testing 
Test description Verify the features to support user to work properly: 
  • Input validation to check user input
  • Links to separate pages 
  • Roster report to work properly
  • More fields on customer page
  • Order function 
Expected result All features work properly without error
Actual result All features works properly as expected. Each fucntions are tested by each individuals as we encode functions.

4.2 Summary of Integration Test / Testing Product as a Whole

Based on our tests, we are confident that our application is meeting the requirements outlined in our supporting documents.
back to table of contents

5.0 Evaluation of the Process

5.1 Evaluation of Test Cases

The test cases are all well-defined and have been performed as suggested in the VVP documentation. We tested all aspects of the product including functionality, usability, accessibility and appearance.

5.2 Results From Defect Tracker

All defects are well resolves while developing. No serious defect were found. And it is ready for final release.

5.3 Lessons Learned

Breaking the test cases into components in the VVP was a great way to test the product adequately. Based on the VVP documentation, we tested the product specifically and fixed errors. Since all team members have participated in testing the product, we could be flexible about testing time and procedure. Also, it was good way to test the product in different platform.
back to table of contents

6.0 Outcome of Acceptance Test and Delivery

We developed software based on current system the company is using. We also have screenshots of existing software. Because of that, our product flowes similarly to current one except improved userbility. Because of lack of user interface of current software, we decided to improve that criteria by using web brower. User can easily click each link and button to edit, add, and delete informations. We still need to add more functionalities into the system in later stage.

Our system can be access by using web brower and giving correct URL where our server reside. When we install the system for the company, we need to configure the server and DB setting that their local computer can access the software. Currently our software runs 24/7 by our server.
back to table of contents

7.0 Summary of Open Issues

Not applicable
back to table of contents

8.0 Additional Information

None.
back to table of contents

Change Log

version date description
1.0 10 March 2005 -The Verification and Validation Results document is created.
2.0 1 April 2005 -Modified from version 1.0 for stage 2 release.
3.0 14 April 2005 -Modified from version 2.0 for stage 3 release.
back to table of contents