Unit Testing Plan:
Ideally, we would use Jest for Javascript unit testing and Postman for testing API calls. It is a testing framework where we make automated unit tests on each of our components. Jest is widely used for Javascript projects and can be easily integrated so we can create a test file with unit tests for our code. Unit tests would include things like checking database retrieval data to ensure they are valid.
However, most of the database has been tested by the previous team and their results have been documented. Furthermore, hundreds of volunteers are currently using the app, and we have not received any notices about major bugs. For this reason, we believe the infrastructure for our project has already been extensively tested and is currently being tested and we will most likely only use Jest if we encounter a major bug that we believe belongs to the database rather than frontend code.
For the admin app, there is still work to do in using Postman to test post, update, and delete requests that are both valid and faulty to ensure we are accessing our database in a way that we would expect. For example, we will make a post request with incomplete fields to ensure that the database is not adding this entry unless it has all the information a regular entry within the database has. Another instance of how we can use Postman to test API calls is testing the update request and checking if our validation checks work to ensure the admin cannot update a working dataset with any fields that could break the functionality of the database.
Integration and system testing (with UI):
Integration and system testing (with UI) is where we test groups of components together in conjunction to make sure features are working as they should. Ideally, we could use Jest to accomplish integration testing for our project as well because there are built-in tools like jsDOM which could emulate browser APIs and mocking tools for stimulating external APIs. We would use integration testing to check sequential processes. For example, for our existing deployed app, we are creating a better functionality on Wake Smiles’ volunteering and admin portals, and we would want to check the back-to-back functionality of clicking the login button and then clicking the “shifts” button on our navbar to ensure that they work in conjunction.
Ideally, we would also use end-to-end or more in-depth integration tests to test the entire process of having a user input their credentials, click the login button, click “shifts” on the navbar, click the clock-in button, and then log out of their account. This would be one example we would implement a “use” case for integration testing/end-to-end testing because we are checking multiple functionalities from start to finish of what a volunteer would need to be able to do when using the platform.
In practice, our project involves 2 apps that are separate, but work off the same database, so we do not expect one app will break the functionality of the other app itself, but one app could make changes to the database in a way that affect the ability of the other app to work as intended, so most of our integration testing would involve ensuring each app interacts with the database in the way that was intended, a lot of which will be covered by our unit tests.
Description of types of end users:
There are two platforms that we are creating as part of our project – the volunteering platform and the admin platform. The volunteering platform is accessible to the public or specifically college volunteers, employees of WakeSmiles, dental hygienists, and dentists. On that platform, any user should be able to create an account, log in with their credentials, and navigate throughout the site by the navbar that has multiple tabs that take care of signing up for shifts, logging hours, forms, and other things. Users are volunteers that should be able to use the website to check available shifts occurring, sign up for preferred shifts, clock in and clock out of any current shift, and see a history of all previous shifts in their account. On the admin side, there is only one user (the individual who oversees the entire volunteering process at WakeSmiles). They can manage and edit any volunteer’s shifts at their discretion and there is only one individual who can access that platform.
Performance and Reliability testing:
If we had the time to incorporate automated performance testing in our project, we could use LoadView to do our testing. Using LoadView would be an ideal method for us because it can test web applications and utilizes real browsers so we could measure and see actual performance from a user’s perspective. We would script the user actions and set up a load test. Under our current time constraints, we are doing performance testing manually by physically logging in and checking performance as we click through the website. However, given time constraints, it seems unlikely we will test performance, especially on the admin app, where there is only one user.
Acceptance Testing:
For our project, acceptance testing would work if we shared the site we were planning to deploy with a few volunteers from Wake Smiles and set up tests consisting of functionality and performance and see if it worked according to the written and user criteria. If not, our website would go back to development and if it all worked out we would deploy it. In one way, we are already implementing this with our client. When we have check-in meetings, our client can approve or disapprove the features that she specified in the user stories because we show her the functionality of the feature she asked for. She is then able to ask us to change features according to her needs if they don’t work the way that she needs them to or she approves features and we can move on.