Skip to main content

D3. Test Plan

Our project is based entirely off of web interactions from a specific group of people, patients of the UNC hospitals with hematologic malignancies. This means that our testing needs to be thorough when finding bugs in our user interface.

Not only that, but our tool will be used in the medical field where accuracy is the upmost importance. When considering database entry of information, bugs in the backend are very important to find and fix. Entries need to be accurate, and equally as important they need to be easy to access and manipulate.

Unit testing

  • User interface
    • Testing our user interface will involve making sure there is a seamless transition from our home page to both the video page and the survey itself.
    • We will do most of our testing on the survey portion of the app. This means testing a tree of different paths in the survey, for example, filling out the entire survey and attempting to re-pick answers, refreshing the page during survey usage, and selecting different combinations of answers.
    • We will also test the home page to make sure that going forwards and backwards in the browser works as intended, in this case allowing our users to do so with warning that their answers will not be saved if they move back in the browser from the survey page. Video tutorial progress will also not be saved.
    • Lastly, we will test the dashboard of our application, that is, the interface that faces the medical professionals looking at data. This is not of the upmost importance to our project as a whole for the semester, so this is something that we may not get to given our timeline.
    • This portion of our testing will not use automated testing.
    • With more time and resources, testing on a control group of patients would yield the best results. We could then see exactly what these people like or don’t like about our app and make changes based on that, but we do not have the time or resources to do this.

  • Backend testing
    • Create correctly formatted JSON objects before sending said objects to the database.
    • Database logs are correctly formatted in the database after being sent. POST and GET requests return all values that are expected in the right order and format.
    • A get request sent to the dashboard is correctly formatted in the given placeholders that the front end uses for display.
    • With all the time in the world, we would create very strict and exhaustive testing, but for the time being, the tests will be relatively simple, but rigorous enough that we are confident handing off our app.

Integration and System Testing

  • Test the recording of correct survey responses from the front end, formatting into a JSON object, and logging to the database using POST.
  • Test separately a GET request, and that it correctly returns expected values.
  • Test that the containerization of our app works as expected, that one link leads in and out of the survey, and a unique token is generated when a new link is created that is tied to the expected recipient. This is something that may or may not be tested in our timeline as it is a reach goal.

Description of tools

  • We will use a combination of Jest for assertions and javascript functions to automate what is described above apart from the UI testing as that will be manual. Some of our integration testing will be manual as well.

End users

  • Our users will be patients with hematologic malignancies at UNC Hospitals. This is important as most of the patients are older in age, and want their medical experience to be as easy as possible as they spend a lot of time receiving care.

Acceptance testing

  • We plan to hold a meeting towards the end of the semester with our client to go through our testing process, and see if this meets their expectations that they set out for us originally.