Lesson 1 of 9

The Quality Mindset

Subject intro · Quality · Testing · Terminology · 7 Principles

→ next slide  |  ESC overview

Lesson Plan
Lesson 1: The Quality Mindset
Focus: Subject Intro, Quality vs. Testing

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

About Me
Tatjana Kirotar
Staff QA Engineer
MS Teams · Tatjana Kirotar
· tatjana.kirotar@techno.ee
· tatjana.kirotar@gmail.com
🇪🇪 Estonian  
🇬🇧 English  
🇷🇺 Russian

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

About This Course

Course Overview

Structure 4 × 45 min per lesson · Teams / TPT
New topic + Engagement + Homework
Goal You can test your own software:
· Requirements
· Documentation
· Test Automation
Grading Practical assignments
In-class exercises
Prerequisites Programming Basics (any language)
Curiosity + willingness to break things

Key references: ISTQB Foundation · Agile Methodology · Clean Code by Robert C. Martin

👋 Your Turn — Let's Meet

Type your answers in the Teams chat or speak up!

Questions:

  • What's your tech stack? (JS/Python/Java…)
  • Projects you've worked on?
  • Testing experience so far?
  • What do you want from this course?
Why I'm asking: I'll adapt examples to your stack.
Your goals shape what we spend more time on.

No wrong answers — "zero experience" is a valid and welcome answer!
Topic 2

Quality is Quality — Car or Code, Same Standard

🚗
A quality car…
  • Starts every time you turn the key
  • Does what the brochure says
  • Doesn't break down unexpectedly
  • Looks and feels consistent throughout
  • Is easy to service and maintain
  • Worth what you paid for it
🖥️
Quality software…
  • Works every time you run it
  • Does what the requirements say
  • Doesn't crash unexpectedly
  • Behaves consistently across features
  • Is easy to maintain and extend
  • Worth what it cost to build
Quality is quality. The standard is the same — whether it rolls on four wheels or runs on a server.
Topic 2

(Software) Quality

  • Understandable design — intuitive, logical structure
  • Suitable functionality — does what users actually need
  • Reliability — behaves correctly, consistently
  • Consistency — same behaviour across all features
  • Resilience — handles failures and edge cases gracefully
  • Supportability — maintainable, fixable, upgradeable
  • Good value — worth what it costs to build and run
Quality software is: Bug-free software, delivered on time and within budget. It meets stated and implied requirements, and is maintainable.
"Quality is conformance to requirements." — Philip Crosby

Quality is Relative — Same Code, Different Verdict

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

Topic 3

Why Test? Real-world Failures

CrowdStrike (2024)
Faulty update → ~8.5M Windows systems crashed. ~$10B in damage. Planes grounded. Hospitals offline.
Boeing 737 MAX (2018–19)
Reliance on a single sensor. Software overrode pilots. 346 people killed in two crashes.
Tesla Recall (2021)
Flash memory failure in touchscreens. 135,000 vehicles recalled.
T-Mobile (2022)
Security flaw → 37 million customer records exposed.
Gangnam Style (2014)
YouTube's 32-bit view counter overflowed at 2,147,483,647 views. Had to upgrade to 64-bit.
Uber (2015)
App continued sending ride notifications to a wife after husband logged out — revealing affair. Lawsuit: €45M.

Cost of Fixing Bugs — The Earlier the Better

Found inRelative Cost
Requirements
Design
Development10×
Testing20×
Production100×
Software bugs can cause:
  • Financial loss (time + money to fix)
  • Reputation damage
  • Legal liability
  • Physical harm or death
  • Environmental damage

Source: IBM Systems Sciences Institute / NIST studies

Where Do Bugs Come From?

Client misses requirements
Analyst misinterprets
Design flaw
Code error
Test misses it
Production failure
Bugs enter at every phase of development. Testing's job is to catch them before users do.
ISTQB Testing Goals:
  • Find defects made during development
  • Increase reliability and confidence
  • Prevent defects from reaching users
  • Meet business and user requirements
Topic 4

Error → Defect → Failure

Error
Human mistake
Defect / Bug
Flaw in code or design
Failure
System misbehaves at runtime
// 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

Verification vs Validation

Verification — "Are we building it right?" Checking the product against specifications

Static: reviews, inspections, walkthroughs
Dynamic: unit tests, integration tests

Did we follow the design?
Validation — "Are we building the right thing?" Checking the product against user needs

UAT, beta testing, demos with customers
Acceptance criteria review

Does it actually solve the problem?
You can perfectly test a perfectly wrong product. Both matter.

Key Testing Terminology

  • Test Case — input + conditions + expected result
  • Test Suite — collection of related test cases
  • Test Plan — scope, approach, schedule, resources
  • Regression Testing — re-test after any change
  • Smoke Test — quick stability check after a build
  • Sanity Test — quick check after a specific fix
  • Exploratory Testing — learn + test simultaneously
  • Coverage — how much of the system is tested
  • Entry Criteria — conditions to start testing
  • Exit Criteria — conditions that signal "done"
Topic 4

What is ISTQB?

International Software Testing Qualifications Board The global body that sets the standard for software testing knowledge, vocabulary, and certification. Founded in 2002, active in 130+ countries.
Why it matters: The terminology, principles, and techniques in this course follow the ISTQB standard — it is the common language of the industry. Most job postings mention it.
CTFL — Certified Tester Foundation Level The most widely held software testing certification in the world. Entry-level, vendor-neutral, recognised globally. A solid first certification to pursue after this course.
Key outputs:
  • Standardised testing vocabulary
  • 7 Principles of Testing
  • Test processes and techniques
  • Free syllabus and glossary online
🔗 istqb.org — free glossary, syllabi, and sample exams for all certification levels

7 Principles of Testing (ISTQB)

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.

Topic 5

AI Tools Are Here — Use Them With Brains

AI can help you:
  • Write code and documents faster
  • Generate first-draft test cases
  • Explain unfamiliar code
  • Suggest refactoring ideas
AI cannot know:
  • Your actual requirements
  • Your users' real expectations
  • System usability
  • Whether its output is correct
The quality mindset you're building here is exactly how you use AI responsibly. Trust, but verify.

🐛 Bug Wall — Teams Activity (10 min)

Share the most annoying or memorable bug you've ever seen or encountered — in any software, anywhere.

  • Type it in the chat or feel free to unmute yourself and share
  • Include: what was the bug, what went wrong, what was the impact?

Let's discuss: What type of testing would have caught this? When in the dev cycle?

Homework 1 — Before Lesson 2

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.