D3: Test Plan – OMLSMS Database

Part I contains the ideal, holistic, comprehensive test plan that we would execute given enough time. Part II contains the tests that we actually plan on implementing and executing for our project.

Part I – Ideal Test Plan

Unit Testing

We plan to write unit tests with Pytest to ensure that specific parts of our application are functioning how we would expect them to. Pytest works great with Python, which will help a lot with our project. We plan to test all kinds of cases, from the most common ones to the least common edge cases. We would also like to have unit tests for creating, reading, updating, and deleting from the database to ensure the link between our application frontend and server.

Integration and System Testing (with UI)

Once we can confidently say that our application functions as we expect, we need to test the features of the user interface and ensure that it is interacting with our backend services properly. We will go through and check the functionality of each UI element. As all of the UI code will have been updated from PyQT4 to PyQT5, this is essential and will ensure that none of the elements break during the updating process and that any new features will function as expected. Ideally, each member as well as the client would complete this individually as well as together for redundancy.

Steps we will use to test the functionality of UI elements:

Open Application from Desktop
Click each button
Record if it functions as expected for users and admins
Repeat until all UI elements have been tested.

Descriptions of Tools Used

One tool we plan on using to accomplish our testing goals is Pytest, a testing framework specifically designed for writing unit tests in Python, for Python applications. Pytest makes it easy to make assertions and assess how your application is actually performing versus how you expect it to perform. This is critical because all the code is being moved from Python 2.7 to 3 and could cause functional errors that would not have been caught by our syntax updating tool, Python2to3.

Descriptions of Types of End Users

We have two types of users, admins and non-admin employees. Non-admin employees will have access to all other functionality except creating, editing, and deleting users. A logged in admin, either the IT department or head of the OMLSMS will have the ability to add/delete users as employees come and go.

Performance and Reliability Testing

Ideally, we would test the application across all computers in the lab in person, as well across various other machines at different powers and operating systems. This would minimize the amount of unforeseen errors on specific hardware or software configurations that we may not know about.

Acceptance Testing

If time was not a constraint, we would develop each feature with the client to ensure all features in their request list were met and approved before delivering the final product. We would also have the daily users of the application test each feature as we go to optimize the UI and catch bugs.

Part II – Actual Test Plan

Instructions/Disclaimer: Our project relies on some specific database connections to work, and setting this up isn’t particularly trivial as we are using a specific copy of a Microsoft SQL Server DB given to us by the Dental School. As a result, if a DB connection is not established, the test suites will not work. However, once you go through the trouble of getting a proper connection to this DB or a copy of it, then it works fine (which you can do by following instructions in the README). We recognize that anyone who does not have access to the Dental School servers or has not gone through all of the setup we have may find some difficulty merely getting both the unit and UI/System testing to even run in the first place as we have described below. We discussed this potential issue with Sam, and he informed us that it would be best to describe the steps as best as we can in as much detail as we can to set up a server on their own, but to also perhaps show us running our own tests to be safe. Therefore, to convince anyone that our system does indeed work and pass our tests, we have recorded clips of us running our test suites to view. The README discusses how we went about setting up the system so that if anyone theoretically had access to a DB copy, they could follow these steps in detail to get it running on their end. However, be aware that the entire setup process is finicky and took us some time to get working ourselves. With that, the first section below will follow all of the setup for the tests, followed by a tutorial/description and video of our unit tests and other system/integration/UI tests.

Setting Up the Test Environment:

First, obtain a backup file of the OML SMS database (which we have access to but were given privately – for anyone else wanting the backup file, you would likely have to check with the Dental School to gain access – we can also ask for permission if necessary – otherwise, ask for the omldb.bak file – our contact for this was “Dale Andrews” over at the Dental School).
Next, in the console, after downloading all dependencies specified in the README, pip install “pytest”
After that, restore the backup database file (.bak) using Microsoft SSMS (instructions also in the README). Also, run a local SQL Server instance on your machine (will likely need to download the developer version, as this is a paid service – the README also goes into detail about this).
Then, after restoring the database file, connect to your SQL Server instance in SSMS – once the connection is established, your server is up and running
Next, change the specified values in the code to relate to your database instance instead of the one from the Dental School (note this is a constraint of the older code that we would have likely changed if starting fresh – the README specifies which values need to be changed and where).
- Note that some values in the database itself will need to be changed first, as a new user with a new password has to be added and their permissions changed in order to access the server. THIS STEP IS NECESSARY TO RUN THE UI TESTS, AS IT IS THE USER/PASSWORD ENTERED TO LOG IN ONCE THE APPLICATION STARTS – again, see the README for instructions on how to do this.
Running “python omldb.py” in the db_rewrite directory and running “python manage.py runserver” without errors means everything should be connecting properly. However, some of our unit tests also address connecting to the database. Note that “runserver” will start a web server, but this is not a web application, it merely utilizes some components of a web framework, and starting the server means everything is connecting properly, so it is a good way to check.

Unit Testing

Our unit tests are written using pytest and were added to test various things like functions or database operations that do not rely on the UI. First, all of the dependencies listed in the README must be installed, including the correct version of Python (see “descriptions of tools used” below). Then, run “pip install pytest” to install pytest (naturally). To run these tests, navigate to the “web” directory, and in the console, enter the command: “pytest” – this will automatically run our test suite and output results on the console.

Integration and System Testing (with UI)

While the unit tests will be conducted by running the Python code in the test folder, the integration and system tests will be conducted by running the “omldb.py” file, which is done by running “python omldb.py” in the rewrite_db directory. Once the application is launched, we will ensure that all of the tabs/views and database operations function properly. The goal here is that it functions exactly as the old version of the application does, as well as ensuring that our additions integrate into the system properly. See below for some specific UI tests to run:

Launch application with “python omldb.py” in the rewrite_db directory after following all of the setup that was described above
Ensure a login dialog box appeared
Enter the username and password you created for your SQL Server instance (and added to the logindlg.py file, line 91) and click enter – ensure the application launches without an error or without shutting down
Click the “Dentist” tab once the application launches – you should see a page with a Dentist ID at the top
On the Dentist tab, click “Find” at the bottom left and ensure a dialog page that allows you to search appears, then click “cancel”
Click “Date Inactive” on the Dentist tab and ensure an “Enable Dentist” dialog box appears – then click “No”
Next, click the “Sterilizers” tab – ensure a new dialog box appears
Do the same as above but for “Lots”
Also repeat this for “Renewals,” but ensure the Renewal History at the bottom appears – specifically, you should be able to scroll through various lots, dates, and different fees should be shown (an early bug would cause this to be blank)
Next, click the “Tests” tab, and just like for renewals, there should be a list of tests with +/- values that you can scroll through – ensure it is not blank
Finally, click on the “Reports” tab and a new dialog box should appear with multiple tabs on the side. Click on each of these tabs to ensure their functionality (errors are thrown if they do not work properly).

Descriptions of Tools Used

The unit tests should run and function correctly with Python 3.10, PyQt5, pytest 8.1.1, and Django 5.0 installed. We will be running these tests inside of VS Code.

The system/UI tests will need to run on the same versions, but they will be operating on a local Microsoft SQL Server backend, as described above. Before testing the system on the client’s platform, it should be noted that configuration files will need to be changed back from our local versions to fit the client’s original database.

Descriptions of Types of End Users

We have two types of users, admins and non-admin employees. For our current purposes, these two types of users will behave the same, as their different functionality was not quite implemented yet.

Performance and Reliability Testing

Ideally, given more time, we would have tested the application (both UI and unit) on every machine used by the OML, but for our purposes, we will have to just ensure it works on the client’s machine by asking them to run the UI tests (and possibly help in-person if a connection fails).

Acceptance Testing

As noted above, we will demo the application to the client and allow them to test it on their local machines (specifically UI testing and clicking through all the buttons). This will allow us to catch any potential issues and change them so that the client’s application works as expected.