Since we have developed a security system revolving around 4 security types: Manager, Front Desk, Accounting, and Room Services; it is necessary that we ensure that only the menus needed are shown and accessible to a given security level.
For information on what is accessible for each security level please refer to the document Response to customer questions.
In order to properly test these security features we will wait until the final prototype is completed.
One of our main objectives was ease of use and speed. Essentially this is more of a feeling for the system then a measurable metric. After filling the database with a large quantity of data the system will be tested for speed in such areas as searching and retrieval of complex invoices. Further, it is important to ensure that the database is relatively simple to restore from tape or other archive media. If the hotel system crashes for some unseen reason, such as a power failure it is fundamental to the operation of the hotel that the system is returned to operation as quickly as possible. Since the system is designed for the use of several users at one time we will test with approximately twice the current number of employees working at our customers hotel.
Due to our intense function level testing this will only require a quick check of module linkage. For example we will be checking that all the menu items and buttons actually respond to a key press.
Our philosophy in doing detailed testing at the function level revolves around the fact that functions that behave correctly for a given input will behave the same when combined with other functionality. As long as the interconnection between the functions is correct the overall program will be correct as well. Further we will test from a top down manner based on our structure charts. Due to the fact that the system has no reached a coding phase we have not added information on expected responses. However, we have attempted to test for inputs that we feel should either return a success to the user or notify them of a problem. Currently we have standardize on a dialog box based approach of informing the user of errors and success of operations.
For a detailed analysis of our function level testing please see the following documents:
Remo, our head of testing, will be in charge of processing bug reports and requests for functionality modification. Remo has the power to forward modifications to the development team or to hold them for future development. In regards to bug reports Remo will ensure that they are forwarded to the development team along with information on their severity and instructions for repeating the problem.
Once Remo has passed a bug report or a feature on to Brian our head of the development team he will be responsible for implementing the change. If he feels that the change is too complex, or will fundamentally change the structure of the software he will discuss the change in greater detail with the entire development team and with Remo. If the task is deemed accomplishable he will assign someone to complete it.
The head of testing (Remo) will assign function level testing to each member of the design team. Upon completion of the function level testing he will then assign two people to do Performance and Stress testing in parallel to each other. Their results will be compared, and any changes deemed important will be passed on to the development team. At the same time one other member of the testing team will be assigned to evaluate the security of our system. Once all the above testing has been completed the testing team as a whole will perform the validation testing based on
Below is shown an example of our testing bug report form. This form will be used as a tool right from reporting of the bug to the final solution of the bug. In essence it is the hart of our bug tracking system.