What would we do if we had enough time?
Unit Testing
- We would test for each function for both the front and back end of our project. These tests would include both user and edge test cases testing for individual classes and functions.
- For our front end, testing would include testing the buttons and polygons for each garden.
- For our back end, a use case would be testing for a specific item in a JSON file for a plant bed. An edge case would be if unrecognizable data is entered into the plant data.
Integration, widget, and system testing (with UI)
- Our integration, widget, and system testing would test the functionality of the website collectively with the data themselves.
- For our front end, a use case test would be seeing plant information after clicking on a garden showing on the map.
- System testing for the backend would include testing whether the entire JSON page is being pulled and utilized through our user actions. This can include when the admin enters different data for the plants.
- Widget testing would be one of the main ways we test our code. Multiple interactive parts that cover UI are created through widgets. Each of these parts would have to be tested in order to test for functionality.
Descriptions of Tools Used
- We will be testing using the Robot framework. All of these tests would be tested through visual studio code.
- For unit testing we would be using the Robot framework.
- For integration we would use the integration package in visual studio code
Descriptions of Types of End Users
- Our primary users will be UNC students, teachers, and visitors who are on UNC campus for long durations of time. They would be able to open the website and click on each garden. They are then able to find the description of each plant in each garden.
- Our secondary user would be Kyle Parker or anyone who would be in charge of changing the plant data for different seasons. They would be able to access the data of our project and be able to change the plants and their data in each garden.
Performance, Reliability, etc. Testing
- We would gather groups of students, teachers, and UNC staff in testing the website. Half the groups would be laptop or desktop users and the other half would be mobile-device users. We would test the initial loading steps for the start of the website, clicking on each garden, and going through each plant information in each garden. We would also test to see if using different browsers and having different versions of the browser could cause some issues.
- For the admin side, we would get the edible campus director Kyle Parker to enter into the admin page. We would then ask if he could first change the data of a plant. We would then ask if he could change the plant itself. These changes after being saved should show up on the website..
Acceptance Testing
- We would meet up with edible campus director Kyle Parker and see if there were parts of our website that did not fit his initial requirements of the app.
What will we actually do?
Unit testing
- Testing each buttons and drop down menu on our website
- JSON validation functions to make sure correct values of data are being sent and received.
Integration and system testing (with UI)
- Manual tests from the front end where we will complete the surveys and make sure that all UI are functioning as intended.
Descriptions of tools used
- We will use the Robot framework for unit testing.
Acceptance testing
- Send the website to our client, Kyle Parker, for any UI feedback or any other feedback he would like to give.