Software Quality Control Document

Overview

This Software Quality Control Document enlists the set of procedures used by naveze to ensure that a software product will meet its quality goals at the best value to naveze, and to continually improve our ability to produce software products and services in the future.  Software quality control refers to specified functional requirements as well as non-functional requirements such as supportability, performance and usability.  

It also refers to the ability for software to perform well in unforeseeable scenarios and to keep a relatively low defect rate. These specified procedures and outlined requirements lead to the idea of Verification and Validation and software testing. 

It is distinct from software quality assurance which includes audits of the quality management system against a standard. Whereas software quality control is a control of products software quality assurance is a control of processes.  

Description

Software Quality Control is the function that checks whether the software project follows its standards processes, and procedures, and that the project produces the desired internal and external (deliverable) products i.e. output. 

1. Introduction

1.1 Definition

‘‘A Quality Control Plan sets out to analyse the actions required to fulfil the project requirements such that the product meets its specifications and product quality is maintained”.

1.2 The characteristics of a Quality Plan

  • Consistent: The plan should follow the standard and guidelines set by naveze
  • Complete: The plan should include the overall representation of the project requirements, features, documentation of the project plan. Such plan should be developed through all the stages of the project development activity.
  • Clear: The plan, thus developed should be very clear to the developer and to the stakeholders regarding project requirements and other project details.
  • Correct: The project details will be very clear to stakeholders regarding product delivery date of its postponement or cancellation of the product
  • Constructible: The project development plan should be such that if by chance some design errors occur in product development then it should be constructible within small time span.

To achieve 5 C’s it is recognized that communication between stakeholders and developer is consistent.

1.3 Purpose

  • Consistent: The plan should follow the standard and guidelines set by naveze
  • Complete: The plan should include the overall representation of the project requirements, features, documentation of the project plan. Such plan should be developed through all the stages of the project development activity.

1.4 Objective

The main objective of the Quality Control Plan is to provide a mechanism by which all the plans are executed consistently without any design errors. It ensures that the procedures are continuously reviewed by the stakeholders and the designers. To achieve quality control, a project file document is created where feedback is given at regular intervals. Periodic review of the feedback results in appropriate changes in the development process.

1.5 Requirements of Quality Control

The basic requirements of Quality Control are to fulfil all the valid requirements of the project. It also requires planning, documentation of the project development activities, constant supervision of designer throughout the development process. It also requires the developer to ensure that all the project activities are co-ordinated and completed as per schedule and reviews are made periodically.

2. Project Quality Control Requirements

A Project Quality Control Plan is necessary for each project before starting the project work. 

Project Quality Control Plan: This plan gives the detailed information of methods & process that provides the good quality control for all work products. This plan is kept updated with the requirements of project. The plan includes the following parts:  naveze commits to the following principles and practices:

2.1 Quality Control Staff

Mainly the QC team at naveze contains following members:  

  • Product Manager
  • Quality Assurance Manager 
  • Engineers
  • Designer 
  • Testers

2.2 Quality Control Reviews

Every Project will undergo this review step. The reviewer is an experienced person who is not an active member of project development team. 

2.2.1 Checking Procedures
  • Checking Reports 
    • Avoid Redundant data 
    • Support for focusing on Major issues 
    • Makes data & structures consistent 
  • Checking Drawings/Prototypes
    • Provides the design according to the requirement of project 
    • Provides Complete & clear idea of project 
    • Provides Coordination with other aspects of the project – Backened/Frontend 
    • Gives Compatible standards and good plans preparation practice 
  • Checking Calculations 
  • Checking Correspondence 

2.3 Proposed method of documentation of comments, coordination responses and quality assurance records.

Documentation of Comments, Coordination and Responses through an updated Feedback Tracker 

The bugs reported through the testing process are updated on the JIRA board. 

3. Quality Control Activities

  • Check that assumptions and criteria for the user stories and the different factors related to these stories are documented. 
  • Check for transcription errors in data input and reference. 
  • Check the integrity of database files.
  • Check for consistency in data and database files.
  • Check that the movement of inventory data among processing steps is correct.
  • Undertake review of internal documentation.
  • Undertake completeness checks of the stories and processes.
  • Compare Results to previous Results and maintain a tracker to detect change.
  • Check the JIRA boards for updates which includes (Estimates/Story Points/Due Dates and Stories correct status update)
  • Maintain a Root Cause Analysis Document for Customer Complaints/Persistent Issues

3.1 Verification & Validation

Verification and Validation assures that a software system meets a user’s needs.  Verification: “Are we building the product right“. The software should conform to its specification.  

Validation: “Are we building the right product“. The software should do what the user really requires.  

Two principal objectives are:  

  • Discovery of defects in a system. 
  • Assessment of whether the system is usable in an operational situation. 

3.2 Testing

  • Unit testing – It is a type of software testing where individual units or components of a software are tested. The purpose is to validate that each unit of the software code performs as expected. Unit Testing is done during the development (coding phase) of an application by the developers.
  • Functional testing – Ensures that the requirements or specifications are properly satisfied by the application.
  • Integration testing – software and/or hardware components are combined and tested progressively until the entire system has been 
  • System testing – Performed on a complete integrated system to evaluate the compliance of the system with the corresponding requirements.
  • Usability testing – Usability testing is a technique used in user-centred interaction design to evaluate a product by testing it on users. This is an irreplaceable usability practice, since it gives direct input on how real users use the system.
  • Software performance testing – It is a testing method performed to determine the system performance in terms of speed, reliability and stability under varying workload.
  • Load testing – Load testing is the process of putting demand on a software system and measuring its response.
  • Installation testing – Most software systems have installation procedures that are needed before they can be used for their main purpose. Testing these procedures to achieve an installed software system that may be used is known as installation testing. This procedure may involve full or partial upgrades and install/uninstall processes.
  • Regression testing – Regression testing is re-running functional and non-functional tests to ensure that previously developed and tested software still performs after a change. If not, that would be called a regression.

3.3 Quality Process Activities

  • Agile Process with Scrum 
  • Daily Huddles – The team connects along with the Scrum Master to discuss the issues on the JIRA board.
  • Sprint Planning – The stories which will be picked up for the upcoming week. 
  • Retrospective Planning – Discussions with respect to what went wrong or the issues which couldn’t be fixed in the ongoing week. Usually happens on the last day of the week.
  • Two Week Development Sprint – Usually two weeks sprints are planned, depending on the user stories and complexity of the work.
  • One Week Testing – We follow continual feedback testing mechanism through the sprint cycles or two weeks development work and one-week testing.
  • Quality Feedback and Discussion with Team (Daily) – Agile way of testing having continuous feedback.
  • Any quality update/requirements/lapse is updated as Bugs on the JIRA board under respective projects.

Getting Help

To get help for interpretations, resolution of problems, and special situations please contact: Caroline Falkiner
CEO naveze
E: caroline@naveze
M:  0401 691 346

Related policies/References

For more information about related policies or procedures, guidelines, forms, etc View all related naveze policies at https://naveze.com/policies

Last Update: 01 July 2022