Software Quality Assurance (SQA) Process Procedure
What is Software Quality Assurance
The purpose of Software Quality Assurance (SQA) in a Project Management is to provide the relevant stakeholders with data on the deliverable’s adherence to the expected baselined standards, relevant guidelines and organizational process, by comparing against available artifacts and data submitted; by which deviations can be identified and rectified with immediate effect.
SQA process helps to evaluate and audit the software developmental life cycle processes and work products against applicable process descriptions, standards and procedures; to identify and document noncompliance issues, provide feedback to stakeholders on the results of audit and ensure that noncompliance issues are addressed with immediate effect. SQA applies to all phases defined in the SDLC.
Procedure for Software Quality Assurance Process
This section outlines the break-down of the Software Quality Assurance (SQA) procedures for granular clarity.
Sub-process / Activities
- Milestone based Audit: Milestone review will be performed for SDLC projects – In milestone based audit, the specific milestones mentioned in the Project Plan is scrutinized for quality assurance and adherence to standards.
- The Audit Plan is published by the PPQA Lead and thereby the relevant stakeholders are notified for preparations through a schedule plan.
- The pre-approved Audit Checklist is prepped and applied to the task.
- The SQA Lead selects a project for scrutiny and kicks-off the audit process.
- The relevant data should be made available to the SQA Lead from the respective Project Manager. The data can be the respective project artifacts from that phase of SDLC, examples are:
- Project Plan
- Estimation sheet
- Statement of Work and Risk Register
- Scoping Document and Baselined Specification Requirements from Client
- Entry and Exit criteria definitions for Build and Test phase
- Requirement Traceability Matrix
- Development and Test Oracles
- Unit Test and Integrated Test artifacts
- Reports from Unit and Integrated tests
- User Acceptance Testing / Client feedback / Minutes of Meeting with relevant stakeholders
- The Process Checklist is used as a yardstick to measure and gauge the adherence of the processes and presented artifacts of that particular Milestone / Project phase for compliance and deviations.
- Based on the scrutiny, an Evaluation Report is prepared against the Milestone phase.
- The Evaluation Report will contain a detailed summary on the adherence and non-compliance factors against process and artifacts for that specific Milestone / project. It can be captured in %-wise factor.
- The report will be shared and discussed with the respective Project Owner for mitigation steps, wherein the Project Owner will be given a deadline to furnish the missing artifacts to cover for the skipped processes.
- Once the missing artifacts are made available to the SQA Lead and is scrutinized specific to the phase / project.
- Re-evaluation of the artifact against the defined standards is performed again by SQA Lead.
- The process team will have to perform a Causal Analysis, if certain non-conformities are recurrent, in the project, and settle for mitigation, in agreement with the project teams.
- The Evaluation Report will be presented to the Process Owners for their perusal by the SQA Lead.
The Quality Assurance will involve the following activities –
- Milestone audits ( phase audits )
- Periodic Audits
Milestone review will be performed for SDLC projects.
1. Periodic & Milestone Based Audits ( Phase Audits )
Audit Council members will perform the periodic and milestone based audit for SDLC projects. The scope of the milestone based audit will be limited to the particular milestone / phase,
Periodic audits will be conducted as per the audit calendar published for the month. Audits will be performed on the organization audit checklist, for every project. The auditor will mark non compliances, with partial and full compliance as applicable, in the checklist.
Audits will also be performed on the organization audit checklist for the Training Cell. The auditor will mark non compliances, with partial and full compliance as applicable, in the checklist.
The auditee (project teams/Training Cell) will be asked to review the NCs raised, and propose a corrective action against each NC, within a stipulated time.
The process team will perform a Causal Analysis, if certain non-conformities are recurrent, in the project, and settle for mitigation, in agreement with the project teams.
Project teams will measure the % compliance, and will reflect this in the organization baseline for compliance.
Each project team will be asked to predict the % compliance based on some influencing factors, at the beginning of the project
Project teams will be required to match the percentage predicted across the execution of the project. The process team will prepare an audit report, for each project and the Training Cell, and share it with the project team and relevant stakeholders.
3. Audit Items
Given below is a list of Activities, general Artifacts and Process that are to be audited during various phases of the project. The list here is comprehensive, and can be tailored as per the project requirements. The list may not apply to certain project categories, in which case, alternative evidence will be audited to make sure that the process is followed.
The list of Audit Items for each phase of the Software Lifecycle is given below.
Audit Items( Process and Product)
Guidelines for SQA
The Quality Assurance activities are based on the standard practices and guidelines which underline the better understanding of this complex process.
Guideline 1. Communication with all stakeholders involved.
Communication with all relevant stakeholders is very much integral to the success of the program. The communication should not be open-ended and objective, matching the goals and definitions of the process area.
Guideline 2. Publishing the plan and meeting the target dates.
A mutually agreeable plan for audit and review should be published between PPQA Lead and the Project Owner(s) before the SQA task.
Guideline 3. Audit based on Milestone or Periodic timetable.
The quality of the shippable deliverable will be under tight checks if the audits are properly spaced, timed and periodic. This provides high-level answer to the question “How does the product adhere conformance to the specification?”
Guideline 4. Documentation of Adherence and Non Compliance factors
The adherence and non-compliance issues should be documented in detail. The non-compliance records should be closed at the earliest post discussion with the respective project owner.