Quality Assurance Plan

Introduction

This Quality Assurance Plan will cover the methods and processes that will be used to test the quality of our backend methods. The plan will define all the test coverage criteria using various testing processes. Overall we put a larger emphasis on dynamic V&V due to time constraints. Our team has not yet created concrete plans for performing static V&V, however this will most likely be organized early in sprint 3.

Coverage Criteria

1. Statement coverage: all lines of code are executed and are logically coherent.
2. Branch coverage: all condition branches are covered in the testing process.
3. Path Coverage: all possible paths of a method are tested for correct functionality.

Dynamic Testing

The dynamic testing of the backend methods will be done using JUnit 4.

Unit Testing of Persistence Methods

This test suite will validate all the features of the Persistence layer. Each Dao class (CRUD Repository) will be tested on their ability to PersistAndLoad and Delete. The SpringBootTest framework will be used to interact with the Persistence layer. The unit tests should achieve at least 90% of the statement coverage.

Unit Testing of CRUD Methods

This test suite will validate all the methods inside the Service class. Each method will have several test cases using equivalence partitioning in order to ensure that the coverage criteria are met. The SpringBootTest framework will be used to interact with the Persistence layer. The unit tests should achieve at least 90% of the statement coverage, 100% of branch coverage, and at least 90% of path coverage.

Unit Testing of Service Methods

This test suite is similar to the unit testing of CRUD methods, however, the Mockito Framework will be used to interact with the Persistence layer. The unit tests should achieve at least 90% of the statement coverage.

Integration Testing of RESTful Service

This test suite will validate & verify all the POST, PUT, GET, and DELETE endpoints of the RESTful Service using Postman. Every query in the REST controller will be tested. The integration tests should achieve at least 90% of the statement coverage.

Static Testing

Concrete plans for static testing have yet to be put into place due to major time constraints caused by schedule conflicts among team members. It was decided that any serious static testing, whether using structured inspection or modern review, will occur over sprint 3.

Ultimately, the lack of static validation was detrimental to the workflow of sprint 2 as we constantly felt ourselves going back in order to add more tests or re-determine what the desired functionalities of our product should be. Some informal structured inspection did occur over sprint 2 in the form of several team members communicating over voice chat while working, resulting in some on-the-spot critiques of each others code.