Chapter 1 · 8 exam questions
Fundamentals of testing
What testing is
Testing = activities to find defects and evaluate quality. It's much more than running programs — it includes planning, analysis, design and reviewing documents.
The software runs. Failures appear during execution.
Nothing runs — documents and code are reviewed or analyzed by tools.
Did we build the product right? (meets the specified requirements)
Did we build the right product? (meets the users' real needs)
Typical test objectives: find defects and cause failures · evaluate work products (requirements, stories, designs, code) · build confidence · reduce risk · check coverage · verify legal/contractual requirements · give stakeholders information for decisions (e.g. the release decision).
Error → Defect → Failure
Testing is not debugging
Testing vs quality assurance
| Testing (quality control) | Quality assurance (QA) |
|---|---|
| Product-oriented · corrective. Focuses on the work product: find defects, evaluate quality. Test results → used to fix defects. | Process-oriented · preventive. Good process, followed correctly → good product. Test results → feedback on how well the process works. Everyone's responsibility. |
The seven testing principles
Tests can prove defects exist — never that there are none.
You can't test everything. Focus with techniques, priorities and risk.
Early defects are cheap defects. See "shift left".
A few components hold most defects (Pareto). Aim your tests there.
Repeated tests stop finding new defects — refresh them. (Automated regression tests are the useful exception.)
No universal recipe: a bank is not a game app.
Fixing every found defect still doesn't make the product what users need. Verify and validate.
The test process — 7 activity groups
Monitoring & control is the 7th activity — it runs the whole time: compare progress against the plan, and steer with corrective actions. The activities are iterative, not a strict line.
Testware — what each activity produces
| Activity | Outputs (testware) |
|---|---|
| Planning | test plan, schedule, risk register, entry & exit criteria |
| Monitoring & control | test progress reports, control directives |
| Analysis | prioritized test conditions, defect reports on the test basis |
| Design | prioritized test cases, charters, coverage items, test data requirements, environment requirements |
| Implementation | procedures, scripts, suites, test data, execution schedule, stubs & drivers & simulators |
| Execution | test logs, defect reports |
| Completion | test completion report, lessons learned, change requests |
Traceability, roles & skills
Traceability connects test basis ↔ test conditions ↔ test cases ↔ results ↔ defects ↔ risks. It makes coverage measurable ("is every requirement covered?"), enables impact analysis, clearer reports, and audits.
| Test management role | Testing role |
|---|---|
| Owns process & team: planning, monitoring & control, completion. In Agile, the team itself may absorb these tasks. | Owns the engineering side: analysis, design, implementation, execution. |
Essential skills: testing knowledge · thoroughness & curiosity · communication (testers deliver "bad news" — do it constructively) · analytical & critical thinking · technical knowledge · domain knowledge. The whole team approach (from XP): anyone with the right skills does any task, quality is everyone's job — but safety-critical work may need more independence instead.
Independence of testing
- Static testing finds defects directly; dynamic testing causes failures. Options that swap these two words are wrong.
- Debugging fixes defects — it never "fixes failures", and it is not testing.
- Verification = specified requirements · validation = user needs. The classic swap.
- A regulator's fine is a consequence, not a failure. Keep the chain order exact.
- Test data requirements → design. The actual test data → implementation.
Chapter 2 · 6 exam questions
Testing throughout the SDLC
SDLC models change how you test
Waterfall, V-model. Documents can be reviewed early, but running code arrives late — so dynamic testing starts late.
Spiral, prototyping. Every loop delivers a working version → static + dynamic testing at all levels, every iteration.
Unified Process. The product grows piece by piece → fast feedback and lots of regression testing.
The SDLC choice affects the scope and timing of testing, documentation detail, techniques, automation, and the tester's role. Agile prefers lightweight documentation, heavy test automation and experience-based manual testing.
Good practices in every SDLC: every development activity has a matching test activity · every test level has its own objectives · test analysis & design for a level starts during the matching development phase · testers review drafts as soon as they exist.
Test-first — the only three approaches
Test-driven development. Developer writes a small test → writes code to pass it → refactors. Tests drive the code.
Acceptance test-driven development. The team writes tests from acceptance criteria before development.
Behavior-driven development. Behavior written as simple natural-language tests: Given / When / Then → then automated.
DevOps
Shift left
Retrospectives at the end of an iteration or project ask: what went well? what to improve? how? Results go into the test completion report. Benefits: better test effectiveness and testware, team learning, a better test basis, better dev–test cooperation.
The five test levels
| Level | Focus |
|---|---|
| Component (unit) | one component in isolation · needs harnesses / unit test frameworks · usually developers |
| Component integration | interfaces between components · depends on integration strategy: bottom-up, top-down, big-bang |
| System | end-to-end behavior of the whole system, functional + non-functional · often an independent test team |
| System integration | interfaces to other systems & external services · environment close to production |
| Acceptance | validation — ready for users & business? · forms: UAT, operational, contractual, regulatory, alpha, beta |
Levels differ by: test object, objectives, test basis, typical defects, and who is responsible.
The four test types
What the system does — completeness, correctness, appropriateness.
How well it behaves. ISO 25010: performance efficiency, compatibility, usability, reliability, security, maintainability, portability, safety.
From the specification — checks behavior against requirements.
From the internal structure — checks the structure is covered.
All four types apply at every test level. Many non-functional tests are just functional tests with an extra check ("…and it finishes within 2 seconds").
Confirmation vs regression testing
| Confirmation testing — is the fix fixed? | Regression testing — did we break anything else? |
|---|---|
| Re-run the tests that failed before the fix (or at minimum, repeat the failing steps). Comes first. | Checks for side effects in unchanged parts — same component, other components, even connected systems. Do an impact analysis to choose scope. Suites grow → automate them, early. |
Maintenance testing — 3 triggers
Scope depends on: the risk of the change, the size of the system, and the size of the change.
- Only TDD, ATDD, BDD exist. "System TDD" and "Function-driven development" are invented distractors.
- Given/When/Then belongs to BDD. ATDD starts from acceptance criteria.
- Integration is a test level, not a test type. "How fast?" is non-functional, even for a critical business function.
- Confirmation testing → the changed code; regression testing → the unchanged rest. Regression suites grow, never shrink.
- Retirement is a maintenance trigger (archiving + restore testing).
- Retrospectives improve the process; end users don't attend them.
Chapter 3 · 4 exam questions
Static testing
Test without running anything
Static testing examines work products without executing them — by people (reviews) or by tools (static analysis). Anything readable can be reviewed: requirements, code, test plans, backlog items, contracts, models. Static analysis needs a formal structure to check (code, models); it lives happily inside CI pipelines.
| Static testing | Dynamic testing |
|---|---|
| Finds defects directly — nothing runs, so nothing "fails". | Causes failures; the defect behind them is found by analysis. |
| Works on any readable work product, even non-executable ones. | Only on software that runs. |
| Measures things like maintainability. | Measures things like performance. |
Found best (or only) statically: requirement defects (contradictions, ambiguities, omissions) · design defects (poor modularization) · unreachable code, undeclared variables, duplicated code · deviations from standards · wrong interface specifications · some security vulnerabilities (buffer overflows) · coverage gaps in the test basis.
Why it pays off: defects are caught at the cheapest possible moment, stakeholders build shared understanding early, and communication improves. Reviews cost effort — total project cost goes down.
The review process — 5 activities
The more formal the review, the more of these tasks it uses. An anomaly is not automatically a defect — that's decided in step 4.
Who does what in a review
Decides what gets reviewed; provides staff and time.
Creates and fixes the work product.
Runs the meeting; mediates; keeps it a safe space.
Collects anomalies; records decisions.
Does the reviewing — team member, expert, or any stakeholder.
Overall responsibility: picks who, organizes when & where.
Four review types, from casual to strict
Review success factors: clear objectives and measurable exit criteria (never evaluating people) · the right review type · small chunks at a time · time to prepare · feedback to authors · management support · training · reviews as part of the culture.
- "Chairperson" is not a review role. Manager decides what; review leader decides who/when/where.
- Reviews find defects/anomalies — never "failures" (nothing runs).
- Informal reviews may still involve preparation — they just need no formal process or documented output.
- Evaluating participants must never be a review objective.
Chapter 4 · 11 exam questions — the biggest chapter, with guaranteed calculations
Test analysis & design
Three families of test techniques
From the specified behavior, ignoring internals. Tests survive implementation changes. EP · BVA · decision tables · state transitions.
From the internal structure — only possible once design/code exists. Statement & branch testing.
From the tester's skill. Finds what the others miss — complementary. Error guessing · exploratory · checklists.
Equivalence partitioning (EP) guaranteed exam calculation
Split the data into partitions the system treats the same way. If one value in a partition finds a defect, any other value there would find it too — so one test per partition is enough.
Each Choice coverage — when there are several inputs (e.g. floor type × payment type), each partition of each input must be hit at least once. One test can tick partitions of several inputs at the same time, and combinations are not required.
Boundary value analysis (BVA) guaranteed exam calculation
Developers make mistakes at the edges. BVA tests each ordered partition's boundary values — its minimum and maximum.
Why 3-value is stronger (the syllabus's own example): if if (x <= 10) is wrongly coded as if (x == 10), the 2-value tests x=10 and x=11 both pass — only x=9, the extra 3-value neighbor, catches the bug.
Decision table testing guaranteed exam calculation
For business rules where combinations of conditions decide the outcome. Conditions and actions are rows; each column = one rule = one test.
| Online shop rules | R1 | R2 | R3 | R4 |
|---|---|---|---|---|
| Conditions | ||||
| Customer is a member | T | T | F | F |
| Order is ≥ €100 | T | F | T | F |
| Actions | ||||
| Give 5% discount | X | X | ||
| Free shipping | X | X | ||
- Coverage = columns exercised ÷ feasible columns × 100%. A second test hitting the same column adds nothing.
- Tables can be minimized by merging columns where a condition doesn't change the outcome ("–").
- Decision tables expose gaps (a combination no rule covers) and contradictions (two rules match the same combination with different actions).
State transition testing guaranteed exam calculation
Some systems answer the same event differently depending on their state. Transition label syntax: event [guard condition] / action.
| State ↓ · Event → | pay | ship | deliver | cancel |
|---|---|---|---|---|
| CREATED | → PAID | → CLOSED | ||
| PAID | → SHIPPED | |||
| SHIPPED | → CLOSED | |||
| CLOSED |
Visit every state. The weakest criterion — possible without using every transition.
Exercise every valid transition. The most widely used. Implies all-states coverage.
Valid ones + attempts at invalid ones. Minimum for mission- & safety-critical software. Only one invalid transition per test — or one defect can hide another (defect masking).
White-box: statement & branch coverage
= statements exercised ÷ all executable statements. Even 100% can miss data-dependent defects (e.g. division by zero).
= branches exercised ÷ all branches. Branches are the edges of the control flow graph — conditional and unconditional.
White-box looks at the real code, gives an objective coverage number — but can't find defects of omission (requirements never implemented).
Experience-based techniques
Anticipate likely errors, defects, failures from experience: how the app behaved before, mistakes these developers make, failures in similar apps. Methodical version: fault attacks — test from a written list of possible defects/failures.
Design, run and learn at the same time. Structured as session-based testing: time-box + test charter + debriefing. Shines when specs are weak or time is short; depends on the tester's skill.
Test conditions come from a checklist (often questions). No automatable items, no entry/exit criteria, nothing vague. Update it regularly — old items wear out. More coverage, less repeatability.
Collaboration-based approaches
The techniques above find defects. Collaboration avoids them — through communication.
The medium holding the user story (index card, board entry).
The talk that builds shared understanding of how the software will be used.
The acceptance criteria — how we know it's done.
Story format: "As a [role], I want [goal], so that I can [business value]". Good stories are INVEST:
Acceptance criteria = the story's test conditions. Two formats to classify on the exam:
| Scenario-oriented | Rule-oriented |
|---|---|
| The Given / When / Then format (BDD): Given I'm logged in, When I pay by card, Then I see a receipt. | A bullet-point verification list, or a table mapping inputs to outputs. |
ATDD, step by step: 1) a specification workshop analyzes the user story + acceptance criteria and fixes their defects; 2) the team writes test cases before coding — positive cases first, then negative, then non-functional. Automated, the tests become executable requirements. Tests must cover the whole story and never go beyond it; no two tests should check the same thing.
- EP coverage counts invalid partitions too; Each Choice needs no combinations.
- BVA: count carefully — a boundary's neighbor is usually the next partition's own boundary. Open-ended ranges still have boundaries.
- Decision tables: a duplicate test on a covered column adds nothing. Gap = no rule matches; contradiction = two rules match with different actions.
- State transitions: repeating an event may reuse the same transition (no new coverage); any sequence continuing after the end state is infeasible.
- 100% statement coverage does NOT give 100% branch coverage. Branch subsumes statement — know the direction.
- Exploratory testing is experience-based, not black-box. A written failure list = fault attack, not checklist-based testing.
- ATDD: a plausible test that goes beyond the acceptance criteria is the classic wrong answer.
Chapter 5 · 9 exam questions — with calculations
Managing the test activities
The test plan
A test plan = objectives, resources and processes of the test project. It documents the schedule, communicates with stakeholders, and shows how testing follows (or deviates from) the test policy and strategy. Content: context (scope, objectives, test basis) · assumptions & constraints · stakeholders · communication · risk register · test approach (levels, types, techniques, entry/exit criteria, metrics, data & environment needs) · budget & schedule.
Testers help plan too — in release planning: testable user stories & acceptance criteria, risk analysis, effort estimation, the test approach. In iteration planning: detailed risk analysis, testability checks, breaking stories into testing tasks, estimating them.
Entry criteria vs exit criteria
| Entry — may we start? | Exit — are we done? |
|---|---|
| Things available before starting: resources (people, tools, environments, data, budget, time), testware (test basis, test cases), initial quality (smoke tests passed). Agile name: Definition of Ready. | Thoroughness achieved: coverage reached, unresolved defects, defect density, failed tests — plus yes/no checks (all planned tests executed, regression automated). Agile name: Definition of Done. Running out of time/budget can be a valid exit if stakeholders accept the risk. |
Estimation — four techniques guaranteed exam calculation
Historical ratios from your own organization. Dev:test was 3:2 → dev of 600 person-days means 400 for test.
Measure early, project forward — e.g. next iteration ≈ average of the last three.
Experts estimate in isolation → discuss outliers → re-estimate → repeat until consensus. Planning Poker = the Agile card variant.
Optimistic a · most likely m · pessimistic b → weighted mean, with a known error range.
Syllabus example: a=6, m=9, b=18 → E = (6+36+18)÷6 = 10, SD = 12÷6 = 2 → the estimate is 10 ± 2 person-hours.
Test case prioritization apply-level
Tests for the biggest risks first.
Highest coverage first (variant: highest additional coverage next).
Tests of the most important requirements first.
The exam twist: dependencies beat priority. If high-priority TC3 needs TC1's result, TC1 runs first regardless of priority. Resource availability constrains the order too.
The test pyramid
The testing quadrants
- functional tests, examples
- user story tests, UX prototypes
- API testing · manual or automated
- exploratory testing
- usability testing
- user acceptance testing · often manual
- component tests
- component integration tests
- automated, in CI
- smoke tests
- non-functional tests (except usability)
- often automated
Top row = business facing, bottom row = technology facing. The quadrants (Marick) help every stakeholder see that no test type or level is forgotten.
Risk management
Risk = a potential event with an adverse effect. Risk level = likelihood × impact — two independent factors. Risk-based testing selects and prioritizes test work by risk.
likelihood
likelihood
likelihood
| Project risks — can we deliver? | Product risks — is it good? |
|---|---|
| Organizational (delays, bad estimates, cost cutting) · people (skills, conflicts, shortage) · technical (scope creep, poor tool support) · suppliers. They hit schedule, budget or scope. | Missing/wrong functionality, wrong calculations, runtime errors, poor architecture, slow response, bad UX, security holes. They cause user dissatisfaction, lost revenue & trust, penalties — in extreme cases injury or death. |
Risk analysis = identification (brainstorming, interviews…) + assessment (categorize, rate likelihood & impact, prioritize). It decides the scope and thoroughness of testing: which levels, types, techniques, coverage, and what runs first.
Risk control = mitigation (do the planned actions) + monitoring (do they work? new risks?). Possible responses: mitigate by testing · accept · transfer (e.g. insurance) · contingency plan. Testing mitigates risk via: the right testers, right independence level, reviews & static analysis, right techniques/coverage/types, regression testing.
Monitoring, control & reports
Monitoring gathers data on progress and exit criteria · control acts on it (reprioritize, adjust schedule, add resources) · completion consolidates at milestones. Metric families: project progress · test progress (run/pass/fail) · product quality (e.g. mean time to failure) · defects (density, detection %) · risk (residual level) · coverage · cost.
| Test progress report — during | Test completion report — at the end |
|---|---|
| Regular (daily/weekly): progress vs plan, impediments, metrics, new risks, next period. Supports ongoing control. | At a milestone (level / iteration / release done, exit criteria ideally met): summary, evaluation vs plan, deviations, unresolved defects & risks, lessons learned. Built from progress reports. |
Tailor the message to the audience — business people don't need branch coverage. Channels: conversation, dashboards & burn-down charts, chat/email, formal reports.
Configuration management
CM keeps testing reproducible: every item (test plans, cases, scripts, results, environments) is uniquely identified, version controlled, change-tracked and traceable. Approved versions become baselines, changed only via change control — and you can revert to a baseline to reproduce old results. In DevOps, CM is built into the pipeline.
Defect management guaranteed exam task: critique a report
- Date · author · role
- 2026-07-08 · D. Dogan · tester
- Test object + environment
- WebShop v2.3.1 · Chrome 126 / Windows 11 ← the field everyone forgets!
- Context
- TC-17 · system testing · sorting the order list
- Steps + data to reproduce
- Open orders → add 3 orders dated 2026-07-01 → click "sort by date" ← input data lets the developer reproduce it
- Expected vs actual
- Expected: stable sorted list · Actual: duplicate rows disappear
- Severity · priority
- Severity: high (impact on stakeholders) · Priority: fix in next release
- References
- TC-17 · requirement R-88
Statuses: open · deferred · duplicate · waiting to be fixed · awaiting confirmation testing · re-opened · closed · rejected. A good report enables reproduction, tracks work-product quality, and feeds process improvement.
- Entry = available before starting · exit = achieved at the end. The classic flip.
- Pyramid = granularity & automation · quadrants = stakeholder view of test types. Distractors swap their properties.
- Scope creep and poor tool support are PROJECT risks — they only sound product-ish.
- Likelihood and impact are independent; be ready to compute either one (risk ÷ likelihood = impact).
- Severity (impact) ≠ priority (urgency to fix).
- Versions + baselines + rollback = configuration management; defect IDs and workflow = defect management.
- Acceptance criteria live on the user story — not in the test plan. Concrete test data doesn't belong in a test plan either.
Chapter 6 · 2 exam questions
Test tools
Tool types
Manage the SDLC, requirements, tests, defects, configuration.
Support reviews and static analysis.
Generate test cases, test data, procedures.
Run tests automatically, measure coverage.
Do what's hard by hand — e.g. performance load.
Delivery pipeline, build automation, CI/CD.
Support communication.
Virtual machines, containers. Even a spreadsheet can be a test tool.
Test automation — benefits vs risks
| Benefits ✓ | Risks ✗ |
|---|---|
|
|
- Tools support testers — they don't share responsibility, replace critical thinking, or invent test cases with expected results from nothing.
- Distractors reword benefits as risks and vice versa — "less repetitive manual work" is a benefit.
- Matching questions: VM/containers = scalability & deployment · CI/CD = DevOps tools.