|
|
Stage1
VVR 3/14/08
1.0 Introduction and Overview
1.1 Purpose of this Document
The purpose of this document (Verification and Validation Results, VVR) is to describe the results acquired from the VVP document, and to give the results acquired from testing our system.
1.2 Scope of the Development Project
Team Diamond-Cutters will develop a database application which consists of a graphical user interface deployed through a web browser. The user interface will send queries to a database managed by Microsoft Access and return the corresponding queried data. Such requestable data includes: valet packets, car information, and customer information. This information in return will assist valet works at Diamond Airport Parking manage and assist customers.
1.3 Definitions, Acronyms, and Abbreviations
- DAP - Diamond Airport Parking
- GUI - Graphical User Interface
- UI - User Interface
1.4 References
- Core Servlets and Java Server Pages, Vol. 1: Core Technologies, Second Edition by Marty Hall, Larry Brown
- Microsoft Office Access 2003 for Dummies: by John Kaufeld
- VVP Document - stageI
- Project Plan Document - Plan
1.5 Overview of Document
This document is a summary of the testing scheme established by the VVP. This document also reviews the outcome carried out by each test, evalutates our testing process, and summarizes any issues in the defect report. (more details in Reviews, Walkthroughs, Inspections, and Audits)
2.0 Summary of Results
We tested the entire Stage1 release of the DAP suite, and have found that each module functioned accordingly. Thus we can summarize that no major defects exist in the system. As a result our Stage1 release of the DAP suite has been very successful and working to the degree of our original plans.
3.0 Results from review, walkthroughs, inspections, and audits
We didn't have any formal walkthroughs, but every week at group meetings we review the progress made on the DAP suite and ensure that it is progressing as planned. Our team leader inspects the code regularly ensures that it meets criteria, and all known problems are dealt with. As a result our Stage1 suite is a reflection of all the goals we have planned for this initial release.
4.0 Results from testing
4.1 Summary of component test
- As we developed the DAP suite we tested each module. It was difficult to test each module individually since our project has many dependencies on other components. As a result we employed the test as you build strategy described by our VVP.
- Along the way we also adopted a new testing tool which was introduced to our group. This tool, Selenium IDE is a plug-in for web browsers. It automatically writes javascript during the runtime of a project. For example as we enter in credentials to the login page these fields would be recorded inside Selenium and then allows this code to be automatically re-used when the opened again. We used Selenium to test all of the other modules and didn't find any problems.
| Component | Setting | Who | How Long | Comments | Problems | Work not Completed |
| User Interface | In Process | Spencer | 10 hours | User Interface could use some touch up and some "wow" factor | none | none |
| Packets | Database | Chris | 5 hours | Multiple accounts are not supported, however this did not cause any problems insofar | see comments | none |
| Database | Database | Kem | 10 hours | Database is awesome | none | none |
4.2 Summary of integration test/testing product as a whole
- Group-Demo Testing: Similar to end-user-testing. When the project was first put together and prepared for initial launch Kem presented the suite to our group and navigated his way through all the modules and invoked all of the different modules as listed in the VVP. At the time no bugs or major problems were encountered.
| Component | Setting | Who | How Long | Comments | Problems | Work not Completed |
| All Components | The Suite | All Members | 10 hours | none | Issues with switching database from Derby to Access; Issues with calendar buttons | Calendar buttons not resolved |
5.0 Evaluation of the process
This section will allow you to reflect on how well your team's testing process worked.
5.1 Evaluation of test cases
Test were thorough and eye opening. We found issues mainly in integration with database control and using the application on different browsers, i.e. calendar buttons do not work sometimes. We need more tests from non group members and actual DAP employees. Also, more stress testing of the data fields would be nice.
5.2 Results from defect tracker
We have not used the defect tracker much, because we have not come across any defects major enough to report. When there are defects found, we will post the information about the defect in the defect tracker, which will give information about the defect.
5.3 Lessons learned
Since we have not encountered any major problems with this initial release, we feel the project is headed in the right direction. However we were recently introduced to Selenium IDE which is a web browser plug-in. We feel that with this new testing device, the time spent testing could be greatly reduced. Since most of the tests are created by the end-user and is tracked by this plug-in. In return Selenium would write tests for us so we can do automated testing.
6.0 Outcome of acceptance test and delivery
So far only group members have tested the suite. In the future we will allow DAP employees to try their best to break our best and give us their feedback. We will add another section so the DAP user can input bugs/feedback.
7.0 Summary of open issues
Only two issues are still open:
- Calendar Buttons - In some browsers the calendar buttons do not behave like they should, e.g. the months do not change. This is currently being resolved by Kem and he will fix it in the near future.
- Database Integration - Changing from Derby to Microsoft Access has been a more difficult task than originally planned. However, we are working hard to get Access compliant, we are Derby compliant thus far.
8.0 Additional Information
N/A
Sign in to add a comment