Skip to content

Software Quality Assurance Plan & Report

ishraqhossain edited this page Mar 11, 2019 · 2 revisions

Introduction

This document represents the Software Quality Assurance Plan (SQAP) for the ECSE321 project. Software Quality Assurance (SQA) is a formal process for evaluating and documenting the quality of the work produced during each stage of the deliverable. The primary objective of the SQA process is to ensure the production of high-quality work products according to stated requirements and established standards.

Scope

This SQA process is tailored to fit the current software development effort and is related to the project planning and lifecycle description documents for this project.

Formal Review

For each project deliverable three formal reviews are conducted. The three review types are: End-user review to ensure we’re building the right system Technical review to ensure that the system is being built correctly Quality Assurance review to ensure the overall product is up to standards These reviews are put in place to assure that the software guidelines, and the project management processes are being followed effectively and the deliverable is both technically correct and satisfactory to the users

VERIFICATION AND VALIDATION VERIFICATION The process of determining whether or not the deliverable fulfill the requirements established during the previous stage. Best practices in SQA identify the following activities as part of requirements verification: Evaluate requirements and relationships for correctness, consistency, completeness, accuracy, readability and testability. Assess how well the requirements document satisfies the high level requirements described in the deliverable document Assess the criticality of requirements to identify key performance or critical areas of software.

Validation The process of evaluating software at the end of the deliverable to ensure compliance with software requirements. In validation, the software is tested in a formal, structured manner intended to provide complete coverage of all requirements. This is accomplished through execution of test cases. The test cases are created during the development stage and incorporated into the project test plan. The test cases include criteria for compliance with all requirements. Test cases are run against the software during the unit testing stage, where they may be modified before being incorporated into the final acceptance plan.

FORMAL ITERATION PROCESS

END-USER REVIEW Certain deliverable classes must be reviewed by at least one software developer in the team who is familiar with the system. The developer will examine the deliverable for the presence of attributes specific to the class of deliverable. The intent of the end-user review is to insure that each deliverable is examined from the point of view of the users of the system, by someone who is knowledgeable about the process being automated.

TECHNICAL REVIEW Each class of deliverable must be reviewed by at least one software developer who is familiar with the system. This review will be conducted from a technical point of view, with the reviewer examining the deliverable for the presence of attributes specific to each class of deliverable. The intent of the technical review is to insure that each deliverable is examined for technical accuracy by someone who is familiar with the processes and development tools for the project. This includes code walk-through and peer reviews.

Software Quality Assurance Plan

As highlighted above, we are using extensive reviews to make sure the software is being built correctly. We are implementing an official end-user review for each unit of our system. This will ensure that each service we are implementing works and covers the appropriate requirement.

We are also implementing a comprehensive technical review. The responsibility of the review is being shared by the whole development team. We are ensuring that every piece of code being committed is peer reviewed by everyone. This immediate critique is helpful in catching cascading errors that could occur. This also leaves a lot of room to critique each other’s code style. This technical review is being complemented by unit testing which will ensure our code logic and code acceptance is technically sound. The test coverage report is attached below. We are using JUnit to complete the unit testing, and Eclemma to gather the test report.

Unit testing:

testLogin() testGetCoopSystem() testDeleteCoopSystem() testCreateStudent() testGetStudent() testGetCoopUser() testGetAllStudents() testGetAllCoopUsers() testCreateEmployer() testGetEmployer() testGetAllEmployers() testDeleteStudent() testDeleteEmployer() testSetPassword() testSetStudentPermissions() testFindCoopUserByUsername() testFindStudentByUsername() testFindEmployertByUsername() testDeleteCoopuser() testFindEventNotificationByName() testFindAllEventNotifications() testCreateMessage() testFindMessageById() testFindMessagesBySender() testFindMessagesByReceiver() testGetAllMessages() testFindMessagesBySenderAndReceiver() testDeleteMessage() testFindCoopJobById() testSetCoopJobState() testGetAllDocuments() testGetPersonalDocumentsByStudent() testGetAuthoredDocuments() testGetAttachments() testGetCoopJobDocuments() testGetArchivedInterns() testGetInternDocuments() testFindCoopJobByEmployerAndStudentAndDate() donothing() testCreate() TestCreate3() TestCreate2() testCreateCoopJob() testFindCoopJobs() testDeleteCoopJob() testSetCoopJobSettings() testAddDocumentToCoopJob() testGetAllCoopJobs() testCreateDocument() testSetPersonalDocument() testFindDocuments() testFindDocumentsByAuthor() testDeleteDocument() testDeleteAllDocuments() testCreateEventNotification() testDeleteEventNotification() testSetEventNotification()

The coverage report for the unit tests is attached below:

Integration Testing: testCreateSystem() testCreateStudent() testCreateEmployer() testSetPassword() testCreateDocument() testDeleteDocument() testSetPreferencesStudentPreferences() testSetPreferencesStudentPersonal() testGetCoopuser() testCreateAndSendMessage() testGetMessage() testDeleteMessage() testSentMessages() testDeleteSystem() testCreateEventNotification() testSetEventNotificationSettings() testGetEventNotification() testDeleteNotification() testCreateJob()

The integration testing coverage is attached below:

As can be seen there are a number of problems for integration testing. We will be having a Quality Assurance meeting soon to sort out the errors, which could not be done this sprint due to time constraints. This page will be updated with the new results