Quality depends on requirements and context
A behaviour becomes a defect when it violates an explicit or implied need. The same behaviour can be judged differently across products, users, and settings.
SECTION 01
Define quality before judging it
Quality is not an abstract sense of “good.” It is the extent to which a product satisfies requirements, user goals, and risk constraints.
Core definition
Defect = behaviour that does not conform to requirements; Quality = fitness for purpose in a specific context.
A defect is therefore contextual. Poor mobile rendering may not violate the requirements of an explicitly desktop-only product; it becomes a quality issue when target users need mobile access.
SQA
Quality Assurance
Organisation- and process-oriented. Standards, plans, roles, and preventive activities improve development processes and reduce the creation of errors.
SQC
Quality Control
Product- and outcome-oriented. Inspection and verification confirm that deliverables meet agreed quality requirements before release.
TEST
Testing
An execution-level activity that finds technical issues and evaluates functionality, usability, performance, security, and compatibility.
Key distinction
Testing ≠ quality assurance. Testing tells a team where problems exist; quality assurance focuses on preventing them. High quality comes from the full lifecycle, not a final testing gate.
| Concept | Question | Management meaning | Example |
|---|---|---|---|
| Severity | How large is the impact? | Describes technical or business consequences. Sev 1 commonly means the system is unavailable with no workaround. | The payment flow is completely unavailable. |
| Priority | How quickly should it be addressed? | Orders work using severity, urgency, user visibility, and business timing. | Correct a homepage brand typo before a launch campaign. |
| Acceptable defects | Is the residual risk acceptable? | Ordinary systems can trade off risk; critical systems should drive acceptable defects towards zero. | An aviation-control failure cannot be accepted as “fix later.” |
Defect targets: Six Sigma to Zero Defects
The lecture uses Six Sigma's approximately 3.4 defects per million opportunities to illustrate a low-defect target, and Crosby's Zero Defects to express a preventive mindset: defects are not inevitable. These are quality aspirations, not one universal acceptance threshold.
Whole-system view
Failures can originate in people (users and teams), processes (rules, hand-offs, and decisions), or technology (code, devices, and infrastructure). Effective improvement addresses systemic causes, not just surface bugs.
Safety-critical
Failure may cause death, serious injury, major property damage, or environmental harm—for example, aviation, chemical-processing, and nuclear systems.
Mission-critical
Failure significantly disrupts core operations and may threaten organisational survival, such as a production system that depends heavily on electricity.
Business-critical
Failure creates very high business costs, such as unavailable core banking services, interrupted transactions, or large-scale customer loss.
SECTION 02
Make “good” measurable
Defect counts alone are insufficient. Complete measurement covers internal structure, external behaviour, and outcomes for users in real contexts.
Internal quality
Structural properties observable without running the software, such as architectural weaknesses, complexity, maintainability, and static-analysis findings.
External quality
Behaviour shown while the software runs, such as errors, response time, resource use, recoverability, and compatibility.
Quality in use
Outcomes users achieve while completing goals: effectiveness, productivity, safety, and satisfaction. It ultimately answers “is it fit for purpose?”
Quality in use
ISO 9126's quality-in-use model focuses on four outcomes: effectiveness, productivity, safety, and satisfaction. Internally elegant code does not automatically mean user success.
| Quality dimension | Question to answer | Measures / methods in the materials |
|---|---|---|
| Defects | How many deviations from requirements exist, and how much do they matter? | Defect count; severity and priority classification; production defects. |
| Reliability | How long can the system operate reliably? Do changes break existing behaviour? | Production defects, load testing, regression testing, downtime behaviour. |
| Performance efficiency | Does the system remain responsive within given time and resource constraints? | Stress testing, soak testing, application performance monitoring (APM). |
| Security | Can information and systems resist unauthorised access and exploitation? | Vulnerability count, patch deployment rate, time to resolve vulnerabilities. |
| Maintainability | How easy is the software to modify, understand, hand over, and extend? | Lines of code, cyclomatic complexity, ISO 5055 structural weaknesses. |
| Delivery | Can the team deliver value to users continuously and safely? | Number / frequency of releases; speed of testing feedback. |
Measurement principle
Measures must connect to requirements, risk, and decisions. An isolated number can create an illusion of control. Ask what action it will change before deciding to collect it.
SECTION 03
Three standards, three layers
Treat the standards as complementary views: a product-quality model, source-code structural measurement, and organisation-level information-security management.
ISO/IEC 9126
Establishes a common language for software product quality across four parts: quality model, external metrics, internal metrics, and quality-in-use metrics.
- Six product characteristics
- Four quality-in-use characteristics
- Replaced by ISO/IEC 25010 in 2011
ISO/IEC 5055
Uses static analysis to measure internal software structure and find severe weaknesses that can harm operations or raise IT costs.
- Reliability and security
- Performance efficiency and maintainability
- Unit- and system-level coverage across technology-stack connections
ISO/IEC 27001
Defines requirements to implement, maintain, and continually improve an Information Security Management System (ISMS), protecting the CIA triad.
- Confidentiality
- Integrity
- Availability
| Standard | Primary object | Core purpose | Typical outputs |
|---|---|---|---|
| 9126 / 25010 | Software product and outcomes in use | Defines the dimensions of quality and supports quality requirements and evaluation models. | Characteristics, sub-characteristics, and internal / external / in-use measures. |
| 5055 | Internal source-code structure | Automatically finds dangerous architectural and component weaknesses before operational incidents. | Weakness counts / density, quality targets, release or supplier acceptance gates. |
| 27001 | An organisation's information-security management system | Builds a risk-based loop of policy, controls, audit, and continual improvement. | ISMS scope, risk treatment, controls, internal audit, and management review. |
Why ISO 5055 matters
Traditional operational measures mostly show after-the-fact outcomes. ISO 5055 inspects internal construction, finding SQL injection, unreleased resources, authentication-bypass paths, and other structural weaknesses during development and acceptance. Its measures can become RFP, SOW, contract, release, and technical-debt targets.
ISO 27001: PDCA thinking
Plan: identify scope and risk. Do: implement policies, processes, and controls. Check: monitor, audit, and conduct management reviews. Act: correct and continually improve. The 2022 Annex A reorganises 93 controls into organisational, people, physical, and technological groups.
SECTION 04
Build quality across the lifecycle
Shift-left is not about mechanically moving every test earlier. It brings feedback, questions, and risk judgement forward.
Clarify requirements
Identify users, problems, use environments, success measures, load, security, and update needs.
Validate the design
Use prototypes, alternative designs, design reviews, and usability testing to avoid solving the wrong problem beautifully.
Build in quality
Use TDD, pair programming, testable code, static analysis, and small integrations.
Verify in layers
Use unit, integration, end-to-end, and exploratory tests, formal technical reviews, and UAT.
Learn in operation
Monitor real performance, user feedback, defect trends, and patches while continuously paying down technical debt.
E2E / UIFew · slow · expensive · sensitive to UI change
IntegrationVerify collaboration among services, databases, and file systems
Unit testsMany · fast · inexpensive · frequent feedback
Strategic testing pyramid
Layer your automation investment
Unit tests form a large, fast base. Integration tests verify collaboration among components. A small E2E layer covers critical user journeys but costs the most to write and maintain.
Do not pick one side: automation suits stable, repetitive, high-frequency work; human exploration suits unknown risks, usability, edge behaviour, and judgement-heavy scenarios.
TDD · Red → Green → Refactor
Write a failing test, add the minimum implementation to pass it, then refactor while keeping tests green. Benefits include rapid feedback, executable documentation, clearer code, and lower late-stage debugging costs.
Formal Technical Review
Use formal reviews, walkthroughs, or inspections to find functional, logical, and standards deviations early. Record what was reviewed, who participated, and the findings and decisions.
User Acceptance Testing
Ask appropriate subject-matter experts and end users to verify contractual, regulatory, operational, and real-use needs. Test user documentation and training as well.
CI / CD
Integrate frequently and run automated tests on each change. Only changes that pass quality gates enter the sustainable release flow, shortening feedback cycles.
Exploratory / Ad hoc
Exploratory testing learns and designs tests at the same time within a scope; ad hoc testing is more random and driven by error guessing. Both can uncover behaviour missed by scripted tests.
Effective bug report
Report one issue per ticket with a clear summary, environment, reproduction steps, actual and expected results, and evidence. Confirm reproducibility first and state frequency when relevant.
V-model lesson
Earlier errors become more expensive: a wrong requirement propagates into design, code, and tests. Agile does not remove this effect; every iteration should revalidate the problem statement, user stories, and design assumptions.
SECTION 05
Poor quality is not “just a bug”
It amplifies across technical, operational, customer, and legal pathways, while technical debt turns today's speed into tomorrow's resistance.
These figures are CISQ / Synopsys estimates cited by the course materials. They show scale and risk structure; categories may overlap and should not simply be added together.
Misunderstood requirements→
Shallow / delayed testing→
Production defects→
Downtime / breach / data loss→
Revenue and reputation loss→
Complaints, regulation, and litigation
Reputation
Poor experiences quickly become app-store ratings and social-media sentiment. They damage the current product and create negative expectations for future products.
Revenue & technical debt
Skipping unit and regression tests can create short-term speed, but increases side effects, maintenance costs, and the risk of failed modernisation.
Legal & social impact
Accessibility, security vulnerabilities, privacy, data loss, and downtime can trigger penalties or litigation. Software now shapes the real world.
Supply-chain first step: SBOM
Maintain a software bill of materials for third-party and open-source components. When a new vulnerability appears, the team can locate affected systems, assess risk, and patch promptly.
DevQualOps
Add explicit quality activities and gates to high-velocity Agile, DevOps, and DevSecOps delivery, supported by automated analysis, operational monitoring, and continuous technical-debt management.
SECTION 06
Turn principles into team behaviour
The most effective quality management does not come from buying more tools. It aligns people, processes, technology, and decision-making.
DO
- Write testable requirements and code; use TDD where it fits.
- Automate regression, smoke, load, and repeated cross-environment tests.
- Use cloud test environments to broaden browser, device, and OS coverage.
- Use low-code tools where they add value and reuse test assets.
- Define a test strategy and invest in layered testing.
- Make development, QA, users, and business jointly responsible for quality.
DON'T
- Change scope and deadlines unilaterally without engineering input.
- Blame individuals for bugs while ignoring requirements, process, and system complexity.
- Adopt a tool only because it is free or popular, without considering skills and maintenance cost.
- Silo development and QA, then hand work over for testing at the end.
- Treat manual and automated testing as a binary choice.
- Scatter test data across disconnected tools and lose the whole-system view.
Planning-document hierarchy
A test policy defines organisational principles; a quality management plan defines project quality goals and responsibilities; a test strategy defines the product-level approach; a test plan says what, when, how, and who.
A healthy QA environment
Clarify roles, respect testers, provide business training, encourage direct development–QA communication, and improve collaboration through retrospectives.
Purpose of test-management tools
Connect requirements, test cases, environments, execution results, defects, and KPIs to improve traceability and visibility. Tools should serve the process, not replace thinking.
SECTION 07
Apply it to an IE / team project
Turn Week 06 into a quality roadmap the team can use now.
Define “fit for purpose”
- Who are the target users? Do client and user needs conflict?
- What problem does the product solve? How is success measured?
- When, where, and on what devices will people use it?
- Is failure ordinary, business-critical, or more severe?
Find errors before implementation
- Write clear user stories and verifiable acceptance criteria.
- Validate critical flows with prototypes and alternative designs.
- Invite real users to participate in usability testing.
- Define load, authorisation, database-attack, and update strategies.
Build continuous feedback
- Build a unit-test base, then add critical integration and E2E tests.
- Run automated regression and static analysis in CI.
- Use pair programming / reviews for high-risk changes.
- Record dependencies and component versions; maintain an SBOM.
Use evidence to decide release
- Organise defects by severity × priority.
- Ask users to complete critical tasks and provide UAT evidence.
- Test user documentation, training, and recovery procedures.
- Share measures, residual risk, and release advice with stakeholders.
Team responsibility
Quality decisions are professional responsibilities. Explain risk, evidence, trade-offs, and residual uncertainty clearly to non-technical stakeholders; “the tests passed” is not enough.
SECTION 08
Three memory aids + eight checks
Remember the structure first, then add detail. Select a question to reveal the reference answer.
SQA manages process and prevention; SQC manages product conformity; testing finds and evaluates problems.
Functionality, reliability, usability, efficiency, maintainability, and portability.
Reliability, security, performance efficiency, and maintainability—the business-critical structural factors in source code.
1. Why can the same software behaviour be a defect in one project but not another?
A defect is judged against requirements and context of use. If the behaviour does not violate target-user, functional, or environmental needs, it may not be a defect for that product. The judgement changes when requirements change.
2. What is the difference between severity and priority?
Severity describes impact; priority describes urgency of treatment. High-severity issues are often high priority, but business timing, visibility, and workarounds can change the order.
3. Why can “more testing” not guarantee quality by itself?
Testing mainly exposes existing problems. If wrong requirements, poor designs, broken processes, and communication problems have entered the product, end-stage testing can only reveal them at high rework cost.
4. What problems do ISO 9126, ISO 5055, and ISO 27001 address?
ISO 9126 provides a software product-quality model; ISO 5055 automatically measures critical structural weaknesses in source code; ISO 27001 establishes an organisation-level ISMS and continual-improvement loop.
5. If shift-left does not mean “move every test to the start,” what does it mean?
It brings requirements review, risk identification, test design, automated feedback, and cross-functional collaboration forward to prevent problems and shorten find–fix cycles. Shift-right feedback in operation remains important.
6. Why does the testing pyramid recommend many unit tests and few E2E tests?
Unit tests are fast, stable, and inexpensive, making them suitable for frequent feedback. E2E tests cover real journeys but run slowly, cost more to maintain, and are more likely to be flaky, so they should focus on a few critical flows.
7. Why is security part of reliability?
Unauthorised access, database attacks, supply-chain vulnerabilities, and failed patching can make systems unavailable, damage data, or cause incorrect behaviour. A system that cannot resist these threats is not reliable.
8. Why does the cost of poor software quality keep accumulating?
Production failures, cybercrime, defect repair, legacy systems, and failed development create direct losses. Unpaid technical debt then slows future change and raises regression risk, creating a reinforcing loop.
SECTION 09
Own-time material index
Course visual and caption links use local copies; article links return to their original web sources for checking.
- Quality Measurement and Management visualCourse visual summary
- Measuring and Managing quality14:11 automatic captions; obvious transcription errors are corrected contextually here
- What Determines Software Quality?Source-status record: the target page was replaced by unrelated content
- The $2t cost of poor software qualityEconomic cost, supply chain, technical debt, and DevQualOps
- What Happens When Testing Goes Wrong?Reputation, surprises, revenue, feedback delay, and litigation
- Improve Software TestingEleven testing and QA improvement practices
- Software Quality Management Best Practices5 Do's & Don'ts
- Software Quality Standards — ISO 5055Automated measurement of structural source-code quality
- ISO/IEC 9126 in Software EngineeringProduct-quality model, metrics, and history
- Purpose of ISO 27001ISMS, CIA, implementation stages, and controls
Material boundary: The listed Code Quality Podcast has no local captions or transcript, so this guide does not invent its content. The target page for “What Determines Software Quality?” has also become unavailable. This page summarises only verifiable local materials and excludes real-time cases.
