-
Notifications
You must be signed in to change notification settings - Fork 0
Software Quality Assurance Report
This document represents the quality standards for the Co-Operator system and other project deliverables. These standards are derived from software requirements which were implemented by our team to meet all the requirements of the stakeholders. Software Quality Assurance is a formal process for evaluating and documenting the quality of the work products produced during each stage of the project.
This document’s main target group is Co-Operator software project team. Members should make sure that quality standards are followed during developing the application, documentation, and testing of the project. This document is basically a guideline to follow while moving further with the project.
There are many co-op programs offered by McGill University, and the number of these programs may increase in the future. Our software group aims to develop software system for managing co-op terms for such co-op programs.
Co-operator application will be used by stakeholders in many ways. We are responsible for the student view point. 1)Student: Co-operator system will be reported with an acceptance of co-op program form which is filled by the student. System will store employer contract, term specific reports, and co-op internship evaluation forms at different stages of the coop.
This project is being developed for ECSE321 course. Timing is a constraint as the project should be completed before the end of term. The team includes 5 developers. If a group member becomes absent at some point of the project, this may affect the progress of the project, and may lead to delays in the deliverables.
This section is about identifying the various kinds of documents we will need to develop throughout the entire project.
To ensure that the implementation of the software satisfies the technical requirements, the following documentation is required.
This document should be used and modified from time to time to be sure that the group is covering every requirement of the stakeholders. This document includes all functional, and nonfunctional requirements of Co-operator application.
This document should be used and might be modified as the group moves further on the project. This is important for the group since it outlines the project and makes the group members understand the basic concepts of the program. This document should show the interaction between classes.
Software Test Reports are used to understand the results of the executed tests. A report should contain every single information of tests which are executed.
This documentation explains how to install, operate, manage, and maintain Co-Operator application. It should explain data control inputs, input sequences, options and program limitations, Error messages should be explained with which path will be executed after the message. This is important for further parts of the project.
1)Database: This documentation is in our GitHub page. It shows the model which was used to create the database. This document is essential to take a grasp of the database of Co-operator application. 2)Use Case Model: This documentation is in our GitHub page as well. It basically describes the functionality of a system in a horizontal way. It also includes information about which Use-Case model was taken care of by whom.
Requirement collection: Co-Operator should cover every need of each stakeholder and it should be revised and approved by the customer. Structure: The structure of Co-operator should be error free. Development: All aspects of the application should be completed before the due date. Testing: Every testable piece of code should be tested to have zero issues. Every test code should be written, and should be executed before the due date of every iteration.
The tools and technologies which the group will use is defined by the professor in the lectures. For this sprint (backend) the assigned concepts are software frameworks and services, behaviour modeling, and testing. Tools include Java Spring, Restful API, and JUnit.
We used the following technique for code quality assurance:
1)Group Review: When a group member decided to add or update a requirement, other group members saw those modifications. The modifications were not considered as final until every group member agreed with the updates. 2)TA Review: The responsible teaching assistant checked on the requirements during and after the first iteration. 3)Completion Testing: After every iteration, group members checked if the code covered every functional requirement. If they were not covered, we prioritized covering all requirements before moving forward with the next iteration.
We used mostly JUnit testing to achieve this.
Unit testing is a level of software testing where individual units or components of a software are tested. The purpose is to validate that each unit of the software performs as designed. A unit is the smallest testable part of any software. It usually has one or a few inputs and usually a single output. Unit testing will be applied by the test team before submitting each iteration. All test results will be test results will be noted. Advantages of the unit testing are:
- Unit testing increases confidence in changing/maintaining code.
- Codes are more reusable.
- Development is faster.
- Debugging is easy
Integration testing is a level of software testing where individual units are combined and tested as a group. The purpose of this level of testing is to expose faults in the interaction between integrated units. Test drivers and test stubs are used to assist in Integration Testing. It is important for the team since, there are lots of modules which need to work together.
Persistence Coverage: 50.8%
Unit Testing Approaches: Top-down approach including service tests and mock tests. Used edge cases to check for whether the various parameters are null or 0 while creating a coop or a student object.
For the code coverage, we used ECLEmma which is a free plug-in used for testing and code coverage.