-
Notifications
You must be signed in to change notification settings - Fork 2
Software Quality Assurance Plan
This plan will cover the methods and processes that are going to be used for the testing and quality assurance of backend methods. The plan will define test coverage criteria we wish to achieve and how we will achieve this criteria using unit/integration test approaches (Dynamic V&V), and explain other means of testing our team has implemented (Static V&V).
The dynamic testing of backend methods will be done using JUnit 4 Framework. Tests are separated into three categories (or layers) that were combined to cover all cases and coverage criteria.
- Statement coverage: All lines of the source code will be thoroughly tested, with Static and Dynamic V&V. These include all business methods, and persistence code.
- Branch Coverage: All branches of the business methods will be tested for correct functionality.
- Path Coverage: Static Testing will be used to test all paths of the business methods.
This layer of testing shall cover all methods within the Service Classes. Quality Assurance will focus on the main CRUD methods, and test cases derived from equivalence partitioning. This will consequently call for multiple test cases per business method. Each service class will have its own test class with all test cases, and the test suite will run all tests. Mockito Mocking Framework will be used to stub the functionality of the database interactions. The unit tests should achieve at least 90% statement coverage.
The next layer of validation & verification comprises all integration tests for the REST Controller. POST, GET, READ, and DELETE endpoints will be tested using Advanced REST Client, a Google Chrome Extension. Every query in the REST controller will be tested with multiple test cases (equivalence partitioning again), and should achieve at least 90% statement coverage.
The final layer of testing will be to fully test the final application. For the manager viewpoint, there will be multiple tests for every use case, which will be derived using equivalence partitioning. Some tests will require the creation of a manager, and logging in under the account, because of access conditions in the application. These tests will be run using manual inputs and outputs in a Test Suite created by the Quality Assurance team. The statement coverage should be no less than 90%.
It was decided to use the Structured Inspection approach for further testing of the Business Methods, because of its rigid structure, and the groups lack of engineering experts to act as reviewers.
| Role | Team Member(s) | Description |
|---|---|---|
| Moderator | George Kandalaft | Ensures followed procedure, keeps meeting on track. |
| Recorder | Ryan Arndtsen | Documents problems identified during inspection. |
| Reader | Elias Tamraz | Reads aloud small logical units. |
| Reviewer | Louca Dufault, Caleb Lim * | Detects problems in artifacts. Role assigned to member from development and member from QA for different perspectives. |
| Producer | George Kandalaft, Ryan Arndtsen, Elias Tamraz, Louca Dufault ** | Author of artifacts under review. Fixes problems found during inspection. |
*All team members played a reviewer role, but Louca and Caleb were main reviewers.
**Producer role changed based on which artifact was being reviewed (different authors).
Due to team members' busy schedules, it was decided that only one review session would take place throughout the sprint. This session was scheduled for October 30, 2019 at 8pm. The artifacts were explained through Slack by the authors so there would be no confusion when the day of the meeting arrived. To prepare, all team members reviewed the Business Method classes and thought of potential issues to bring up in the meeting. Finally, a checklist was created by the moderator where all artifacts and all types of errors to be reviewed were listed.
All team members met and played their roles to successfully identify issues, and propose potential solutions. Two main categories of source code were tested: Business Methods, and RESTful Services. Issues identified were:
- Potential cascading errors with "delete" business methods.
- Spring Framework annotation errors (Autowiring and Service) in business methods.
- Lack of Javadoc for some methods.
- Similar and redundant RESTful services that cause excessive testing.
These issues were recorded by the Recorder, and then given to the Producer for further inspection and fixes.
Overall, the use of Structured Inspections was successful. All members played their parts well, which made the review session efficient and effective. Issues were successfully fixed and a follow up check was done by the moderator to check if producers had done their job. This process will be used again throughout the project, and roles will be the same because of its effectiveness.