Skip to content

Software Quality Assurance Plan and Report

Fulin Huang edited this page Mar 4, 2019 · 5 revisions

Software Quality Assurance Plan and Report

Introduction

This Software Quality Assurance Plan and Report defines all the appropriate test coverage criteria that the team aims to achieve for the business method implemented in the backend. This test plan includes the unit test approaches of each controller implemented at RESTful and each test coverage is measured and reported. Additionally, the integration test for each modify-data service at backend are well documented and reported. We aim to have consistent coding convention. Code reviews are performed after every push of the code.All the testings are successfully passed the JUnit test and are successfully built on Travis CI.

Unit Testing of Backend

Four controller tests are developed for unit testing purpose. These unit tests are executed in isolation using the JUnit framework. The unit tests focus on testing the functionality of objects and methods.

CoopTermControllerTests

The coopTermControllerTest is used for testing methods in CoopTerm service class, which are used for implementation of the CoopTerm controller class. Equivalent testing is used to test all the methods. The main function of this test is to check whether the followings are correctly implemented or not and whether it could deal with all the possible cases:

1) Get a coopTerm given a coopTermId 
2) Update the CoopTerm States, either Active or Inactive 
3) Get all coopTerms 
4) Get all coopTerms of a student  

Statement coverage is sufficient for this stage, and we expect to achieve about 95% of this coverage. Both valid cases and invalid cases of a method should be tested. For instance, we want to get a coopTerm given a coopTerm ID. The test should cover both the cases when coopTerm ID exists/is valid or not exists/is invalid.

The following methods are used to test the functionalities of the CoopTerm service class:

 
- testGetCoopTermById()
- testGetCoopTermByIdReturnNull()
- testUpdateCoopTermStatesById()
- testUpdateCoopTermStateByIdReturnNull()
- testGetAllCoopTerms()
- testCoopTermsOfAnStudent()
- testCoopTermsOfAnStudentReturnNull() 

The coverage achieved by the CoopTermControllerTests is 95.6%.

StudentControllerTests

The StudentControllerTests is used for testing methods in Student service class, which are used for implementation of the Student controller class. Equivalent testing is used to test all the methods. The main function of this test is to check whether the followings are correctly implemented or not and whether it could deal with all the possible cases:

1) Get a student given a studentId
2) Get all students 

We expect to achieve about 95% using the statement coverage. Both valid cases and invalid cases of a method should be tested. For example, we want to get a student given a student ID. If the studentId is not found, then this is an invalid case, and it should throws exception. If the studentId is found (a valid case), then it should return a student with this studentId.

The following methods are used to test the functionalities of the Student service class:

 
- testGetStudentFindById()
- testGetStudentFindByIdReturnNull()
- testGetAllStudent()

The coverage achieved by the StudentControllerTests is 98.3%.

EmployerControllerTests

The EmployerControllerTest is used for testing methods in Employer service class, which are used for implementation of the Employer controller class. Equivalent testing is used to test all the methods. The main function of this test is to check whether the followings are correctly implemented or not and whether it could deal with all the possible cases:

 
1) Get an Employer by a given Id
2) Get an Employer by a given Email
3) Get all Employer
4) Create an Employer by a given Id, Email, Password, Name

Statement coverage is implemented for this stage, which aims to achieve 95%. Both valid cases and invalid cases of a method should be tested. For example, when trying to get an employer by a given id, the case of valid id, invalid id, a not-found id all should be tested. If could not get an employer, exceptions are thrown. The test should cover all possibilities when getting an Employer with ID / Email, and create an Employer.

The following methods are used to test the functionalities of the Employer service class:

     
- testGetEmployerByID()
- testGetEmployerByIdReturnNull()
- testGetEmployerByInvalidId()
- testGetEmployerByEmail()
- testGetEmployerByEmailReturnNull()
- testGetEmployerByNullEmail() 
- testGetEmployerByInvalidEmail()
- testGetAllEmployer()
- testCreateEmployer()
- testCreateEmployerEmailNull() 
- testCreateEmployerEmailSpace()
- testCreateEmployerPasswordNull() 
- testCreateEmployerPasswordSpace()
- testCreateEmployerCompanyNameNull()
- testCreateEmployerCompanyNameSpace()

The coverage achieved by the EmployerControllerTests is 80.6%.

EventControllerTests

The EventControllerTest is used for testing methods in Event service class, which are used for implementation of the Event controller class. Equivalent testing is used to test all the methods. The main function of this test is to check whether the followings are correctly implemented or not and whether it could deal with all the possible cases:

1) Get an Event
2) Get all Event 

Statement coverage is implemented for this stage, which aims to have a coverage of more than 95%, and both valid cases and invalid cases of a method should be tested. The test is supposed to cover all the possibilities when getting an Event and get all Events.

The following methods are used to test the functionalities of the Employer service class:

- testGetEvent()
- testGetEvents() 

The coverage achieved by the EventControllerTests is 100%.

Integration Testing of Backend

The target of the integration test is the combination of units. An integration test verifies the interaction between software components. Our IntegrationTest package contains three integration tests: cooperatorControllerIntegrationTest, EmployerControllerIntegrationTest and Event ControllerIntegrationTest. Bottom-up approach, build from small program to larger program, is applied in our integration tests.

CooperatorControllerIntegrationTest

This Integration test should test on getting one coopterm and updating a coopterm. Thus, the following two tests are included:

- canGetOneCoopTerm( )
- canupdateCoopTerm( )

For canGetOneCoopTerm method, aGET method with a precise URL is passed to get a coopterm. The received content is expected to be in JSON format; The response http status should be ‘Ok’; It should return a valid coopterm. For canupdateCoopTerm method, an URL is passed in order to put information as JSON format in a coopTerm. After the update, it should return the updated coop term, and the expected coopTerm should have the same content as the JSON information that passed in. The response http status should be ‘Ok’. The coverage for this integration test is 100%.

EmployerControllerIntegrationTest

This integration test should test on signing up an employer and getting an employer’s information. Therefore, two tests are included in this class:

- signUpEmployer( )
- canGetOneEmployer( )

The signUpEmployer method uses PUT method with an URL to put employer’s signup information, including email, password, company name and employer ID in JSON format. An employer object is returned. The expected employer’s information should be in JSON format, and the response http status should be ‘Ok’. For the canGetOneEmployer method, a GET method with an URL is passed to get an employer. The received content is expected to be in JSON format. The response http status should be ‘Ok’.

The coverage for this integration test is 100%.

EventControllerIntegrationTest

This integration test should test on getting events for an employer. Thus, this test includes a

 - canGetEvents test

The method performs a GET method with a precise URL to get all the events. The result is expected to be ins JSON format. The response http status should be ‘Ok’.

The coverage for this integration test is 100%.

Clone this wiki locally