The Test Plan


Testing Strategy

1.  Primary Testing consisting of:
Unit testing the components of the database to make sure that every part works correctly by utilizing the rootnode.com testing environment to individually test the SQL tables and SQL statements used to modify the database.  Testing each of the requirements listed in the requirements document by using the tests involved for each of the requirements.  Some of the requirements have multiple tests that need to be tested to determine if the requirement was met.
 
2.  Customer testing using beta front-end with:
The Lockheed members are able to test the backend with the front end we provide and the server laptop being up on a static IP address so they are able to test it across the Internet. Students in the group are able to test the database utilizing the same procedures that Lockheed will be using.


Testing Problems

While creating the database we ran into many discrepancies with Lockheed on the requirements.  So we changed the requirements of the database design and the overall system requirements as we progressed through the project to take into account the ever-evolving project.  This pushed off the time available for coding, which in turn pushed off the time where testing was to come into play on the database, since less time was able to be devoted to the testing phase.  Although we were able to test the SQL statements and tables using the rootnode.com testing environment while the actual server and front-end were being coded.  So when either of them was changed the testing environment was changed.

The testing environment allowed us to work with Lockheed and the rest of the group in an online environment without having to meet in person or via a conference call.  This also allows the future groups working on this project to get a good idea of the use cases and SQL commands used in the project so they may design the final front-end accordingly and get a good understanding of what the project is doing.


Testing for Next Semester

This semester we did not have time to actually test the live database on the server or the prototype front-end, although we were able to test the code on Rootnode. The code was tested on rootnode fairly well but the database went through many interations of deveolpment so the latest version(s) were unable to be fully tested. Rootnode is almost fully functional on the use cases with their corresponding actors and the actions available to the actors. Thus the requirements are down but the design isn't set in stone yet. 

Steps for next Semester


Back to Main Page