Subject intro · Quality · Testing · Terminology · 7 Principles
→ next slide | ESC overview
1. Welcome & Intro — who are we, what is this course, how does it work
2. What is Quality? — fit for purpose, reliable, maintainable, not just "bug-free"
3. Why Test? — real-world failures, cost of bugs, risk reduction, trust
4. Terminology — Verification vs Validation, Error vs Bug vs Failure, ISTQB principles
Each lesson: theory + engagement + homework introduction
Working experience:
2025 – Wolt / DoorDash — Staff QA Engineer
2023 – TPT — Visiting Lecturer (still here!)
2021–25 CyberCube — QA Engineer → Sr QA Engineer → Engineering Manager
2019 Testlio — Test Automation Specialist
2017–19 TalTech — Visiting Lecturer
2015–19 Evitec — QA Engineer → System Analyst
Education:
2017–23 MSc Engineering — TalTech
2014–17 BSc Engineering — TalTech
Key references: ISTQB Foundation · Agile Methodology · Clean Code by Robert C. Martin
Type your answers in the Teams chat or speak up!
Questions:
Quality is quality. The standard is the same — whether it rolls on four wheels or runs on a server.
"Quality is conformance to requirements." — Philip Crosby
function divide(a, b) {
return a / b;
}
divide(10, 2); // → 5 ✓ correct
divide(10, 0); // → Infinity ✗ is this "quality"?
// Quality depends on the REQUIREMENT:
// "If b is 0, the function must throw Error('Division by zero')"
function divide(a, b) {
if (b === 0) throw new Error('Division by zero');
return a / b;
}
// Now it conforms → quality improved
// The code changed, the requirement didn't
Quality is not absolute — it's always measured against a specification
| Found in | Relative Cost |
|---|---|
| Requirements | 1× |
| Design | 5× |
| Development | 10× |
| Testing | 20× |
| Production | 100× |
Source: IBM Systems Sciences Institute / NIST studies
// ERROR: developer writes assignment instead of comparison (human typo)
function applyDiscount(total, isMember) {
if (isMember = true) { // ← ERROR: should be ===
return total * 0.9;
}
return total;
}
// DEFECT: isMember is always overwritten to true
// FAILURE: every customer gets a discount — financial loss
Not all defects become failures — some hide until specific conditions occur
You can perfectly test a perfectly wrong product. Both matter.
🔗 istqb.org — free glossary, syllabi, and sample exams for all certification levels
1Testing shows presence of defects — not their absence. Tests can find bugs; they can't prove zero bugs exist.
2Exhaustive testing is impossible — prioritise by risk. You cannot test every input combination.
3Early testing saves time & money — shift left. Find it in requirements, not in production.
4Defects cluster together — 80/20 rule. A few modules tend to contain most bugs.
5Pesticide paradox — vary your tests. Running the same tests repeatedly stops finding new bugs.
6Context-dependent — medical software ≠ game app. Test appropriately.
7Absence-of-errors fallacy — passing all tests ≠ good software. It might still not meet user needs.
The quality mindset you're building here is exactly how you use AI responsibly. Trust, but verify.
Share the most annoying or memorable bug you've ever seen or encountered — in any software, anywhere.
Let's discuss: What type of testing would have caught this? When in the dev cycle?
Reflection: Write 3–5 sentences on what does "quality" mean to you? Give an example from a software project you've worked on or used.
No submission required. We'll discuss it next time in the first 10 minutes.