Quality & Process Maturity

1. What is software quality?

Software quality is the degree to which a software product satisfies its stated and implied requirements — and more broadly, how well it meets the needs of its users. It is not one thing but a collection of qualities.

The two classic definitions come from different angles. Conformance to requirements: the software does what was specified, so quality is measured by whether the delivered product matches its specification. Fitness for use: the software does what its users actually need it to do, so quality is measured by whether the product is useful in the real world. A product can conform perfectly to a bad specification and still be poor quality — which is why fitness for use matters.

Quality is multi-dimensional, captured in quality attributes: functionality (does it work), reliability (does it stay working), usability (can people use it), efficiency (is it fast enough), maintainability (can it be changed), portability (does it run where needed), and security. The interview point: quality is not a single score — it is conformance plus fitness, evaluated across many attributes, and it is everyone’s responsibility, not just the testers’.

2. What is Software Quality Assurance?

Software Quality Assurance (SQA) is a process-oriented discipline that ensures the quality of the processes used to build the software — on the premise that good processes produce good products. It is preventive: it focuses on making sure the development process is defined, followed, and continuously improved.

SQA is planned and systematic. It involves defining quality standards and processes, auditing that teams follow them, reviewing deliverables against standards, collecting quality metrics, and driving process improvement. SQA engineers act as process auditors — they ask “are we following the process?” and “is the process capable of producing quality?” — rather than finding bugs in the product.

SQA is different from testing and Quality Control in a critical way. SQA is about the process — preventing defects by ensuring the way work is done is sound. Quality Control is about the product — detecting defects in the finished work. Testing is one QC activity. The common analogy: SQA is a cooking teacher making sure the recipe is good and followed; QC is the taster checking the dish; testing is the taster’s method.

3. What is Quality Control?

Quality Control (QC) is the product-oriented activity of detecting and correcting defects in the software that has been produced. Where Quality Assurance focuses on the process, QC focuses on the output — finding and fixing what is wrong with the product.

QC activities include all forms of testing — unit, integration, system, acceptance — as well as reviews, inspections, and defect detection in finished deliverables. QC verifies that the product meets its requirements and quality standards. It is reactive in the sense that it examines the product after it is produced.

The relationship between QA and QC is the classic interview question. QA is process-oriented and preventive — it ensures the process that builds software is capable, so defects do not happen. QC is product-oriented and detective — it finds defects that did happen. QA establishes the net; QC catches the fish that escape. Both are necessary: QC without QA means endlessly finding defects that a better process would prevent; QA without QC means trusting the process without ever checking the product.

4. What is the difference between QA and QC?

Quality Assurance (QA) focuses on the process; Quality Control (QC) focuses on the product. QA is preventive, QC is detective.

QA is process-oriented: it ensures that the way the software is built — the processes, standards, and procedures — is defined, followed, and capable of producing quality. It is a planned, systematic activity that includes process definition, audits, standards, and metrics, and its goal is to prevent defects from being introduced. SQA is about “are we building it the right way?”

QC is product-oriented: it detects and corrects defects in the delivered work. It includes testing, reviews, and inspections of the finished product, and its goal is to find defects that did get introduced. QC is about “does the product we built meet the requirements?”

The relationship: QA creates the conditions for quality; QC verifies the results. QA is applied to the process before and during development; QC is applied to the product as it is produced. QA is everyone’s responsibility through process discipline; QC is often specialized (testers). And the important point — QA cannot guarantee quality by itself; it must be complemented by QC to verify the output. Quality is a result of both: prevention reduces defects, detection finds the ones that remain.

5. What is a quality model?

A quality model is a framework that decomposes the abstract notion of software quality into measurable characteristics and sub-characteristics. It gives the team a structured way to define, evaluate, and compare quality.

The most important quality model is ISO/IEC 25010, which defines quality in two parts: quality in use (the product’s effect when used — effectiveness, efficiency, satisfaction, freedom from risk) and product quality (eight characteristics: functional suitability, performance efficiency, compatibility, usability, reliability, security, maintainability, portability). Each characteristic breaks down into sub-characteristics — for example, reliability includes maturity, availability, fault tolerance, and recoverability.

An older but historically important model is McCall’s quality model, which groups quality factors into three views: product revision (maintainability, flexibility, testability), product transition (portability, reusability, interoperability), and product operation (correctness, reliability, efficiency, integrity, usability). The interview point: a quality model turns “make it good” into a checklist of specific, targetable characteristics, so quality can be specified, measured, and tested.

6. What are software quality attributes?

Software quality attributes are the measurable properties of a system that define its quality — the “ilities” and “-abilities” that stakeholders care about. They are the concrete dimensions on which quality is judged and tested.

The core attributes: functionality (does it do what it should), reliability (does it work without failure over time), availability (is it up when needed), usability (can users use it effectively), performance/efficiency (does it respond fast enough and use resources reasonably), security (does it resist attack and protect data), maintainability (how easily it can be changed and fixed), portability (does it run on the platforms required), and scalability (does it handle growth).

Quality attributes are the non-functional requirements of the system, and they are often in tension — security versus usability, performance versus maintainability, portability versus efficiency. The architecture exists largely to satisfy these attributes, because they are the properties that must hold at scale and over time, and they are notoriously hard to retrofit. The interview point: functional requirements define what the system does; quality attributes define how well it does it — and choosing the right balance of attributes is a core architectural decision.

7. What is process improvement?

Process improvement is the systematic effort to make the software development process better — more predictable, more efficient, and higher quality — by analyzing how work is done, identifying weaknesses, and making changes. It is based on the principle that the quality of the product is limited by the quality of the process.

The improvement loop is continuous: measure the current process, analyze where problems and inefficiencies are, define improvements, implement them, and measure again to verify they worked. The cycle is captured in the PDCA (Plan-Do-Check-Act) model and in the principle of continuous improvement from Lean and Kaizen.

Process improvement is usually guided by maturity models and standards — CMMI, ISO 9001, Agile retrospectives — which provide the framework and the assessment. In Agile, the retrospective is the native process improvement mechanism: the team reflects and adjusts every sprint. The interview point: process improvement treats the development process as a product in its own right — something to be measured, improved, and maintained — because a better process consistently produces better software.

8. What is CMM?

CMM — the Capability Maturity Model — is a framework for assessing and improving an organization’s software process, developed by the Software Engineering Institute (SEI) in the 1980s. It describes the maturity of an organization’s software process in five levels.

The five levels, from least to most mature: Level 1 — Initial: the process is ad hoc and chaotic; success depends on individual heroics. Level 2 — Repeatable: basic project management is established; successful practices are repeated. Level 3 — Defined: the process is documented and standardized across the organization. Level 4 — Managed: the process is measured quantitatively and controlled. Level 5 — Optimizing: the process is continuously improved through quantitative feedback and innovation.

The model’s premise is that process maturity drives product quality and predictability — a mature organization delivers predictable schedules, costs, and quality, while an immature one depends on luck and individual effort. CMM was later succeeded by CMMI, which integrated software, systems, and other disciplines into one model and added a representation with both staged and continuous views. The interview point: CMM is a ladder of process maturity, and an organization’s level indicates how controlled and improvable its process is.

9. What is CMMI?

CMMI — the Capability Maturity Model Integration — is a model for process improvement that succeeds CMM. It integrates multiple disciplines (software, systems engineering, product development) into a single framework and provides guidance for improving an organization’s processes.

CMMI comes in two representations. The staged representation uses five maturity levels, like CMM, describing the organization’s overall maturity: Initial, Managed, Defined, Quantitatively Managed, and Optimizing. The continuous representation uses capability levels (0–3) applied to individual process areas, letting an organization improve specific areas without committing to the whole ladder. The process areas span engineering, project management, process management, and support — such as requirements development, project planning, risk management, and process and product quality assurance.

CMMI is used both as an improvement roadmap and as a procurement certification — many organizations require suppliers to hold a CMMI level. Its value is making the process visible and improvable in a structured, assessed way. The interview distinction: CMM was the original software-only model; CMMI is its integrated successor covering software, systems, and services, with maturity levels (staged) or capability levels (continuous).

10. What are the maturity levels of CMMI?

CMMI’s staged representation defines five maturity levels that describe how mature and controlled an organization’s processes are.

Level 1 — Initial: processes are unpredictable and ad hoc; success depends on individual effort and often luck. Level 2 — Managed: projects are planned, managed, and measured against plans; the process is repeatable at the project level. Level 3 — Defined: processes are documented, standardized, and tailored from organization-wide standards; the process is consistent across projects. Level 4 — Quantitatively Managed: the organization measures its processes statistically and manages them with quantitative goals; quality and performance are predictable. Level 5 — Optimizing: the organization continuously improves its processes using quantitative feedback and innovation; process and product are both optimized.

The levels are a staircase — each requires the discipline of the level below. An organization at Level 5 not only executes its process well (Levels 2–3) and measures it (Level 4), but systematically improves it. The maturity levels matter because they give an organization — and its customers — a common language for process capability, and certification at a level is a market signal. The interview point: list the five levels in order — Initial, Managed, Defined, Quantitatively Managed, Optimizing — and describe what each requires.

11. What is ISO 9001?

ISO 9001 is an international standard that specifies requirements for a quality management system (QMS) — the set of policies, processes, and records an organization uses to ensure its products and services meet customer and regulatory requirements. It is the most widely used quality management standard in the world.

ISO 9001 is not a product standard — it does not say what a good product is. It is a process standard: it requires an organization to define its processes, document them, monitor them, and continuously improve them. Its core principles include customer focus, leadership, engagement of people, process approach, improvement, evidence-based decision making, and relationship management. Its structure follows the Plan-Do-Check-Act cycle.

Organizations get certified by an accredited body after an audit demonstrates their QMS meets the requirements, and certification is widely demanded by customers and industries. For a software organization, ISO 9001 certifies that its development and service processes are documented, controlled, and improved — complementary to CMMI, which is specifically about software process maturity. The interview point: ISO 9001 governs the quality management system; CMMI governs software process capability — both are process, not product, standards.

12. What is Six Sigma?

Six Sigma is a disciplined, data-driven methodology for improving quality by reducing defects and variation in processes. Its goal is to get a process to a level of performance where the defect rate is so low it is measured in defects per million opportunities — statistically, 3.4 defects per million, the “six sigma” level.

Six Sigma uses the DMAIC cycle for improving existing processes: Define the problem and goals; Measure the current process; Analyze the root causes of defects; Improve the process to remove them; Control the process to hold the gains. For designing new processes, the variant is DMADV (Define, Measure, Analyze, Design, Verify). It emphasizes statistical measurement, root-cause analysis, and fact-based decisions over opinions.

Six Sigma originated in manufacturing (Motorola, then GE) and has been adapted to software and services. Its value in software: it brings statistical rigor to process quality — measuring defect rates, controlling variation in effort and schedule, and systematically removing defect causes. The interview point: Six Sigma is about reducing process variation and defects through statistical methods and the DMAIC cycle — and it differs from models like CMMI in that it is a methodology focused on defect reduction rather than a maturity certification.

13. What is defect prevention?

Defect prevention is the strategy of eliminating defects at their source — analyzing why defects occur and changing the process so they do not happen again. It is the opposite of defect detection: instead of finding and fixing defects after they are made, it stops them from being introduced.

The mechanism is root-cause analysis. When a defect occurs, the team analyzes why it happened — was it an ambiguous requirement, a missing review, an unhandled edge case, a communication gap? — and then changes the process to prevent the same cause. Common defect prevention practices include: requirements reviews and checklists; code reviews and inspections; test-driven development; standard templates; training; and the analysis of defect patterns to target weak process areas.

Defect prevention is the heart of Quality Assurance and the premise of process improvement — it is why SQA and models like CMMI focus on process rather than just product. Its economics are compelling: preventing a defect is far cheaper than finding it, and far cheaper than fixing it. The interview point: defect prevention shifts the cost curve by moving effort from finding defects (QC) to preventing them (QA) — through root-cause analysis, reviews, and process change.

14. What is continuous process improvement?

Continuous process improvement is the ongoing effort to improve products, services, and processes incrementally and constantly — the belief that the process can always be better and should always be getting better. It is the philosophy at the top of the maturity ladder.

The loop is iterative: measure, analyze, improve, and measure again. The PDCA (Plan-Do-Check-Act) cycle is the classic model — plan a change, do it on a small scale, check the results, act on what was learned, then repeat. Related concepts include Kaizen (the Japanese philosophy of continuous small improvements) and the PDSA variant used in improvement science.

In software, continuous process improvement appears in many forms: Agile retrospectives where the team adjusts every sprint; the CMMI Level 5 “Optimizing” stage; Lean’s elimination of waste; and the systematic analysis of defect and process metrics. Its key traits: it is continuous (never a one-time project), incremental (small, sustainable changes rather than big-bang overhauls), data-driven (changes are based on measurement), and cultural (it is a mindset, not a task). The interview point: continuous process improvement is the ongoing, incremental, measurement-driven refinement of how the team works — and in mature organizations it is a normal part of the rhythm, not a special project.