Software Quality Assurance Plan

This document describe the test coverage criteria, the unit testing approach we are choosing and the other means of quality assurance we will be using.

Unit Tests

Test Coverage Criteria

Test Coverage Objectives:

• Line Coverage: 80%
• Method Coverage: 90%

In order to make sure that we achieve these numbers, we plan to test all business methods to make sure that they perform the required operations successfully. Since the database access has already been tested in the Persistence Layer Tests, we are stubbing the data used in unit tests using Mockito.

To make sure that all the modules operate correctly, the unit tests are written knowing the inner workings of the method. Hence, the unit tests follow the white-box testing scheme.

Testing Approaches

For our testing, we use a top-down approach. We started by testing the persistence layer in deliverable 1. For deliverable 2, we test the business methods (located in Service classes) from persistence. We then test our service methods in isolation from persistence. Finally, we test the controller methods, which call both the service and the persistence.

For unit testing, we partitioned our input by selecting valid input first and testing for this input. Then we selected edge cases that return an error and test if the exception returned is right. We grouped the unit tests by type of object and by request, then divided these tests among the members of the team:

User Tests

User	Get	Create	Edit/Reset Password	Delete
Valid user	Normal use case	Normal use case	Normal use case	Normal use case
Valid admin	Exception thrown, no advertisement found	Normal use case	Exception thrown, no advertisement found	-
Invalid user	Exception thrown	-	Exception thrown, user not found	Exception thrown, user not found
Invalid email	Normal use case	Exception thrown	-	-
Invalid username	Exception thrown	Exception thrown	-	-
Invalid password	-	Exception thrown	Exception thrown	-

Pet Tests

Advertisement Tests:

Advertisement	Get	Create	Edit	Delete
Valid advertisement	Normal use case	Normal use case	Normal use case	Normal use case
Invalid ID	Exception thrown, no advertisement found	-	Exception thrown, no advertisement found	Exception thrown, no advertisement found
Invalid Pet	Exception thrown, no advertisement found	Exception thrown	Exception thrown	-
Invalid title	Exception thrown, no advertisement found	Exception thrown	Exception thrown	-
Invalid description	-	Exception thrown	Exception thrown	-

Application Tests

Forum Tests

Forum	Get	Create	Edit	Lock/Unlock	Subscribe/Unsubscribe
Valid forum	Normal use case	Normal use case	Normal use case	Normal use case	Normal use case
Invalid forum	Exception thrown	-	Exception thrown	Exception thrown	Exception thrown
Invalid user	Exception thrown	Exception thrown	-	-	Exception thrown
Valid user	Normal use case	Normal use case	-	-	Normal use case

Comment Tests

Comment	Get	Create	Edit	Delete
Valid comment	Normal use case	Normal use case	Normal use case	Normal use case
Invalid comment	Exception thrown	-	Exception thrown	Exception thrown
Locked thread	-	Exception thrown	-	-
Invalid thread	-	Exception thrown	-	-
Invalid user	Exception thrown	Exception thrown	-	-

Donation Tests

Donation	Get	Create
Valid donation	Normal use case	Normal use case
No user	Exception thrown	Normal use case
Negative amount	-	Exception thrown
Null donation	-	Exception thrown

Coding Conventions

To make the code more uniform and easily reusable among different classes, we settled on some coding conventions to be respected when writing methods:

1. In the service classes, all the methods interacting with the controller should have Data Transfer Objects (DTOs)

Test Coverage Results for Unit Service Tests

Component	Methods Coverage (%)	Lines Coverage (%)
Advertisement	100	90
Application	100	98
Comment	100	100
Donation	100	94
Forum	100	100
Pet	100	99
User	100	90

Discussion

We successfully met our test coverage objectives, with a methods coverage averaging at 100% and a lines coverage averaging at 96%.