Testing Phase

In order to ensure that the database for raiderplanner is designed correctly and works seamlessly with the application, we will need to undergo the creation of several test scenarios and test cases.

---

Test Scenarios and Test Cases

First and foremost the database design team will need to create multiple test scenarios and test case documents. These test case documents will contain a set of conditions that a tester must linearly undergo in order to make sure that the application is functioning properly. This means that this test case document will contain step-by-step instructions of how data is supposed to interact with our system and the outcome of certain operations.

Some things that the database design team will need to consider when constructing their test plans are as follows:

1. Checking whether or not graphical user interface forms or data entry points are mapped correctly to the right relations in the database. This mapping is obviously predefined in our functional requirements and data requirements documents.
2. Checking wherever certain actions and operations are executed, in our raiderplanner application, that the correct corresponding JDBC code gets executed (E.I. Create, Retrieve, Update and Delete) and the database reflects the correct operation outcome. In essence we want to make sure that the right action is invoked. This means that a tester will have to check each action to make sure the correct action is invoked and whether it executed successfully.
3. Checking whether or not data integrity is maintained throughout the system. This means after any of the following operations are executed (create, retrieve, update, and delete) the correct data is displayed to all users, views, models, and forms. We should never allow on old values to be displayed in any views after changes or transactions are successfully made. Remember keeping consistency throughout our application is crucial.

---

Outcome

The outcome of creating these test scenarios and test case is will be to ensure the following characteristics:

• System is Accurate: Exacts the purpose.
• Fully Economical: No unnecessary steps or work.
• Traceable: Capable of being traced to requirements.
• System is Repeatable: Can be used to perform the test over and over.
• Test cases are reusable: Can be reused if necessary

---

Testflow

The database designers should follow this sequence while testing the application:

1. Set up and prepare the environment
2. Run through test case`
3. Compare test result to expected results
4. Document and report outcome

Other Test Strategies

Other testing that might be undertaken by the database designers are as follows:

1. Creation of Structural Data Test plans: this would deal with records and tuples testing, relational schema testing, storage protocols testing, and views or triggers testing, etc.
2. Creation of Functional Tests plans: this would entail checking the functionality of the database from the overall end user point of view. This is generally done through white box and black box testing protocols.
3. Creation of Nonfunctional Test plans: this deals with the process of load testing, risk testing, atomicity testing, Consistency testing, stress testing, requirements testing, performance testing, isolation testing. Basically, it deals ensuring that the **ACID **properties are upheld in our database.

---

In summation, only once all test plans and scenarios have been executed, documented, and reviewed can the developers finish this project. Obviously, there is a lot that goes into testing the application these are just some ideas and good practices to consider while implementing this test phase for our database system. And, ultimately, these test cases should not be exclusively used just for testing our database, but rather these test cases can be used for all major changes to our application. Basically, Developers or database designers should run through these test cases to ensure that their newly implemented code does not break previously functioning components of the system.