SE C7 Software Quality Assurance Quiz

Lecture 7: Software Quality

• Software quality is defined as a developed product meeting its specifications.
• Problems include: Requirements exceeding customer specifications, ambiguous quality characteristics (e.g., maintainability), and users not involved in requirements development, potentially leading to products deemed low quality, even if they meet specifications.
• Quality can be understood in terms of "fitness for purpose".
• Customer perception of quality is crucial.
• Observable factors (e.g., user interface, freedom from faults) are easier to evaluate than less obvious aspects (e.g., security, future upgrades).
• Customers don't always articulate their needs clearly.
• Making quality software is about meeting customer needs, not just what they say they want.

Software Quality Assurance (SQA)

• SQA is a systematic approach to ensuring software products and processes meet quality standards and customer needs.

• SQA encompasses more than just testing.

• It involves a range of practices to reduce the risks of developing low-quality products.

• SQA includes Software Quality Planning (SOP), Software Quality Control (SQC), and Software Quality Metrics (SOM).

  • Processes and standards for creating software are selected and tailored to the specific quality objectives.
  • Definition & implementation of processes to ensure quality procedures and standards are followed.
  • Collection and analysis of quality data to predict and control quality throughout the software development lifecycle.

SQA Umbrella (Components)

• Product Assessment
• Test Management
• Test Planning
• Test Development
• Test Automation
• Test Execution
• QA Project Management
• Defect Management
• Triage
• Metrics
• Audits
• Process Assessment
• Process Improvement
• Risk Management
• Estimating and Scheduling
• Release Criteria
• Defect Reporting
• Release Process
• Project Retrospective
• Change Management
• Peer Reviews & Inspections
• Verification & Validation

SQA - Iceberg Analogy

• External Quality: Visible aspects like correctness, efficiency, reliability, and maintenance cost.
• Internal Quality: Less visible aspects like program structure, complexity, coding practices, testability, coupling, maintainability, readability, and reusability.

Why are Standards Important?

• Standards encapsulate best practices.
• They provide a framework for quality assurance implementation.
• They ensure consistency across projects, no matter who implements the processes.

SDS (Systems Development Standards)

• ISO 9000 isn't the only standard source for SDS.
• Process and product standards are derived independently.
• Product standards are not created only by the SQA group.

Quality Standards (e.g. ISO 9001:2000)

• Standards like ISO 9001:2000 define quality management systems, specifying requirements for documentation, procedures, and activities.
• Ensure quality throughout a project's lifecycle

ISO - 9001 Elements (Key Components)

• Various quality system requirements, including management responsibility, contract review, design control, document controls, purchasing, product identification and traceability, process control, inspection and testing, corrective action, quality records, internal audits, training, and statistical techniques. These govern all aspects of the software development process.

Process and Product Quality

• Quality of the development process directly affects the quality of delivered products.

Obtaining Quality: Quality Control & Assurance

• Quality Control: Measures quality of produced products via testing methods (integration testing, code reviews).
• Quality Assurance: Focuses on the development process itself, ensuring all procedures are correctly followed (e.g., testing at all stages).

Methods of Software Quality Control (SQC)

• Quality Reviews: In-process reviews of processes and products.
• Tests (e.g., Unit Tests, SQE Dry-runs, TFR): End-result verifications to check if procedures are correctly implemented.
• Quality Audits: In-process verifications to ensure compliance with process standards.

Quality Reviews (Types - Peer Reviews, Walkthroughs, Desk Inspections)

• Peer reviews involve groups, while walkthroughs are group-based discussions about products.
• Desk inspections are individual reviews.

Tests (Engineering Dry-runs, SQE Dry-runs, TFR)

• Engineering dry-runs are conducted by engineers without SQA involvement, used to check correctness, etc.
• SQE dry-runs are done by the SQE before formal customer testing and involve the end-product.
• TFR (Testing for record) are conducted as the final customer test, and SQE is involved.

Quality Audits (SQE Audits, Independent Audits)

• SQE Audits: Verify that procedures are followed by evaluating tasks, and escalating issues not addressed.
• Independent Audits: Conducted by a third party to confirm process validity through external means.

Defect Detection Process and Metrics

• Analyzing the frequency of defects arising from each development stage, and from different test phases.

Defect Prevention Strategies

• Lessons learned from previous projects.
• Risk analysis to identify potential issues early-on.
• Standardized testing guidelines, and creating a fixed/freeze point for code.
• Baseline Acceptance Criteria and ensuring testing (No P1 STRs in FAT TRR).

Continuity and Independence of SQA

• An independent team is crucial for an objective perspective.
• Tailored standards based on the specific project requirements, not using a one-size-fits-all approach.
• Emphasizing that quality is everyone's responsibility.
• The SQA teams' role is to assist the development team in creating high-quality software, not to entirely manage the project.

The SQA Plan

• Preparing an SQA plan at the start of a project provides structure to quality assurance activities

SQA Activities

• Assist with process selection for a specific project.
• Review software engineering activities and products to ensure project/process compliance.
• Document all process deviations for correction.
• Detail any non-compliances for management review.

Reliability Concepts

• Reliability: A broad concept measuring how frequently a software crashes or has issues.
• Fault vs. Failure: fault is the issue, failure is the consequence.
• Time aspects of reliability include execution time and calendar time between failures.
• Definitions of Reliability: Probability of error-free operation over a given time in a specific environment or in relation to failure intensity (the frequency of failure).
• Factors Influencing Reliability: The size and complexity of the code, the development process, and even the environment in which the product is operated.