QA Basics Interview Guide

Що це. Тестування — це набір дій, які дають команді інформацію про якість продукту: ми порівнюємо фактичну поведінку системи з очікуваною, шукаємо відмови й оцінюємо ризики, що лишились. ISTQB CTFL 4.0 включає сюди не лише запуск програми (динамічне тестування), а й аналіз вимог, рев'ю коду та документів (статичне тестування).

What it is. Testing is a set of activities that gives the team information about product quality: we compare the actual behaviour of the system with the expected one, look for failures and assess the risks that remain. ISTQB CTFL 4.0 counts not only running the software (dynamic testing) but also analysing requirements and reviewing code and documents (static testing).

Навіщо. Цілі тестування — знайти дефекти до користувача, переконатися, що вимоги виконані, дати бізнесу підставу для рішення «випускаємо чи ні» і зменшити ризик. Важливо, що результат тестування — це знання, а не «зелений прапорець».

Why it matters. The goals are to find defects before users do, confirm that requirements are met, give the business grounds for a go/no-go decision and reduce risk. The key point is that the output of testing is knowledge, not a green tick.

Приклад. Для відновлення пароля тестувальник перевіряє не лише щасливий шлях, а й прострочене посилання, повторне використання токена, чужий email. Кожна перевірка додає факт: «посилання після 24 годин не працює — як і вимагає специфікація».

Example. For password reset a tester checks not only the happy path but also an expired link, a reused token and someone else's email. Each check adds a fact: "after 24 hours the link stops working, as the specification requires".

Підводні камені. Тестування не доводить відсутність помилок, не є лише пошуком багів і не дорівнює налагодженню: debugging робить розробник, коли вже знає про відмову. Ще одна хибна думка — що тестування починається після написання коду.

Pitfalls. Testing does not prove the absence of bugs, it is not only bug hunting, and it is not debugging: debugging is what a developer does once a failure is known. Another misconception is that testing only starts after the code is written.

Що це. Класичне формулювання Баррі Боема: верифікація — «Are we building the product right?» (чи правильно ми будуємо продукт, тобто чи відповідає він специфікації), валідація — «Are we building the right product?» (чи той продукт ми будуємо, тобто чи розв'язує він реальну потребу користувача).

What it is. Barry Boehm's classic wording: verification asks "Are we building the product right?" — does it conform to the specification; validation asks "Are we building the right product?" — does it solve the user's real need.

Навіщо. Продукт може ідеально відповідати специфікації й усе одно бути марним, якщо сама специфікація хибна. Верифікація ловить відхилення від документа (рев'ю, тест-кейси за вимогами, статичний аналіз), валідація — відхилення від потреби (UAT, демо стейкхолдерам, бета, юзабіліті-тести).

Why it matters. A product can match its specification perfectly and still be useless if the specification itself is wrong. Verification catches deviations from the document (reviews, requirement-based test cases, static analysis); validation catches deviations from the need (UAT, stakeholder demos, beta, usability tests).

Приклад. У специфікації сказано: «звіт експортується у PDF». Команда зробила PDF, усі тести зелені — верифікація пройдена. На демо бухгалтер питає, як тепер вставити цифри в Excel, бо щомісяця він робить саме це. Валідація провалена: правильно зроблено не те.

Example. The specification says "the report is exported to PDF". The team built PDF export and every test is green — verification passed. At the demo the accountant asks how to paste the numbers into Excel now, because that is exactly what he does every month. Validation failed: the wrong thing was built correctly.

Підводні камені. Часто кажуть, що верифікація — «статична», а валідація — «динамічна». Це спрощення: тест-кейс за вимогою, виконаний на збірці, — теж верифікація. Відрізняє їх не техніка, а еталон, з яким порівнюємо: документ чи потреба.

Pitfalls. People often say verification is "static" and validation is "dynamic". That is a simplification: a requirement-based test case run on a build is verification too. What separates them is not the technique but the reference we compare against: a document or a need.

Що це. За глосарієм ISTQB це ланцюжок. Помилка (error, mistake) — дія людини, що дає хибний результат: неуважно прочитана вимога, описка в умові. Дефект (defect, bug, fault) — вада в артефакті: у коді, вимозі, тест-кейсі. Відмова (failure) — момент, коли система під час роботи поводиться не так, як мала б.

What it is. In the ISTQB glossary this is a chain. An error (mistake) is a human action that produces a wrong result: a misread requirement, a typo in a condition. A defect (bug, fault) is an imperfection in a work product: code, a requirement, a test case. A failure is the moment the system behaves differently from what it should while running.

Навіщо. Розрізнення підказує, де шукати і що фіксувати. Тестувальник бачить відмову й описує її; розробник знаходить дефект; ретроспектива або RCA з'ясовує, яка помилка людини і чому до нього призвела.

Why it matters. The distinction tells you where to look and what to record. A tester observes the failure and describes it; a developer locates the defect; a retrospective or RCA finds out which human error led to it and why.

Приклад. Вимога: знижка 10% «для замовлень від 1000 грн», тобто включно з 1000. Розробник пише > замість >= — це помилка, а сам рядок коду — дефект. Клієнт з кошиком рівно на 1000 грн не отримує знижку — це відмова.

Example. The requirement: a 10% discount "for orders from 1000 UAH", i.e. including 1000. The developer writes > instead of >= — that is the error, and the line of code is the defect. A customer with a cart of exactly 1000 UAH gets no discount — that is the failure.

Підводні камені. Не кожен дефект стає відмовою: якщо ніхто не купує рівно на 1000 грн, вада мовчить роками. І не кожна відмова походить від дефекту в коді: причиною може бути середовище — повний диск, неправильний часовий пояс сервера, радіація в пам'яті. Тому в баг-репорті описують відмову, а не гадають про дефект.

Pitfalls. Not every defect becomes a failure: if nobody buys for exactly 1000 UAH, the flaw stays silent for years. And not every failure comes from a code defect: the cause can be the environment — a full disk, a wrong server time zone, radiation flipping a memory bit. That is why a bug report describes the failure instead of guessing the defect.

Що це. У CTFL 4.0 принципи звучать так: 1) тестування показує наявність дефектів, а не їх відсутність; 2) вичерпне тестування неможливе; 3) раннє тестування заощаджує час і гроші; 4) дефекти скупчуються; 5) тести зношуються (раніше — «парадокс пестициду»); 6) тестування залежить від контексту; 7) хибне уявлення про відсутність дефектів.

What it is. In CTFL 4.0 the principles read: 1) testing shows the presence, not the absence of defects; 2) exhaustive testing is impossible; 3) early testing saves time and money; 4) defects cluster together; 5) tests wear out (formerly the "pesticide paradox"); 6) testing is context dependent; 7) the absence-of-defects fallacy.

Навіщо. Принципи — не цитати для співбесіди, а аргументи в щоденних рішеннях: чому ми не обіцяємо «нуль багів», чому потрібні техніки тест-дизайну, чому QA кличуть на рев'ю вимог і чому регресійний набір треба оновлювати.

Why it matters. The principles are not interview quotes but arguments in everyday decisions: why we never promise "zero bugs", why test design techniques are needed, why QA is invited to requirement reviews and why a regression suite has to be refreshed.

Приклад. Форма з п'ятьма полями по 100 можливих значень дає 10¹⁰ комбінацій — ось принцип 2 у цифрах; тому ми беремо класи еквівалентності й межі. Банківський застосунок і мобільна гра потребують зовсім різної глибини — принцип 6.

Example. A form with five fields of 100 possible values each gives 10¹⁰ combinations — that is principle 2 in numbers, which is why we pick equivalence classes and boundaries. A banking app and a mobile game need completely different depth — principle 6.

Підводні камені. Сьомий принцип часто плутають з першим. Перший про межі знання («не знайшли ≠ немає»), сьомий — про цінність: система без жодного відомого дефекту може бути непридатною, якщо вона не розв'язує задачу користувача або повільна.

Pitfalls. The seventh principle is often confused with the first. The first is about the limits of knowledge ("not found ≠ not there"), the seventh about value: a system with no known defect can still be unusable if it does not solve the user's problem or is too slow.

Що це. Термін Бориса Бейзера: як комахи звикають до одного пестициду, так і код «звикає» до одного набору тестів. Якщо запускати ті самі кейси з тими самими даними, вони знаходять дедалі менше нових дефектів — не тому, що їх немає, а тому, що тести перевіряють уже виправлені місця. У CTFL 4.0 принцип перейменовано на «тести зношуються».

What it is. Boris Beizer's term: just as insects get used to one pesticide, code "gets used to" one set of tests. Running the same cases with the same data finds fewer and fewer new defects — not because there are none, but because the tests keep checking places that were already fixed. CTFL 4.0 renamed the principle "tests wear out".

Навіщо. Зелений регрес створює ілюзію якості. Тим часом продукт змінюється: нові інтеграції, нові ролі, нові дані. Щоб набір лишався корисним, його переглядають разом зі змінами продукту й аналізом знайдених у проді дефектів.

Why it matters. A green regression run creates an illusion of quality. Meanwhile the product keeps changing: new integrations, new roles, new data. To stay useful the suite is reviewed alongside product changes and the analysis of defects found in production.

Приклад. Пів року регрес кошика стабільно зелений, а в проді клієнти скаржаться на промокоди з кирилицею та на кошики з 50+ товарами. Команда додає нові дані (кирилиця, емодзі, великі кошики), рандомізує порядок товарів, переписує два застарілі кейси й запускає сесію дослідницького тестування — і за тиждень знаходить три нові баги.

Example. For six months the cart regression run has been green, while customers in production complain about promo codes with Cyrillic letters and carts with 50+ items. The team adds new data (Cyrillic, emoji, large carts), shuffles item order, rewrites two outdated cases and runs an exploratory session — and finds three new bugs within a week.

Підводні камені. Регресійні тести, які нічого не знаходять, не марні: вони підтверджують, що старе не зламалося. Проблема не в них, а в тому, що команда вважає їх єдиним джерелом інформації. Інша пастка — безкінечно дописувати кейси, нічого не видаляючи: набір росте, а цінність — ні.

Pitfalls. Regression tests that find nothing are not useless: they confirm the old behaviour still works. The problem is treating them as the only source of information. Another trap is endlessly adding cases and never removing any: the suite grows while its value does not.

Що це. Спостереження, що більшість дефектів зосереджена в невеликій кількості модулів. Його часто описують правилом Парето «80/20», але це евристика, а не закон: пропорція на кожному проєкті своя. Скупчення виникає там, де складна логіка, часті зміни, слабке покриття, нова технологія або код без власника.

What it is. The observation that most defects concentrate in a small number of modules. It is often described with the Pareto "80/20" rule, but that is a heuristic, not a law: every project has its own ratio. Clusters appear where logic is complex, changes are frequent, coverage is weak, technology is new or the code has no owner.

Навіщо. Принцип допомагає розподілити обмежений час: більше тестів, рев'ю й дослідницьких сесій туди, де історично болить, і в ризиковий аналіз — як фактор імовірності. Це також сигнал для команди: модуль, що постійно «кровоточить», може потребувати рефакторингу, а не ще одного тест-кейсу.

Why it matters. The principle helps spend limited time: more tests, reviews and exploratory sessions where it has historically hurt, and it feeds risk analysis as a likelihood factor. It is also a signal to the team: a module that keeps bleeding may need refactoring rather than one more test case.

Приклад. За квартал у трекері 120 дефектів. Групуємо за компонентом і бачимо, що оплата й тарифи дають 70 з них. На наступний реліз QA планує для цих двох модулів парне тестування з розробником і додаткову серію граничних тестів, а для профілю користувача лишає короткий чек-лист.

Example. The tracker holds 120 defects for the quarter. Grouping by component shows that payments and tariffs account for 70 of them. For the next release QA plans pair testing with a developer and an extra set of boundary tests for these two modules, while the user profile gets a short checklist.

Підводні камені. Кластер у трекері може бути артефактом: там, де більше тестують, там більше й знаходять. А модуль з нулем багів може бути просто неперевіреним. Тому дивляться на щільність (дефекти на обсяг змін) і на дефекти з продакшну, а не лише на сирий лічильник. Ще одна пастка — зовсім покинути «спокійні» модулі: так порушується принцип зношування тестів.

Pitfalls. A cluster in the tracker can be an artefact: where you test more, you find more. And a module with zero bugs may simply be untested. So look at density (defects per volume of change) and at production defects, not just the raw count. Another trap is abandoning the "quiet" modules entirely, which runs straight into the tests-wear-out principle.

Що це. Quality Assurance (забезпечення якості) спрямоване на процес: воно запобігає появі дефектів через стандарти, рев'ю, навчання, Definition of Done, ретроспективи. Quality Control (контроль якості) спрямований на продукт: він виявляє дефекти в конкретному артефакті. Тестування — головна, але не єдина діяльність QC; до контролю належать також рев'ю коду чи інспекції документів.

What it is. Quality Assurance is process-oriented: it prevents defects through standards, reviews, training, a Definition of Done and retrospectives. Quality Control is product-oriented: it detects defects in a specific work product. Testing is the main but not the only QC activity; code reviews and document inspections belong to control as well.

Навіщо. Розуміння різниці пояснює, чому посада «QA engineer» ширша за «людину, що тестує». Сильний QA не лише знаходить баги в збірці, а й питає, чому однаковий тип бага повертається щоспринту, і змінює процес: додає чек у пул-реквест, уточнює шаблон user story.

Why it matters. Knowing the difference explains why a "QA engineer" title is broader than "the person who tests". A strong QA does not only find bugs in a build but asks why the same kind of bug comes back every sprint, and changes the process: adds a check to the pull request template, sharpens the user story template.

Приклад. Тричі за місяць у прод потрапляють непереведені тексти. QC-реакція — тестувальник знаходить і заводить кожен рядок. QA-реакція — команда додає до DoD пункт «усі ключі мають переклад» і лінтер, що ламає збірку на відсутньому ключі. Відтоді таких багів немає, і тестувати їх вручну вже не треба.

Example. Three times in a month untranslated strings reach production. The QC response: a tester finds and files each string. The QA response: the team adds "every key has a translation" to the DoD and a linter that fails the build on a missing key. From then on those bugs stop appearing and nobody has to test for them by hand.

Підводні камені. Помилково думати, що QA — окремий відділ, який «відповідає за якість». Якість — відповідальність усієї команди, а QA-інженер допомагає її будувати. І не варто протиставляти QA і QC: без контролю немає даних, щоб покращувати процес.

Pitfalls. It is a mistake to think of QA as a separate department that "owns quality". Quality is the whole team's responsibility, and a QA engineer helps build it. Nor should QA and QC be set against each other: without control there is no data to improve the process with.

Що це. SDLC (Software Development Life Cycle) — життєвий цикл розробки: вимоги, дизайн, реалізація, тестування, розгортання, супровід. STLC (Software Testing Life Cycle) — цикл саме тестування. У CTFL 4.0 це тестовий процес: планування; моніторинг і контроль; аналіз; проєктування; реалізація; виконання; завершення тестування.

What it is. The SDLC (Software Development Life Cycle) is the development lifecycle: requirements, design, implementation, testing, deployment, maintenance. The STLC (Software Testing Life Cycle) is the lifecycle of testing itself. CTFL 4.0 calls it the test process: planning; monitoring and control; analysis; design; implementation; execution; completion.

Навіщо. STLC не чекає на етап «тестування» в SDLC — він іде паралельно. Поки аналітик пише вимоги, QA вже робить тест-аналіз (що перевіряти); поки розробник пише код, QA проєктує кейси й готує дані. Це і є shift-left: робота з якістю починається там, де з'являється перший артефакт.

Why it matters. The STLC does not wait for the SDLC's "testing" stage — it runs alongside. While the analyst writes requirements, QA already does test analysis (what to test); while the developer writes code, QA designs cases and prepares data. That is shift-left: quality work starts where the first artefact appears.

Приклад. Спринт з фічею «оплата частинами»: на рефайнменті QA ставить питання про ліміти (аналіз), у перші дні пише таблицю рішень і чек-лист (проєктування), готує тестові картки банку (реалізація), тестує збірку на стейджі (виконання), а в кінці фіксує звіт і відкриті ризики (завершення).

Example. A sprint with a "pay in instalments" feature: at refinement QA asks about limits (analysis), in the first days writes a decision table and a checklist (design), prepares bank test cards (implementation), tests the build on staging (execution) and at the end records a summary and open risks (completion).

Підводні камені. Фази STLC — логічні, а не обов'язково послідовні чи окремі в часі: в Agile вони повторюються в кожному спринті й часто накладаються. Помилка — описувати STLC як водоспад із документом-підписом після кожної фази, коли команда працює двотижневими ітераціями.

Pitfalls. STLC phases are logical, not necessarily sequential or separated in time: in Agile they repeat every sprint and often overlap. It is a mistake to describe the STLC as a waterfall with a signed document after every phase when the team works in two-week iterations.

Що це. Статичне тестування перевіряє артефакти без запуску програми: вимоги, user stories, макети, код, тест-кейси. Інструменти — рев'ю людьми і статичний аналіз (лінтери, аналізатори коду). Динамічне тестування, навпаки, виконує ПЗ і дивиться на відмови. Статичне знаходить сам дефект, динамічне — його прояв.

What it is. Static testing examines work products without running the software: requirements, user stories, mock-ups, code, test cases. The tools are human reviews and static analysis (linters, code analysers). Dynamic testing, by contrast, executes the software and observes failures. Static testing finds the defect itself; dynamic testing finds its symptom.

Навіщо. Частину дефектів динамічно знайти важко або неможливо: суперечливі вимоги, недосяжний код, відсутній сценарій. Рев'ю вимог до початку розробки — найдешевший спосіб прибрати таку ваду. CTFL 4.0 виділяє чотири типи рев'ю за формальністю: неформальне, walkthrough (прохід з автором-ведучим), технічне рев'ю (рішення приймають експерти) та інспекція (найформальніша, з ролями, чек-листами й метриками).

Why it matters. Some defects are hard or impossible to find dynamically: contradictory requirements, unreachable code, a missing scenario. Reviewing requirements before development starts is the cheapest way to remove such a flaw. CTFL 4.0 names four review types by formality: informal review, walkthrough (led by the author), technical review (experts reach a decision) and inspection (the most formal, with roles, checklists and metrics).

Приклад. Історія «Доставка безкоштовна для замовлень понад 1000 грн. Доставка коштує 50 грн». Під час рев'ю QA помічає: невідомо, що буде рівно з 1000 грн, як рахується сума після знижки, і чи стосується правило самовивозу. Три дефекти знайдені без рядка коду.

Example. The story reads "Delivery is free for orders over 1000 UAH. Delivery costs 50 UAH". During the review QA notices: it is unclear what happens at exactly 1000 UAH, whether the total is counted after discounts, and whether the rule covers pickup. Three defects found without a single line of code.

Підводні камені. Рев'ю не повинно перетворюватися на оцінку автора — критикують артефакт, а не людину. Без підготовки учасників рев'ю стає формальністю. І лінтер не замінює людське читання вимог: він ловить синтаксис, а не хибну бізнес-логіку.

Pitfalls. A review must not turn into judging the author — the work product is criticised, not the person. Without participants preparing beforehand a review becomes a formality. And a linter does not replace a human reading the requirements: it catches syntax, not wrong business logic.

Що це. Розробник думає, як змусити систему працювати; тестувальник — як і за яких умов вона може не спрацювати. CTFL 4.0 описує мислення тестувальника як допитливість, професійний песимізм, критичний погляд, увагу до деталей і прагнення до добрих, позитивних стосунків з колегами. Це конструктивний скептицизм, а не протистояння з командою.

What it is. A developer thinks about how to make the system work; a tester thinks about how and under what conditions it might not. CTFL 4.0 describes the tester's mindset as curiosity, professional pessimism, a critical eye, attention to detail and a drive for good, positive communication with colleagues. It is constructive scepticism, not a fight with the team.

Навіщо. Автору важко побачити власні сліпі зони: він знає, як задумано, і мимоволі тестує задумане. Незалежний погляд помічає неявні припущення: що станеться при повторному кліку, без мережі, з іншою роллю, з даними, про які ніхто не подумав.

Why it matters. Authors struggle to see their own blind spots: they know how things were intended and unconsciously test the intention. An independent view spots hidden assumptions: what happens on a double click, offline, under another role, with data nobody thought about.

Приклад. Розробник показує чекбокс «Запам'ятати мене» і перевіряє, що після перезапуску браузера сесія жива. Тестувальник одразу питає: скільки днів вона живе, що буде після зміни пароля на іншому пристрої, чи працює це в режимі інкогніто, чи знімає «Вийти» запам'ятовування на всіх пристроях.

Example. A developer demos a "Remember me" checkbox and checks that the session survives a browser restart. The tester immediately asks: how many days does it last, what happens after a password change on another device, does it work in incognito mode, does "Log out" forget the session on every device.

Підводні камені. Песимізм без емпатії робить тестувальника «тим, хто все блокує». Формулюйте знахідки як факти й ризики для користувача, а не як «ти знову зламав». Інша крайність — надмірна довіра до розробника («він сказав, що працює»), яка вбиває незалежність. Мислення тестувальника корисне й розробникам, тому його варто поширювати, а не охороняти.

Pitfalls. Pessimism without empathy turns a tester into "the one who blocks everything". Phrase findings as facts and risks for the user, not as "you broke it again". The opposite extreme is over-trusting the developer ("he said it works"), which kills independence. The tester mindset helps developers too, so spread it rather than guard it.

Що це. Оракул — джерело, за яким ми визначаємо очікуваний результат і вирішуємо, пройшов тест чи ні. Це може бути специфікація, попередня версія системи, конкурентний продукт, незалежний розрахунок, правила узгодженості (сума рядків дорівнює підсумку), думка експерта. Проблема оракула — ситуація, коли надійного джерела немає або воно дороге.

What it is. An oracle is the source we use to determine the expected result and decide whether a test passed. It can be a specification, a previous version of the system, a competing product, an independent calculation, consistency rules (line items add up to the total) or an expert's judgement. The oracle problem is the situation where no reliable source exists or it is expensive.

Навіщо. Без оракула тест не має вердикту — є лише спостереження. Особливо гостро це відчувається з розрахунками, ML-моделями, великими звітами та легасі без документації. Senior-тестувальник свідомо обирає кілька оракулів і розуміє сильні й слабкі сторони кожного: попередня версія, наприклад, повторить і свої старі баги.

Why it matters. Without an oracle a test has no verdict, only an observation. It bites hardest with calculations, ML models, large reports and undocumented legacy. A senior tester deliberately picks several oracles and knows each one's strengths and weaknesses: a previous version, for example, will repeat its own old bugs.

Приклад. Фіча конвертації валют у гаманці. Специфікація каже лише «за курсом НБУ». QA бере курс з офіційного API як незалежний оракул, перевіряє зворотну конвертацію (UAH→USD→UAH ≈ вихідна сума з точністю до правила округлення), порівнює з банківським застосунком і уточнює в бухгалтера, як округлювати копійки.

Example. A currency conversion feature in a wallet. The specification only says "at the NBU rate". QA takes the rate from the official API as an independent oracle, checks the round trip (UAH→USD→UAH ≈ the original amount within the rounding rule), compares with a banking app and asks accounting how kopecks should be rounded.

Підводні камені. Найчастіша помилка — використовувати як оракул саму систему: «записав, що показало, і зробив очікуваним». Так тест фіксує баг як норму. Інша пастка — евристичні оракули (узгодженість, правдоподібність) дають лише ймовірний вердикт, тому їх результат варто підтверджувати з людиною, що знає домен.

Pitfalls. The most common mistake is using the system itself as the oracle: "wrote down what it showed and made it the expected result". That way the test enshrines a bug as normal. Another trap is that heuristic oracles (consistency, plausibility) only give a probable verdict, so their result is worth confirming with someone who knows the domain.

Що це. Рівень тестування — це група активностей, організованих навколо одного об'єкта тестування на певному етапі розробки. CTFL 4.0 називає п'ять рівнів: компонентне тестування (component, воно ж unit), тестування інтеграції компонентів, системне тестування, тестування інтеграції систем і приймальне тестування. Класична схема «Unit → Integration → System → Acceptance» — спрощення, де обидва інтеграційні рівні злито в один.

What it is. A test level is a group of activities organised around one test object at a particular stage of development. CTFL 4.0 lists five levels: component testing (also called unit testing), component integration testing, system testing, system integration testing and acceptance testing. The classic "Unit → Integration → System → Acceptance" chain is a simplification that folds both integration levels into one.

Навіщо. Кожен рівень має власну тестову базу, свої типові дефекти, власне середовище й відповідальних. Помилку в округленні ціни дешево зловити на компонентному рівні, а неправильно замаплене поле між магазином і службою доставки видно лише на рівні інтеграції систем. Якщо команда пропускає рівень, його дефекти не зникають, а просто спливають пізніше й дорожче.

Why it matters. Each level has its own test basis, its own typical defects, its own environment and its own owners. A price-rounding mistake is cheap to catch at component level, while a wrongly mapped field between the shop and the delivery service only shows up during system integration testing. When a team skips a level, its defects do not vanish; they surface later, where they cost more.

Приклад. Інтернет-магазин: функцію calculateTotal розробник перевіряє юніт-тестами; зв'язку «кошик → сервіс знижок» перевіряють інтеграційні тести; весь флоу замовлення тестувальник проходить на стейджингу; обмін з Новою поштою та платіжним шлюзом — окремий рівень; нарешті, менеджер продажів приймає фічу на UAT.

Example. An online shop: the developer covers the calculateTotal function with unit tests; the cart-to-discount-service link is covered by integration tests; the tester walks the whole order flow on staging; the exchange with the courier service and the payment gateway is a level of its own; finally a sales manager accepts the feature in UAT.

Підводні камені. Рівні не дорівнюють типам: регресію чи продуктивність можна робити на будь-якому рівні. Також рівні не обов'язково йдуть строго послідовно — в Agile вони перетинаються в межах одного спринту.

Pitfalls. Levels are not types: regression or performance testing can happen at any level. Nor do levels have to run strictly one after another — in Agile they overlap within a single sprint.

Що це. Компонентне тестування перевіряє найменшу окрему частину коду — функцію, метод, клас — в ізоляції від решти системи. Залежності на кшталт бази даних, мережі чи годинника підміняють заглушками (stub) або моками (mock), щоб тест залежав лише від логіки самого компонента. Пишуть такі тести переважно розробники, часто в тому ж репозиторії і за підходом TDD.

What it is. Component testing checks the smallest separate piece of code — a function, a method, a class — in isolation from the rest of the system. Dependencies such as the database, the network or the clock are replaced by stubs or mocks so the test depends only on the component's own logic. Developers usually write these tests, often in the same repository and often test-first.

Навіщо. Юніт-тести виконуються за мілісекунди, тому ловлять помилки в розрахунках і умовах ще до того, як збірка потрапить до тестувальника. Вони ж точно вказують місце поломки: впав тест applyDiscount — значить, проблема саме в цій функції, а не «десь у кошику».

Why it matters. Unit tests run in milliseconds, so they catch mistakes in calculations and conditions before a build ever reaches a tester. They also pinpoint the failure: if the applyDiscount test is red, the problem is in that function, not "somewhere in the cart".

Приклад. Мануальний QA може прочитати назви юніт-тестів і побачити, які межі розробник уже покрив. Якщо для знижки перевірено 999 і 1000 грн, але не перевірено від'ємну суму чи порожній кошик — це готові ідеї для обговорення або для власних перевірок на системному рівні.

Example. A manual QA can read the unit test names and see which boundaries the developer already covered. If the discount is checked for 999 and 1000 UAH but not for a negative amount or an empty cart, those are ready-made ideas to raise with the developer or to test at system level.

Підводні камені. Зелені юніт-тести не гарантують, що компоненти правильно працюють разом: моки можуть повертати дані у форматі, якого справжній сервіс ніколи не надішле. Також висока кількість тестів ще нічого не каже про їхню якість — тест без жодної перевірки (assert) теж «проходить».

Pitfalls. Green unit tests do not prove that components work together: a mock may return data in a shape the real service never sends. A large number of tests says nothing about their quality either — a test with no assertion at all also "passes".

Що це. Інтеграційне тестування перевіряє взаємодію та інтерфейси між частинами, а не логіку всередині кожної. Тестування інтеграції компонентів зосереджене на зв'язках модулів однієї системи (сервіс замовлень викликає сервіс складу). Тестування інтеграції систем перевіряє обмін із зовнішніми системами: платіжним провайдером, службою доставки, CRM.

What it is. Integration testing checks the interactions and interfaces between parts rather than the logic inside each one. Component integration testing focuses on links between modules of one system (the order service calling the stock service). System integration testing checks the exchange with external systems: a payment provider, a delivery service, a CRM.

Навіщо. Найчастіші дефекти на стиках — розбіжність форматів (сума в копійках проти гривень), неправильні коди помилок, таймаути, різне розуміння обов'язковості полів, некоректна обробка повторної відповіді. Кожен компонент окремо може бути ідеальним, а разом вони дають неправильне замовлення.

Why it matters. The most common defects at the seams are mismatched formats (an amount in kopecks versus hryvnias), wrong error codes, timeouts, differing views on which fields are mandatory and mishandled duplicate responses. Each component can be flawless on its own and still produce a wrong order together.

Приклад. Сервіс замовлень передає платіжному провайдеру amount: 1250, маючи на увазі гривні, а провайдер читає копійки і списує 12,50 грн. Юніт-тести обох сторін зелені. Знайти це може лише тест, що проходить реальний (або контрактно точний) виклик і звіряє суму на обох кінцях.

Example. The order service sends the payment provider amount: 1250, meaning hryvnias, but the provider reads it as kopecks and charges 12.50 UAH. Both sides have green unit tests. Only a test that makes a real (or contract-accurate) call and compares the amount on both ends can find this.

Підводні камені. Підхід «big bang», коли все з'єднують одночасно, робить локалізацію дефекту болісною. Інкрементальна інтеграція (зверху вниз, знизу вгору) повільніша на старті, зате кожен збій вказує на конкретний стик. Ще одна пастка — зовнішня пісочниця провайдера поводиться не так, як продакшн, тож результати варто перевіряти хоча б на одному бойовому сценарії з мінімальною сумою.

Pitfalls. The big-bang approach, where everything is wired together at once, makes defect localisation painful. Incremental integration (top-down or bottom-up) is slower to start but every failure points at a specific seam. Another trap: a provider's sandbox does not behave exactly like production, so it is worth confirming at least one live scenario with a minimal amount.

Що це. Системне тестування перевіряє повністю зібраний застосунок як єдине ціле на відповідність вимогам — і функціональним, і нефункціональним. Об'єкт тут — вся система з її інтерфейсом, API, базою та конфігурацією. Зазвичай це робить незалежна команда тестування, дивлячись на систему очима користувача та бізнесу.

What it is. System testing checks the fully assembled application as a whole against its requirements, both functional and non-functional. The test object is the entire system with its UI, API, database and configuration. It is usually done by an independent test team looking at the system through the eyes of the user and the business.

Навіщо. Лише на цьому рівні видно наскрізні сценарії: зареєструвався, додав товар, оплатив, отримав лист, побачив замовлення в історії. Тут же проявляються дефекти конфігурації — не той SMTP-сервер, відсутній переклад, неправильний часовий пояс. Щоб результатам можна було вірити, середовище має бути максимально схожим на продакшн: ті самі версії, налаштування, обсяги даних.

Why it matters. Only at this level can you see end-to-end scenarios: sign up, add a product, pay, get the email, see the order in history. Configuration defects appear here too — the wrong SMTP server, a missing translation, the wrong time zone. For the results to be trustworthy, the environment has to be as close to production as possible: same versions, settings and data volumes.

Приклад. На локальній машині розробника чекаут працює, бо часовий пояс там Київ. На стейджингу, де сервер стоїть у UTC, замовлення, оформлене о 00:30, потрапляє у звіт за попередню добу. Системний тест «замовлення після півночі» ловить це до релізу.

Example. Checkout works on the developer's laptop because its time zone is Kyiv. On staging, where the server runs in UTC, an order placed at 00:30 lands in the previous day's report. A system test for "an order after midnight" catches this before release.

Підводні камені. Системне тестування не замінює нижчих рівнів: шукати помилку округлення через UI довго й дорого. Інша пастка — «стейджинг» із трьома товарами в базі, на якому не видно проблем пагінації, пошуку чи продуктивності.

Pitfalls. System testing does not replace the lower levels: hunting a rounding bug through the UI is slow and expensive. Another trap is a staging with three products in the database, where pagination, search and performance problems simply cannot show up.

Що це. User Acceptance Testing — приймальне тестування, під час якого бізнес-користувачі або замовник підтверджують, що система дає їм змогу виконувати реальну роботу. Тестова база тут — бізнес-процеси, user stories і договірні вимоги, а не технічна специфікація. CTFL 4.0 виділяє кілька форм приймання: користувацьке, операційне (резервні копії, моніторинг, відновлення), договірне й регуляторне, а також альфа- та бета-тестування.

What it is. User Acceptance Testing is acceptance testing in which business users or the customer confirm that the system lets them do their real work. The test basis is business processes, user stories and contractual requirements rather than the technical specification. CTFL 4.0 lists several forms of acceptance: user, operational (backups, monitoring, recovery), contractual and regulatory, plus alpha and beta testing.

Навіщо. Системний тест відповідає на питання «чи працює як описано», а UAT — «чи цим можна користуватися в нашому процесі». Мета UAT — впевненість і рішення про приймання, а не пошук якомога більшої кількості дефектів. Якщо бухгалтерія не може закрити місяць новим звітом, фіча не прийнята, навіть якщо вона бездоганно відповідає специфікації.

Why it matters. A system test answers "does it work as described", while UAT answers "can we use this in our process". The goal of UAT is confidence and an acceptance decision, not finding as many defects as possible. If accounting cannot close the month with the new report, the feature is not accepted, even if it matches the specification perfectly.

Приклад. Бухгалтерка проходить сценарій «повернення товару за частковою оплатою» на даних, схожих на свої. Вона помічає, що звіт показує повернення окремим рядком, а їй для звірки потрібен підсумок по замовленню. Технічно це не баг, але приймальний критерій не виконано — це стає зміною для команди.

Example. An accountant walks through a "refund on a partially paid order" scenario using data close to her own. She notices the report shows the refund as a separate line, while reconciliation needs a total per order. Technically it is not a bug, but the acceptance criterion is not met, so it becomes a change request for the team.

Підводні камені. UAT не є «ще одним колом системного тестування силами бізнесу»: якщо користувачі знаходять там збої на кшталт помилки 500, значить, попередні рівні щось пропустили. Роль QA на UAT — підготувати середовище, дані, сценарії та допомогти оформити зауваження, а не проходити тести замість користувачів.

Pitfalls. UAT is not "one more round of system testing done by the business": if users hit failures like a 500 error there, the earlier levels missed something. The QA role in UAT is to prepare the environment, data and scenarios and to help log feedback, not to run the tests instead of the users.

Що це. Обидва — форми приймального тестування. Альфа-тестування проходить на майданчику розробника: продукт перевіряють потенційні користувачі або внутрішні співробітники не з команди розробки, часто в присутності команди. Бета-тестування проходить у реальному середовищі користувачів: обрана група клієнтів користується майже готовою версією на своїх пристроях і зі своїми даними.

What it is. Both are forms of acceptance testing. Alpha testing happens at the developer's site: potential users or internal staff outside the development team try the product, often with the team nearby. Beta testing happens in the users' own environment: a selected group of customers use a nearly finished version on their own devices and with their own data.

Навіщо. Альфа ловить грубі проблеми використання, поки їх ще дешево виправити і поки команда може спостерігати. Бета показує те, чого не відтворити в лабораторії: різноманіття пристроїв, мережі, реальні звички, неочікувані сценарії. Для мобільних застосунків бета зазвичай іде через TestFlight або закриті треки Google Play.

Why it matters. Alpha catches rough usability problems while they are still cheap to fix and while the team can watch. Beta reveals what a lab cannot reproduce: the variety of devices, networks, real habits and unexpected scenarios. For mobile apps a beta usually runs through TestFlight or closed tracks on Google Play.

Приклад. Банк випускає новий застосунок. Альфа: 30 співробітників з інших відділів два тижні користуються ним у офісі. Бета: 2 000 клієнтів отримують запрошення. Уже на третій день бета-телеметрія показує, що на певній моделі Android з увімкненим режимом економії енергії не приходять push-коди підтвердження — у лабораторії такого сполучення не було.

Example. A bank ships a new app. Alpha: 30 employees from other departments use it in the office for two weeks. Beta: 2,000 customers receive an invitation. By day three the beta telemetry shows that on one Android model with battery saver on, push confirmation codes never arrive — a combination the lab never had.

Підводні камені. Бета без каналу зворотного зв'язку і без збору крешів — просто ранній реліз. Варто заздалегідь вирішити, які метрики і які відгуки вважаються сигналом зупинити розгортання, і не забути про згоду користувачів на збір даних.

Pitfalls. A beta with no feedback channel and no crash reporting is just an early release. Decide in advance which metrics and which feedback count as a signal to halt the rollout, and do not forget user consent for data collection.

Що це. Функціональне тестування перевіряє, що система робить: чи правильні результати, чи виконуються бізнес-правила. Нефункціональне — наскільки добре вона це робить: швидкість, надійність, безпеку, зручність, сумісність, доступність. CTFL 4.0 спирається на модель якості ISO/IEC 25010, де характеристики — функціональна придатність, ефективність продуктивності, сумісність, взаємодія з користувачем (usability), надійність, безпека, супровідність і переносимість.

What it is. Functional testing checks what the system does: whether results are correct and business rules hold. Non-functional testing checks how well it does it: speed, reliability, security, usability, compatibility, accessibility. CTFL 4.0 leans on the ISO/IEC 25010 quality model, whose characteristics include functional suitability, performance efficiency, compatibility, usability (interaction capability), reliability, security, maintainability and portability.

Навіщо. Користувач кидає продукт не лише через неправильний результат, а й через повільну сторінку чи форму, яку неможливо заповнити з клавіатури. Якщо в плані тестування є лише функціональні перевірки, половина ризиків лишається непокритою. До речі, чорна й біла скринька — це не окремі типи за метою, а підходи до проєктування тестів.

Why it matters. Users abandon a product not only over a wrong result but also over a slow page or a form that cannot be filled in from the keyboard. If a test plan contains only functional checks, half the risks stay uncovered. Note that black-box and white-box are not types by purpose; they are approaches to designing tests.

Приклад. Для однієї фічі «вхід у систему» можна скласти перевірки кожного типу: правильний пароль пускає, неправильний — ні (функціональне); сторінка відповідає за 1 с при 500 одночасних входах (продуктивність); після 5 невдалих спроб — блокування (безпека); поля мають підписи для скрінрідера (доступність); вхід працює в Safari на iOS (сумісність).

Example. For a single "log in" feature you can write checks of every type: a correct password gets you in, a wrong one does not (functional); the page responds within 1 s with 500 concurrent logins (performance); after 5 failed attempts the account locks (security); fields have labels for screen readers (accessibility); login works in Safari on iOS (compatibility).

Підводні камені. Межа не завжди чітка: блокування після п'яти спроб — це функціональне правило, що реалізує вимогу безпеки. Не сперечайтесь на співбесіді про класифікацію, а покажіть, що покриваєте обидві сторони.

Pitfalls. The line is not always sharp: locking after five attempts is a functional rule implementing a security requirement. Do not argue about classification in the interview; show that you cover both sides.

Що це. Нефункціональне тестування перевіряє характеристики якості — продуктивність, надійність, безпеку, зручність, масштабованість. Проблема в тому, що вимоги до них часто звучать як «система має бути швидкою» чи «зручною». Таку фразу неможливо ні підтвердити, ні спростувати, отже, і протестувати. Робота QA — разом з аналітиком і бізнесом перетворити її на вимірювану умову: метрика, поріг, навантаження, середовище.

What it is. Non-functional testing checks quality characteristics — performance, reliability, security, usability, scalability. The trouble is that their requirements often read like "the system must be fast" or "user-friendly". A sentence like that can be neither confirmed nor refuted, so it cannot be tested. The QA's job is to work with the analyst and the business to turn it into a measurable condition: metric, threshold, load and environment.

Навіщо. Без числа кожен вирішує сам: розробник вважає 3 секунди нормою, продакт — катастрофою. Вимірювана вимога дає однозначний критерій проходження, дозволяє автоматизувати перевірку в пайплайні і стежити за деградацією від релізу до релізу.

Why it matters. Without a number everyone decides for themselves: the developer thinks 3 seconds is fine, the product owner thinks it is a disaster. A measurable requirement gives an unambiguous pass criterion, lets you automate the check in the pipeline and track degradation from release to release.

Приклад. «Пошук має працювати швидко» після розмови з бізнесом стає: «95-й перцентиль часу відповіді API пошуку не більше 800 мс при 200 запитах на секунду протягом 30 хвилин на стенді з каталогом 100 000 товарів; частка помилок нижче 0,5%». Тепер зрозуміло, що вимірювати, яким інструментом, з якими даними і коли тест провалено.

Example. After a talk with the business, "search must be fast" becomes: "the 95th percentile of search API response time is at most 800 ms at 200 requests per second for 30 minutes, on an environment with a 100,000-product catalogue; error rate below 0.5%". Now it is clear what to measure, with which tool, on what data, and when the test fails.

Підводні камені. Середнє значення маскує хвости — половина користувачів може чекати довше, ніж показує середнє, тому беруть перцентилі. Числа має погодити бізнес, а не придумати тестувальник: вони залежать від продукту, і будь-який поріг у цій картці — лише ілюстрація. І не забувайте про умови: вимога без навантаження та обсягу даних ні про що не говорить.

Pitfalls. An average hides the tail — half of the users can wait longer than the mean suggests, which is why percentiles are used. The business must agree the numbers, not the tester invent them: they depend on the product, and every threshold in this card is only an illustration. And do not forget conditions: a requirement without load and data volume says nothing.

Що це. Це підходи до проєктування тестів залежно від того, що тестувальник знає про систему. Чорна скринька спирається лише на специфікацію та поведінку: вхід → очікуваний вихід, без погляду на код. Біла скринька — на внутрішню структуру: гілки, умови, шляхи виконання; тут міряють покриття операторів і гілок. Сіра скринька поєднує обидва: тестуємо ззовні, але знаємо дещо про нутрощі — схему бази, API, логи, архітектуру.

What it is. These are approaches to test design depending on what the tester knows about the system. Black box relies only on the specification and behaviour: input → expected output, without looking at the code. White box relies on internal structure: branches, conditions, execution paths; here statement and branch coverage are measured. Grey box combines both: we test from the outside but know something about the internals — the database schema, the API, the logs, the architecture.

Навіщо. Кожен підхід ловить свої дефекти. Чорна скринька знаходить невідповідність вимогам, але не бачить «мертвих» гілок коду. Біла показує, яку логіку жоден тест не виконав, але не помітить, що вимоги реалізовано не ті. Сіра дає мануальному QA змогу цілитися точніше: перевірити запис у базі чи запит у Network, не читаючи весь код.

Why it matters. Each approach catches its own defects. Black box finds mismatches with requirements but cannot see dead branches in the code. White box shows which logic no test has executed but will not notice that the wrong requirement was implemented. Grey box lets a manual QA aim more precisely: check the database row or the request in Network without reading all the code.

Приклад. Правило: «безкоштовна доставка від 1000 грн». Чорна скринька: суми 999,99, 1000 і 1000,01 грн. Біла скринька: у коді умова написана як total > 1000, і тест на 1000 проходить гілку «платна доставка» — розбіжність зі специфікацією видно одразу. Сіра скринька: знаючи, що знижка застосовується до перевірки порогу, тестувальник перевіряє кошик 1100 грн із промокодом на 200 грн.

Example. The rule: "free delivery from 1000 UAH". Black box: totals of 999.99, 1000 and 1000.01 UAH. White box: the code says total > 1000, and the 1000 test goes through the "paid delivery" branch — the mismatch with the spec is obvious at once. Grey box: knowing the discount is applied before the threshold check, the tester tries a 1100 UAH cart with a 200 UAH promo code.

Підводні камені. 100% покриття гілок не означає відсутності дефектів: код може бути ідеально покритий і водночас реалізувати неправильне правило. А знання про нутрощі в сірій скриньці не повинно підміняти погляд користувача.

Pitfalls. 100% branch coverage does not mean there are no defects: code can be fully covered and still implement the wrong rule. And inside knowledge in grey-box testing must not replace the user's point of view.

Що це. Smoke-тест — короткий широкий прогін найважливіших функцій на свіжому білді: застосунок відкривається, логін працює, головний бізнес-потік проходить. Його ще називають build verification test. Sanity-тест — вузька, але глибша перевірка конкретної області після невеликої зміни чи фіксу: чи логіка, яку щойно чіпали, поводиться розумно, перш ніж витрачати час на повний регрес.

What it is. A smoke test is a short, wide run over the most important functions of a fresh build: the app starts, login works, the main business flow goes through. It is also called a build verification test. A sanity test is a narrow but deeper check of one specific area after a small change or fix: does the logic that was just touched behave reasonably before you spend time on full regression.

Навіщо і коли. Smoke запускають одразу після кожного деплою на тестове чи продакшн-середовище, і він відповідає на питання «чи можна взагалі тестувати цей білд». Якщо smoke впав, білд повертають, а не розбирають двадцять дрібних багів. Sanity запускають після фіксу або гарячого патча, коли часу мало і треба швидко переконатися, що зміна раціональна.

Why and when. Smoke runs right after every deployment to a test or production environment and answers one question: can this build be tested at all. If smoke fails, the build goes back instead of being picked apart into twenty small bugs. Sanity runs after a fix or a hotfix, when time is short and you need quick confidence that the change makes sense.

Приклад. Інтернет-магазин отримав новий білд 2.14.0. Smoke: головна відкривається, пошук повертає товари, товар додається в кошик, тестова оплата проходить. Окремо розробник виправив округлення знижки для промокоду SALE10 — sanity перевіряє саме знижку на кількох сумах і те, що підсумок у кошику збігається з підсумком у чеку.

Example. An online shop gets build 2.14.0. Smoke: the home page opens, search returns products, a product goes into the cart, a test payment succeeds. Separately, a developer fixed rounding of the SALE10 promo discount — sanity checks exactly that discount on a few amounts and that the cart total matches the receipt total.

Підводні камені. Термінологія плаває: у деяких командах sanity називають будь-яку швидку перевірку, тому на співбесіді варто коротко пояснити своє розуміння. Друга помилка — роздутий smoke на годину: він перестає бути швидким фільтром і його починають пропускати.

Pitfalls. The terms drift between teams: some call any quick check a sanity test, so in an interview it is worth stating your definition briefly. The second mistake is a smoke suite bloated to an hour: it stops being a quick gate and people start skipping it.

Що це. Повторне тестування (у глосарії ISTQB — confirmation testing) — це запуск тих самих кроків, які раніше виявили дефект, щоб підтвердити, що фікс його прибрав. Регресійне тестування перевіряє інше: чи зміна в коді, конфігурації чи середовищі не зламала те, що вже працювало, у тому числі в місцях, які ніхто не чіпав.

What it is. Re-testing (confirmation testing in the ISTQB glossary) means running the same steps that exposed a defect earlier, to confirm the fix removed it. Regression testing checks something else: that a change in code, configuration or environment did not break what already worked, including areas nobody touched.

Навіщо і коли. Повторний тест завжди прив'язаний до конкретного бага і має очікуваний результат з його опису. Регрес потрібен після кожної зміни, бо в системі є залежності, яких не видно з тікета. Прогнати весь регрес на кожен фікс зазвичай неможливо, тому обсяг вибирають через аналіз впливу: що змінилося, що з цим пов'язано і що найбільше болить бізнесу.

Why and when. A re-test is always tied to one bug and takes its expected result from that report. Regression is needed after every change, because the system has dependencies you cannot see from the ticket. Running the whole regression suite for every fix is usually impossible, so the scope is chosen through impact analysis: what changed, what is connected to it and what hurts the business most.

Приклад. Баг: промокод WELCOME15 не застосовувався до товарів зі знижкою. Розробник змінив функцію розрахунку ціни. Re-test — повторити кроки з бага. Регрес — усе, що використовує ту саму функцію: інші промокоди, кошик, повернення коштів, експорт замовлень у бухгалтерію, плюс короткий smoke оплати.

Example. Bug: the WELCOME15 promo code did not apply to discounted items. The developer changed the price calculation function. Re-test — repeat the steps from the bug. Regression — everything that uses the same function: other promo codes, the cart, refunds, order export to accounting, plus a short payment smoke.

Підводні камені. Закрити баг лише після re-test без регресу — класичний шлях до «виправили одне, зламали друге». Протилежна крайність — вимагати повний ручний регрес на кожен однорядковий фікс. Зазвичай регрес — найкращий кандидат на автоматизацію, бо він повторюється.

Pitfalls. Closing a bug after a re-test alone, with no regression, is the classic road to "fixed one thing, broke another". The opposite extreme is demanding a full manual regression for every one-line fix. Regression is usually the best candidate for automation precisely because it repeats.

Що це. Юзабіліті-тестування оцінює, наскільки реальні користувачі з цільової аудиторії можуть досягти своїх цілей ефективно, результативно і із задоволенням. Учасникам дають реалістичні задачі без підказок і спостерігають, де вони губляться. Буває модероване (ведучий поруч або на відеодзвінку) і немодероване (учасник проходить задачі сам, інструмент записує екран).

What it is. Usability testing assesses how effectively, efficiently and satisfyingly real users from the target audience can reach their goals. Participants get realistic tasks with no hints, and you watch where they get lost. It can be moderated (a facilitator sits next to them or on a video call) or unmoderated (the participant works alone and a tool records the screen).

Навіщо. Функціонально правильна форма може бути такою незрозумілою, що люди кидають оформлення замовлення. Думка тестера — корисна евристика, але тестер знає продукт напам'ять і не є типовим користувачем. Юзабіліті-тест дає факти: скільки учасників виконали задачу, за який час, скільки помилок зробили і що казали вголос.

Why it matters. A functionally correct form can be so confusing that people abandon checkout. A tester's opinion is a useful heuristic, but a tester knows the product by heart and is not a typical user. A usability test gives facts: how many participants completed the task, how long it took, how many errors they made and what they said out loud.

Приклад. Команда перероблює оформлення доставки. П'ятьом учасникам дають задачу «замовити каву з доставкою на відділення пошти в іншому місті». Троє шукають вибір відділення в полі адреси, двоє здаються — це вагоміший аргумент, ніж «мені здається, поле незрозуміле». Правило «п'яти користувачів» Якоба Нільсена — евристика для ітеративних тестів, а не статистична гарантія.

Example. A team redesigns the delivery step. Five participants get the task "order coffee for delivery to a post office branch in another city". Three look for the branch picker in the address field and two give up — a far stronger argument than "I think the field is unclear". Jakob Nielsen's five-user rule is a heuristic for iterative rounds, not a statistical guarantee.

Підводні камені. Навідні задачі («натисніть кнопку Обрати відділення») ламають тест. Колеги з команди — погані учасники. І юзабіліті не те саме, що доступність: перше про зручність для цільової аудиторії, друге — про можливість користуватися продуктом людям з інвалідністю.

Pitfalls. Leading tasks ("click the Choose branch button") ruin the test. Teammates are poor participants. And usability is not accessibility: the first is about ease of use for the target audience, the second about people with disabilities being able to use the product at all.

Що це. WCAG (Web Content Accessibility Guidelines) — стандарт W3C з доступності вебконтенту. Актуальна рекомендація — WCAG 2.2 (жовтень 2023), вона додала критерії на кшталт мінімального розміру цілі для натискання і видимого фокусу, який не перекривається. WCAG 2.1 рівня AA досі найчастіше фігурує в законодавстві, наприклад через європейський стандарт EN 301 549. Критерії згруповані за принципами POUR: сприйнятність, керованість, зрозумілість, надійність, і мають рівні A, AA, AAA; ціль зазвичай AA.

What it is. WCAG (Web Content Accessibility Guidelines) is the W3C standard for web content accessibility. The current recommendation is WCAG 2.2 (October 2023), which added criteria such as a minimum target size for pointer input and a focus that is not obscured. WCAG 2.1 level AA is still what legislation most often references, for example through the European standard EN 301 549. Criteria are grouped under the POUR principles — perceivable, operable, understandable, robust — and have levels A, AA and AAA; the usual target is AA.

Навіщо. Автоматичні сканери на кшталт axe чи Lighthouse ловлять лише частину проблем: вони бачать відсутній alt, але не скажуть, чи alt має сенс. Решту закриває ручна перевірка: клавіатура, скрінрідер, масштаб, контраст.

Why it matters. Automated scanners such as axe or Lighthouse catch only part of the problems: they see a missing alt but cannot tell whether the alt makes sense. The rest is covered by hand: keyboard, screen reader, zoom, contrast.

Приклад. Форма реєстрації: пройти її лише клавішею Tab, перевірити, що фокус видно, що помилка «невірний email» озвучується скрінрідером NVDA і прив'язана до поля, що кнопка «Далі» не менша за 24 на 24 CSS-пікселі, а сірий текст підказки має контраст щонайменше 4.5:1.

Example. A sign-up form: complete it using only Tab, check that focus is visible, that the "invalid email" error is announced by the NVDA screen reader and tied to the field, that the Next button is at least 24 by 24 CSS pixels, and that grey hint text has a contrast of at least 4.5:1.

Підводні камені. Колір як єдиний сигнал помилки (червона рамка без тексту) — порушення 1.4.1. Ще одна пастка — додавати ARIA там, де вистачить нативного button чи label: неправильний ARIA гірший за його відсутність.

Pitfalls. Colour as the only error signal (a red border with no text) breaks 1.4.1. Another trap is adding ARIA where a native button or label would do: wrong ARIA is worse than none.

Що це. Тестування сумісності перевіряє, що продукт працює однаково коректно в різних браузерах, операційних системах, на різних пристроях, роздільностях і версіях залежностей — наприклад, з різними версіями Android чи сторонніх бібліотек. Для вебу головні осі — рушій браузера (Chromium, WebKit, Gecko), ОС, розмір екрана і тип вводу (миша чи дотик).

What it is. Compatibility testing checks that the product works equally well across browsers, operating systems, devices, screen sizes and dependency versions — for example different Android versions or third-party libraries. For the web the main axes are the browser engine (Chromium, WebKit, Gecko), the OS, the screen size and the input type (mouse or touch).

Навіщо і як обрати. Комбінацій тисячі, тому матрицю будують з даних, а не з уявлень: беруть аналітику відвідувань за останні місяці, сортують за часткою трафіку і доходу, закривають 90–95 відсотків аудиторії, а решту фіксують як прийнятий ризик. Повний прогін роблять на першому рядку, на решті — smoke і місця, де рушії відрізняються найчастіше: форми, дати, скрол, відео.

Why and how to choose. There are thousands of combinations, so the matrix is built from data, not guesses: take visit analytics for recent months, sort by share of traffic and revenue, cover 90–95 percent of the audience and record the rest as an accepted risk. The full run goes on the top row; the others get smoke plus the places where engines differ most often: forms, date pickers, scrolling, video.

Приклад. Аналітика магазину показує, що 38 відсотків покупок — Safari на iPhone. Якщо команда тестувала лише в Chrome на ноутбуці, баг «поле дати не відкривається на iOS» дійде до користувачів. Тому Safari iOS отримує статус «повний прогін», хоча розробники ним майже не користуються.

Example. The shop's analytics show that 38 percent of purchases come from Safari on iPhone. If the team only tested in Chrome on a laptop, a "date field won't open on iOS" bug reaches users. So Safari on iOS gets a full run, even though the developers barely use it.

Підводні камені. Емулятор у DevTools міняє розмір вікна і user agent, але не рушій: Safari він не відтворює. Реальні пристрої або хмарні ферми потрібні хоча б для верхніх рядків матриці. І матрицю треба переглядати — частки браузерів змінюються.

Pitfalls. The DevTools device emulator changes the viewport and user agent but not the engine: it does not reproduce Safari. Real devices or a cloud device farm are needed at least for the top rows. And the matrix has to be reviewed — browser shares change.

Що це. Інтернаціоналізація (i18n) — це підготовка продукту до будь-якої мови й регіону ще на рівні архітектури: тексти винесені з коду, підтримується Unicode, формати дат, чисел і валют залежать від локалі, верстка витримує довші рядки і письмо справа наліво. Локалізація (l10n) — це адаптація під конкретний ринок: переклад, місцеві формати, юридичні тексти, культурні деталі.

What it is. Internationalisation (i18n) is preparing the product for any language and region at the architecture level: texts moved out of code, Unicode supported, date, number and currency formats driven by the locale, a layout that survives longer strings and right-to-left scripts. Localisation (l10n) is adapting to a specific market: translation, local formats, legal texts, cultural details.

Навіщо розділяти. Дефекти i18n однакові для всіх мов і дешевше знайти їх один раз, ще до перекладу, — наприклад, псевдолокалізацією, коли рядки штучно подовжують і обгортають спецсимволами. Дефекти l10n специфічні для ринку і їх часто ловить лише носій мови.

Why separate them. i18n defects are the same for every language and are cheaper to find once, before translation — for example with pseudo-localisation, where strings are artificially lengthened and wrapped in special characters. l10n defects are market-specific and often only a native speaker catches them.

Приклад. Кнопка «Buy» у німецькій стає «Jetzt kaufen» і вилазить за межі; дата 03/04/2025 для американця — 4 березня, для українця — 3 квітня; «1 товар, 2 товари, 5 товарів» — в українській три форми множини, і рядок «5 товар(ів)» видає відсутність правил плюралізації. Це i18n. А от переклад «Checkout» як «Перевірити» замість «Оформити замовлення» — дефект l10n.

Example. A "Buy" button becomes "Jetzt kaufen" in German and overflows; 03/04/2025 means March 4 to an American and April 3 to a Ukrainian; Ukrainian has three plural forms for "1 item, 2 items, 5 items", and a string like "5 item(s)" reveals missing plural rules. Those are i18n. Translating "Checkout" as the Ukrainian for "Verify" instead of "Place order" is an l10n defect.

Підводні камені. Склеювання речень з частин у коді («Ви маєте» + N + «повідомлень») робить правильний переклад неможливим. Ще часто забувають про сортування: алфавітний порядок з літерами «є», «і», «ї» відрізняється від простого порівняння кодів символів.

Pitfalls. Gluing sentences together in code ("You have" + N + "messages") makes a correct translation impossible. Sorting is also often forgotten: alphabetical order with Ukrainian letters like є, і, ї differs from a plain comparison of character codes.

Що це. Тестування відновлюваності — вид нефункціонального тестування надійності: систему свідомо ламають (зупиняють базу, обривають мережу, вбивають процес, вимикають вузол) і перевіряють, чи вона повертається до робочого стану, за який час і чи не втрачає та не дублює дані. Дві ключові цифри задає бізнес: RTO — за скільки сервіс має піднятися, RPO — скільки даних максимально можна втратити.

What it is. Recovery testing is a kind of non-functional reliability testing: you deliberately break the system (stop the database, cut the network, kill a process, switch off a node) and check whether it returns to a working state, how fast, and whether it loses or duplicates data. Two key numbers come from the business: RTO — how quickly the service must be back, and RPO — how much data can be lost at most.

Навіщо. Збої в продакшні неминучі, а найдорожчі наслідки — не сама недоступність, а неконсистентні дані: гроші списані, замовлення немає, або навпаки два списання за одну покупку. Функціональні тести на стабільному середовищі такого не покажуть.

Why it matters. Production failures are inevitable, and the costliest outcome is not downtime itself but inconsistent data: money taken with no order, or two charges for one purchase. Functional tests on a stable environment never show that.

Приклад. Під час оплати перезапускають базу замовлень. Очікування: клієнт бачить зрозуміле повідомлення, повторний запит з тим самим ключем ідемпотентності не створює другого списання, після підйому бази замовлення має статус paid або платіж скасовано, а черга повідомлень довантажила пропущені події.

Example. The order database is restarted during a payment. Expectation: the customer sees a clear message, a retry with the same idempotency key does not create a second charge, after the database is back the order is either paid or the payment is voided, and the message queue has delivered the missed events.

Підводні камені. Робити таке без погодження на спільному стенді — зіпсувати день іншим командам. Потрібні окреме середовище, моніторинг і план повернення. Інша помилка — перевірити лише «сайт знову відкривається» і не звірити дані в базі та в платіжного провайдера.

Pitfalls. Doing this unannounced on a shared environment ruins the day for other teams. You need a dedicated environment, monitoring and a rollback plan. Another mistake is checking only that "the site opens again" without reconciling data in the database and at the payment provider.

Що це. Тестування зворотної сумісності перевіряє, що нова версія системи продовжує коректно працювати з тим, що створене чи розгорнуте для попередніх: старими версіями мобільних застосунків, інтеграціями партнерів, збереженими даними, файлами експорту, закешованими фронтендами. Мобільні клієнти тут найгостріші, бо оновлення в сторах користувачі ставлять тижнями, а частина не ставить ніколи.

What it is. Backward compatibility testing checks that a new version of a system keeps working correctly with things created or deployed for earlier ones: old mobile app versions, partner integrations, stored data, export files, cached front ends. Mobile clients are the sharpest case, because users install store updates over weeks and some never do.

Як будувати. Спершу з'ясувати, які версії клієнтів ще активні і з якою часткою, — це дає аналітика або логи API з заголовком версії застосунку. Потім класифікувати зміни в контракті: додане необов'язкове поле зазвичай безпечне, а перейменування, зміна типу, новий обов'язковий параметр чи нове значення enum ламають старих. Для кожної активної версії тримати набір контрактних перевірок і прогнати його проти нового бекенду. Окремо тестують міграції даних: записи, створені старою версією, мають читатися новою, і навпаки під час поступового розгортання.

How to build it. First find out which client versions are still active and in what share — analytics or API logs with an app version header tell you. Then classify contract changes: an added optional field is usually safe, while a rename, a type change, a new required parameter or a new enum value breaks old clients. Keep a set of contract checks per active version and run it against the new back end. Data migrations are tested separately: records created by the old version must be readable by the new one, and vice versa during a gradual rollout.

Приклад. Бекенд додає статус замовлення on_hold. Застосунок 3.2, який ще стоїть у 12 відсотків користувачів, на невідомий статус падає. Рішення — віддавати старим клієнтам processing, а новий статус лише версіям від 4.0, і перевірити обидві гілки.

Example. The back end adds an on_hold order status. App 3.2, still installed for 12 percent of users, crashes on an unknown status. The fix is to send processing to old clients and the new status only to 4.0 and up, then test both branches.

Підводні камені. Тестувати лише найновіший клієнт, бо «старі скоро оновляться». І не мати політики підтримки версій: без неї кожен реліз перетворюється на суперечку, скільки старих версій ще треба перевіряти.

Pitfalls. Testing only the newest client because "the old ones will update soon". And having no version support policy: without one, every release turns into an argument about how many old versions still need checking.

Що це. Еквівалентне розбиття (equivalence partitioning, EP) ділить усі можливі вхідні значення на класи (партиції), всередині яких система, за нашим припущенням, поводиться однаково. З кожного класу достатньо одного представника: якщо 30 років приймається, то й 42 прийметься, бо обидва значення проходять через ту саму гілку логіки.

What it is. Equivalence partitioning (EP) splits every possible input value into partitions inside which, by our assumption, the system behaves the same way. One representative per partition is enough: if age 30 is accepted, 42 will be accepted too, because both values go through the same branch of logic.

Навіщо. Поле віку технічно приймає тисячі рядків. EP перетворює цей нескінченний простір на п'ять-сім перевірок і водночас гарантує, що жоден тип поведінки не залишився без тесту. Це прямий наслідок принципу «вичерпне тестування неможливе».

Why it matters. An age field technically accepts thousands of strings. EP turns that endless space into five to seven checks while making sure no kind of behaviour goes untested. It is a direct consequence of the principle that exhaustive testing is impossible.

Приклад. Вимога: «Вік — ціле число від 18 до 65 включно». Валідний клас один: 18–65. Невалідних більше: менше 18, більше 65, дробове число (18.5), літери («abc»), порожнє поле, самі пробіли. Кожен невалідний клас перевіряю окремим тестом, щоб одна помилка валідації не маскувала іншу.

Example. Requirement: "Age is an integer from 18 to 65 inclusive". There is one valid partition: 18–65. There are more invalid ones: below 18, above 65, a decimal (18.5), letters ("abc"), an empty field, only spaces. I test each invalid partition separately so that one validation error cannot mask another.

Підводні камені. Найчастіше забувають класи за типом і порожнє значення, бо думають лише про числову вісь. Друга помилка — об'єднати кілька невалідних значень в одному тесті: форма покаже першу помилку, а решту ти так і не перевіриш. І EP спирається на припущення про однакову поведінку, тож межі класів потім обов'язково добиваю аналізом граничних значень.

Pitfalls. People most often forget the type-based partitions and the empty value because they only think about the number line. The second mistake is combining several invalid values in one test: the form shows the first error and you never check the rest. And EP relies on an assumption of identical behaviour, so I always follow up the partition edges with boundary value analysis.

Що це. Аналіз граничних значень (boundary value analysis, BVA) перевіряє значення на краях упорядкованих класів еквівалентності, бо саме там розробники помиляються з операторами порівняння. ISTQB CTFL 4.0 описує два варіанти. У 2-значному для кожної межі беремо саму межу і найближчого сусіда з іншого класу. У 3-значному — межу і обох сусідів.

What it is. Boundary value analysis (BVA) tests values at the edges of ordered equivalence partitions, because that is where developers get comparison operators wrong. ISTQB CTFL 4.0 describes two variants. In two-value BVA, for each boundary you take the boundary itself and its closest neighbour from the other partition. In three-value BVA you take the boundary and both neighbours.

Навіщо і коли. Для поля 1..100 двозначний варіант дає 0, 1, 100, 101 — чотири тести. Тризначний дає 0, 1, 2, 99, 100, 101 — шість. Додаткові значення 2 і 99 ловлять помилку, коли замість x >= 1 написано x == 1 або межу зсунуто всередину класу. Тризначний варіант беру для грошей, лімітів і всього ризикового, двозначний — для рядових полів.

Why and when. For a 1..100 field the two-value variant gives 0, 1, 100, 101 — four tests. The three-value variant gives 0, 1, 2, 99, 100, 101 — six. The extra values 2 and 99 catch a bug where x == 1 was written instead of x >= 1, or where the boundary was shifted inside the partition. I use three-value for money, limits and anything risky, two-value for ordinary fields.

Приклад. Кількість товару в кошику: 1..100. Розробник написав qty > 1 && qty <= 100. Тест зі значенням 1 падає — одиниця не приймається, хоча має. Значення 50 з класу EP цей баг ніколи б не знайшло.

Example. Cart quantity: 1..100. The developer wrote qty > 1 && qty <= 100. The test with value 1 fails — one item is rejected although it should be allowed. The value 50 from the EP partition would never have found this bug.

Підводні камені. Популярна схема «Min, Min+1, Nominal, Max-1, Max» — це не BVA з CTFL: вона не містить значень за межами (0 і 101), а «номінальне» значення насправді належить до EP. Друга пастка — забути крок: для ціни з копійками сусід межі 1.00 — це 0.99, а не 0.

Pitfalls. The popular scheme "Min, Min+1, Nominal, Max-1, Max" is not the CTFL BVA: it leaves out the values outside the range (0 and 101), and the "nominal" value really belongs to EP. Another trap is forgetting the step: for a price with cents the neighbour of the 1.00 boundary is 0.99, not 0.

Що це. На практиці техніки не живуть окремо. Для пароля з правилом «6–20 символів, щонайменше одна літера й одна цифра» довжина — це впорядкований діапазон (там працює BVA), а склад символів — неупорядковані класи (там працює EP). Разом вони дають компактний набір, де кожен рядок перевіряє одну причину відмови.

What it is. In practice the techniques do not live apart. For a password with the rule "6–20 characters, at least one letter and one digit", length is an ordered range (BVA applies there), while the character mix forms unordered partitions (EP applies there). Together they give a compact set where each row checks one reason for rejection.

Навіщо. Якщо тестувати лише довжину, пропустиш пароль «password» без цифри. Якщо лише склад — пропустиш помилку length > 6, через яку шестисимвольний пароль відхиляється. Комбінація закриває обидва ризики і дає інтерв'юеру побачити, що ти мислиш моделлю, а не набором випадкових значень.

Why it matters. If you only test length, you miss "password" with no digit. If you only test the character mix, you miss a length > 6 bug that rejects a six-character password. The combination covers both risks and shows the interviewer that you think in a model rather than in random values.

Приклад. Значення довжини для BVA: 5, 6, 20, 21. Кожне валідне за довжиною значення будую так, щоб воно було валідним і за складом, — тоді відмова може статися лише через довжину. Для класів складу беру довжину з середини діапазону (8), щоб межі не втручались.

Example. Length values for BVA: 5, 6, 20, 21. I build every length-valid value so that it is also valid by character mix — then a rejection can only come from length. For the character partitions I use a length from the middle of the range (8) so the boundaries do not interfere.

Підводні камені. Вимога мовчить про пробіли, кирилицю, емодзі й те, як рахується довжина (символи чи байти). Це не «тестую на свій розсуд», а питання до аналітика, які я записую до виконання. Також перевіряю, що фронтенд і бекенд валідують однаково: відправка запиту в обхід форми часто показує, що сервер приймає 3 символи.

Pitfalls. The requirement says nothing about spaces, Cyrillic, emoji or how length is counted (characters or bytes). That is not "I test as I see fit" but a question for the analyst that I write down before execution. I also check that the front end and the back end validate the same way: sending the request around the form often shows the server happily accepts 3 characters.

Що це. Таблиця рішень описує бізнес-правило, де результат залежить від комбінації умов. Рядки зверху — умови (так/ні), рядки знизу — дії, а кожен стовпець — одне правило, тобто один тест. Для n бінарних умов повна таблиця має 2ⁿ стовпців: три умови дають вісім правил.

What it is. A decision table describes a business rule whose outcome depends on a combination of conditions. The top rows are conditions (yes/no), the bottom rows are actions, and each column is one rule, meaning one test. For n binary conditions the full table has 2ⁿ columns: three conditions give eight rules.

Навіщо. Текстові вимоги про знижки майже завжди неповні: «зареєстрованим 5% від 1000 грн, промокод дає 15%». А що, якщо є і те, і те? Таблиця змушує заповнити кожну клітинку, тому прогалини у вимогах видно ще до написання коду, — це й статичне тестування, і дизайн тестів водночас.

Why it matters. Written discount requirements are almost always incomplete: "registered users get 5% from 1000 UAH, a promo code gives 15%". What if both apply? The table forces you to fill every cell, so gaps in the requirements show up before any code is written — it is static testing and test design at the same time.

Приклад. Умови: C1 — користувач зареєстрований, C2 — сума від 1000 грн, C3 — промокод валідний. Правило бізнесу, яке ми уточнили з PO: знижки не сумуються, промокод 15% завжди перемагає, лояльність 5% діє лише для C1 і C2 без промокоду. Повна таблиця — 8 стовпців. Далі скорочую: коли C3 = так, результат не залежить від C1 і C2, тож чотири стовпці зливаються в один із «—» (байдуже).

Example. Conditions: C1 — the user is registered, C2 — the total is 1000 UAH or more, C3 — the promo code is valid. The business rule we clarified with the PO: discounts do not stack, the 15% promo always wins, and the 5% loyalty discount applies only for C1 and C2 without a promo code. The full table has 8 columns. Then I collapse it: when C3 = yes the outcome does not depend on C1 and C2, so four columns merge into one with "—" (don't care).

Підводні камені. Скорочувати можна лише тоді, коли ти довів, що умова справді не впливає; інакше втратиш тест, який ловив баг. Ризикові правила (гроші) я часто залишаю повною таблицею. І не забуваю про неможливі комбінації — їх позначаю, а не мовчки викидаю.

Pitfalls. You may only collapse when you have shown that a condition really has no effect; otherwise you drop the very test that would catch the bug. For risky rules involving money I often keep the full table. And I do not forget impossible combinations — I mark them rather than silently drop them.

Що це. Тестування переходів станів моделює об'єкт як скінченний автомат: стани, події, що їх змінюють, і дозволені переходи. Воно підходить усюди, де поведінка залежить від історії: замовлення, заявка, підписка, обліковий запис після трьох невдалих входів.

What it is. State transition testing models an object as a finite state machine: states, the events that change them, and the allowed transitions. It fits anywhere behaviour depends on history: an order, a request, a subscription, an account after three failed logins.

Навіщо. Діаграма дає два набори тестів. Перший — валідні переходи: покриття всіх переходів (0-switch coverage у CTFL) вимагає пройти кожну стрілку хоча б раз. Другий — невалідні переходи: пари станів без стрілки, які система має відхилити. Саме тут ховаються дорогі баги на кшталт скасування вже доставленого замовлення з поверненням грошей.

Why it matters. The diagram yields two sets of tests. The first is valid transitions: all-transitions coverage (0-switch coverage in CTFL) requires exercising every arrow at least once. The second is invalid transitions: state pairs with no arrow, which the system must reject. That is where costly bugs hide, such as cancelling an already delivered order and refunding the money.

Приклад. Замовлення має стани pending, paid, shipped, delivered, cancelled. Скасувати можна лише з pending (без оплати) або з paid (з поверненням коштів). Після відправлення скасування немає, а доставлене замовлення повертається окремим процесом «повернення», а не переходом у cancelled. П'ять станів дають 5 × 4 = 20 впорядкованих пар; валідних переходів п'ять, отже невалідних п'ятнадцять.

Example. An order has the states pending, paid, shipped, delivered, cancelled. It can be cancelled only from pending (no payment yet) or from paid (with a refund). There is no cancellation after shipping, and a delivered order goes back through a separate "return" flow, not a transition to cancelled. Five states give 5 × 4 = 20 ordered pairs; five transitions are valid, so fifteen are invalid.

Підводні камені. Невалідні переходи перевіряють не лише через UI, де кнопки просто сховані, а й через API: PATCH /orders/42 зі статусом cancelled для доставленого замовлення має отримати 409 або 422. Також не плутай стан зі сторінкою інтерфейсу — один екран може показувати кілька станів.

Pitfalls. Invalid transitions are checked not only through the UI, where the buttons are simply hidden, but also through the API: PATCH /orders/42 with status cancelled for a delivered order must get a 409 or 422. Also, do not confuse a state with a UI page — one screen may display several states.

Що це. Попарне (pairwise, all-pairs) тестування — комбінаторна техніка, яка гарантує, що кожна пара значень будь-яких двох параметрів трапиться хоча б в одному тесті. Повний перебір не потрібен, бо на практиці більшість дефектів конфігурацій виникає від взаємодії одного-двох параметрів, а не всіх одразу.

What it is. Pairwise (all-pairs) testing is a combinatorial technique that guarantees every pair of values of any two parameters appears in at least one test. You do not need the full product, because in practice most configuration defects are triggered by one or two interacting parameters rather than all of them at once.

Навіщо. Чекаут перевіряємо на 3 браузерах, 3 ОС, 2 мовах інтерфейсу і 2 способах оплати. Повний перебір — 3 × 3 × 2 × 2 = 36 прогонів. Мінімум для попарного покриття визначає добуток двох найбільших параметрів: 3 × 3 = 9. Тобто вчетверо менше роботи при збереженні всіх пар.

Why it matters. We check a checkout on 3 browsers, 3 operating systems, 2 UI languages and 2 payment methods. The full product is 3 × 3 × 2 × 2 = 36 runs. The minimum for pairwise coverage is set by the product of the two largest parameters: 3 × 3 = 9. That is a quarter of the work while keeping every pair.

Приклад. Таблицю нижче я склав вручну і перевірив: кожна пара браузер–ОС трапляється рівно раз, а пари з мовою та оплатою — щонайменше раз. На реальних проєктах таблицю генерують інструментом, наприклад Microsoft PICT, куди ще й додають обмеження на кшталт «Edge лише з Windows».

Example. I built the table below by hand and verified it: every browser–OS pair appears exactly once, and the pairs involving language and payment appear at least once. On real projects the table is generated by a tool such as Microsoft PICT, where you can also add constraints like "Edge only with Windows".

Підводні камені. Pairwise не знайде дефект, що проявляється лише на трійці значень, тож для критичних комбінацій (найпопулярніша платформа за аналітикою) додаю тести явно. Друга пастка — нереальні комбінації (Safari на Linux): без обмежень генератор їх видасть. І техніка працює для незалежних параметрів, а не для бізнес-правил, де краще таблиця рішень.

Pitfalls. Pairwise will not find a defect that only shows up for a specific triple of values, so for critical combinations (the most popular platform in analytics) I add tests explicitly. The second trap is unrealistic combinations (Safari on Linux): without constraints the generator will produce them. And the technique is for independent parameters, not for business rules, where a decision table is better.

Що це. Юз-кейс описує взаємодію актора з системою заради конкретної мети: передумови, основний (успішний) потік, альтернативні потоки, що теж ведуть до мети іншим шляхом, і виняткові потоки, де мета не досягається. Тестування на основі юз-кейсів перетворює кожен потік на щонайменше один наскрізний тест.

What it is. A use case describes an actor's interaction with the system to reach a specific goal: preconditions, the main (happy) flow, alternative flows that also reach the goal by another route, and exception flows where the goal is not reached. Use case testing turns every flow into at least one end-to-end test.

Навіщо. Техніки на кшталт EP дивляться на одне поле, а юз-кейс — на весь сценарій очима користувача. Так знаходяться дефекти інтеграції кроків: посилання приходить, але веде на 404; пароль змінено, але старі сесії залишились активними. Такі тести також добре лягають у системне тестування та UAT.

Why it matters. Techniques like EP look at one field, whereas a use case looks at the whole scenario through the user's eyes. That is how you find defects in the way steps fit together: the link arrives but leads to a 404; the password is changed but old sessions stay active. Such tests also fit naturally into system testing and UAT.

Приклад. Основний потік: користувач натискає «Забули пароль», вводить email, отримує лист, відкриває посилання, задає новий пароль, система підтверджує і завершує інші сесії. Альтернатива 2a: email не зареєстрований — система показує той самий нейтральний текст, щоб не розкрити, які адреси існують. Винятки: 4a посилання прострочене (у нашій вимозі 30 хв), 4b посилання вже використане, 5a новий пароль не проходить політику.

Example. Main flow: the user clicks "Forgot password", enters an email, receives a message, opens the link, sets a new password, and the system confirms and ends other sessions. Alternative 2a: the email is not registered — the system shows the same neutral text so it does not reveal which addresses exist. Exceptions: 4a the link has expired (30 min in our requirement), 4b the link has already been used, 5a the new password fails the policy.

Підводні камені. Покриття лише основного потоку — найчастіша помилка: найцікавіші дефекти сидять у винятках. Також юз-кейси часто мовчать про паралельні дії (два запити на відновлення поспіль — чи діє перше посилання?). Такі питання я додаю в тест як окремий рядок і уточнюю очікування.

Pitfalls. Covering only the main flow is the most common mistake: the most interesting defects sit in the exceptions. Use cases are also often silent about concurrent actions (two reset requests in a row — does the first link still work?). I add such questions as a separate row and clarify the expected result.

Що це. Вгадування помилок (error guessing) — техніка, заснована на досвіді: тестувальник передбачає, де розробник міг помилитись, спираючись на минулі дефекти, типові збої в подібних системах і знання технологій. У CTFL 4.0 її систематизована форма — атака на збої (fault attack): заздалегідь складений список можливих помилок, під який пишуться тести.

What it is. Error guessing is an experience-based technique: the tester anticipates where the developer may have gone wrong, drawing on past defects, typical failures in similar systems and knowledge of the technology. In CTFL 4.0 its systematic form is the fault attack: a list of likely faults prepared in advance, with tests written against it.

Навіщо. Формальні техніки покривають те, що написано у вимогах. Вгадування помилок ловить те, про що вимоги мовчать: файл нульового розміру, подвійне розширення, обрив мережі на середині. Воно найкраще працює як доповнення після EP і BVA, а не замість них.

Why it matters. Formal techniques cover what is written in the requirements. Error guessing catches what the requirements are silent about: a zero-byte file, a double extension, a network drop halfway through. It works best as an addition after EP and BVA, not as a replacement.

Приклад. Вимога: «аватар JPG або PNG до 5 МБ». EP і BVA дадуть типи файлів і межу 5 МБ. Мій список атак додає: файл .exe, перейменований на .jpg; розширення у верхньому регістрі .JPG; ім'я з пробілами, кирилицею і 200 символами; SVG з вбудованим скриптом; зображення 20000×20000 пікселів при малому розмірі файлу; повторне завантаження того самого файлу; скасування посередині.

Example. Requirement: "avatar in JPG or PNG up to 5 MB". EP and BVA give the file types and the 5 MB boundary. My attack list adds: an .exe renamed to .jpg; an upper-case .JPG extension; a name with spaces, Cyrillic and 200 characters; an SVG with an embedded script; a 20000×20000 pixel image with a small file size; uploading the same file twice; cancelling halfway.

Підводні камені. Без списку техніка залежить від настрою і досвіду конкретної людини, а результат не можна відтворити. Тому я веду командний чекліст атак і поповнюю його після кожного продакшн-інциденту. І не варто видавати вгадування помилок за повне покриття: воно не дає метрики на кшталт «усі класи перевірено».

Pitfalls. Without a list the technique depends on one person's mood and experience, and the result cannot be repeated. That is why I keep a team checklist of attacks and extend it after every production incident. And error guessing should not be presented as full coverage: it gives no metric like "all partitions checked".

Що це. Сеньйорське питання не про визначення технік, а про вибір: яку модель побудувати для кожної частини фічі і де зупинитись. Відповідь має показати, що техніка випливає зі структури вимоги (діапазон, комбінація правил, статуси, сценарій), а глибина — з ризику.

What it is. A senior question is not about defining techniques but about choosing: which model to build for each part of a feature and where to stop. The answer should show that the technique follows from the shape of the requirement (a range, a combination of rules, statuses, a scenario), while the depth follows from risk.

Навіщо. Одна фіча зазвичай містить усе одразу. У формі бронювання дати — діапазон з межами, кількість гостей — числа, тип номера і валюта — незалежні параметри, політика скасування — бізнес-правила, бронювання має статуси, а весь процес — наскрізний сценарій. Застосувати одну техніку до всього означає або роздути набір, або пропустити цілий клас дефектів.

Why it matters. One feature usually contains everything at once. In a booking form the dates are a range with boundaries, the guest count is numbers, room type and currency are independent parameters, the cancellation policy is business rules, the booking has statuses, and the whole process is an end-to-end scenario. Applying one technique to everything either bloats the suite or misses an entire class of defects.

Приклад. Для дат беру BVA (виїзд наступного дня після заїзду, максимум 30 ночей) плюс атаки на 29 лютого і перехід на літній час. Для політики скасування — таблицю рішень. Для статусів бронювання — переходи станів. Для конфігурацій — pairwise. Для всього процесу — юз-кейс. «Досить» визначаю через критерій покриття: усі класи, межі, правила й переходи з високим ризиком покриті, для низького ризику — двозначний BVA і скорочена таблиця.

Example. For dates I use BVA (check-out the day after check-in, a maximum of 30 nights) plus attacks on 29 February and the daylight saving switch. For the cancellation policy, a decision table. For booking statuses, state transitions. For configurations, pairwise. For the whole process, a use case. I define "enough" through a coverage criterion: all partitions, boundaries, rules and transitions with high risk are covered, while low-risk parts get two-value BVA and a collapsed table.

Підводні камені. Відповідь «тестів досить, коли знайдено всі баги» — червоний прапорець: принцип 1 каже, що тестування не доводить відсутність дефектів. Зупинка — це свідоме рішення за exit-критеріями з планом тестування і прийнятним залишковим ризиком, який я озвучую команді.

Pitfalls. The answer "there are enough tests when all bugs are found" is a red flag: principle 1 says testing cannot prove the absence of defects. Stopping is a deliberate decision based on the exit criteria in the test plan and an acceptable residual risk that I state openly to the team.

Що це. Тест-кейс — це одна задокументована перевірка: передумови, вхідні дані, кроки й очікуваний результат, який можна однозначно порівняти з фактичним. У глосарії ISTQB це набір передумов, вхідних даних, дій, очікуваних результатів і постумов, розроблений на основі тестових умов.

What it is. A test case is one documented check: preconditions, input data, steps and an expected result that can be compared with the actual one without ambiguity. The ISTQB glossary defines it as a set of preconditions, inputs, actions, expected results and postconditions developed from test conditions.

Навіщо. Добрий кейс відтворюваний: його пройде новенький у команді, колега з іншого часового поясу або ти сам через пів року, і результат буде той самий. Посилання на вимогу дає трасованість, пріоритет підказує, що запускати першим, коли часу мало.

Why it matters. A good case is repeatable: a newcomer, a colleague in another time zone or you yourself six months later will run it and get the same outcome. The link to a requirement gives traceability, and the priority tells you what to run first when time is short.

Приклад. Нижче заповнений кейс на застосування промокоду в кошику. Зверни увагу: дані конкретні (код SPRING10, сума 1200 грн), а очікуваний результат містить число, а не фразу «знижка застосовується коректно».

Example. Below is a filled case for applying a promo code in the cart. Notice that the data is concrete (code SPRING10, a total of 1200 UAH) and the expected result contains a number rather than the phrase "the discount applies correctly".

Підводні камені. Найчастіші помилки: кілька перевірок в одному кейсі (тоді незрозуміло, що саме впало), розмитий очікуваний результат, кроки, що покладаються на «знання системи», і забуті передумови на кшталт ролі користувача чи стану даних. Ще одна пастка — надмірна деталізація UI («натисни синю кнопку зліва»): після редизайну такі кейси доводиться переписувати всі.

Pitfalls. The usual mistakes: several checks in one case (so you cannot tell what failed), a vague expected result, steps that rely on "knowing the system", and forgotten preconditions such as the user role or the state of the data. Another trap is over-describing the UI ("click the blue button on the left"): after a redesign every such case has to be rewritten.

Що це. Чек-лист — перелік того, що треба перевірити, одним рядком на пункт, без детальних кроків і даних. Тест-кейс описує одну перевірку повністю. Тестовий набір (test suite) — це група кейсів або пунктів, зібраних за спільною ознакою: фіча, тип тестування, рівень ризику, смоук чи регресія.

What it is. A checklist is a list of things to verify, one line per item, without detailed steps or data. A test case describes one check in full. A test suite is a group of cases or items collected by a shared attribute: a feature, a test type, a risk level, smoke or regression.

Навіщо і коли. Чек-листа вистачає, коли продукт знає вся команда, фіча швидко змінюється, а виконують досвідчені тестери: він дешевий у підтримці й лишає місце для дослідження. Повні кейси потрібні там, де важлива відтворюваність і доказовість: регуляторні вимоги, передача роботи аутсорсу, складні розрахунки, кандидати в автоматизацію. Набори дозволяють запускати саме ту частину, що потрібна зараз, наприклад лише смоук після деплою.

When and why. A checklist is enough when the whole team knows the product, the feature changes quickly and experienced testers run it: it is cheap to maintain and leaves room for exploration. Full cases are needed where repeatability and evidence matter: regulatory requirements, handing work to an outsourced team, complex calculations, candidates for automation. Suites let you run exactly the part you need right now, for example only the smoke set after a deploy.

Приклад. Для фільтра пошуку товарів чек-лист із десяти рядків покриває основне за годину роботи. Ті самі пункти потім розкладаються в набори: критичні йдуть у смоук, решта — у регресію каталогу.

Example. For a product search filter a ten-line checklist covers the essentials in an hour of work. The same items are then spread across suites: the critical ones go into smoke, the rest into the catalogue regression.

Підводні камені. Пункт «перевірити фільтр» — це не чек-лист, а побажання: кожен рядок має називати конкретну умову. І навпаки, сто кейсів на кожен клік застарівають швидше, ніж їх встигають оновити. Набори варто переглядати: мертві кейси, які роками не знаходять дефектів, забирають час регресії.

Pitfalls. An item like "check the filter" is a wish, not a checklist line: each line must name a specific condition. At the other extreme, a hundred cases for every click go stale faster than anyone can update them. Suites need regular pruning: dead cases that have not found a defect in years eat regression time.

Що це. Тест-план описує, що, як, ким, коли і з якими ризиками тестуватиметься в межах проєкту чи релізу. Структуру зазвичай беруть з ISO/IEC/IEEE 29119-3, який замінив старий IEEE 829: контекст і обсяг, що в скоупі й поза ним, підхід і техніки, середовища й дані, ролі, графік, критерії входу й виходу, ризики, результати тестування (deliverables).

What it is. A test plan describes what will be tested, how, by whom, when and with what risks within a project or a release. The structure usually comes from ISO/IEC/IEEE 29119-3, which superseded the old IEEE 829: context and scope, what is in and out of scope, approach and techniques, environments and data, roles, schedule, entry and exit criteria, risks, and test deliverables.

Навіщо. План — це домовленість, а не формальність. Коли PM питає «чому ви не тестували IE?», відповідь уже записана в розділі «поза скоупом», і її погодили заздалегідь. Він також показує залежності: якщо стенд з'явиться на три дні пізніше, всі бачать, що зсуваються і терміни.

Why it matters. A plan is an agreement, not paperwork. When the PM asks "why didn't you test on IE?", the answer is already in the out-of-scope section and was agreed in advance. It also exposes dependencies: if the environment arrives three days late, everyone sees that the dates move too.

Приклад. В Agile-команді план на фічу вміщається на одну сторінку в Confluence або в описі епіка. Нижче такий план для оплати частинами: без води, але з усіма рішеннями, які хтось може оскаржити.

Example. In an Agile team a feature plan fits on one page in Confluence or in the epic description. Below is such a plan for pay-in-instalments: no filler, but every decision someone could challenge is written down.

Підводні камені. Сорокасторінковий план, скопійований з шаблону, ніхто не читає, і він застаріває до першого спринту. Інша крайність — плану немає зовсім, і скоуп з'ясовують у день релізу. Розділ ризиків часто заповнюють загальними фразами; корисний ризик завжди має конкретну дію-відповідь.

Pitfalls. A forty-page plan copied from a template goes unread and is out of date before the first sprint. The other extreme is no plan at all, with the scope discovered on release day. The risk section is often filled with generic phrases; a useful risk always comes with a concrete response.

Що це. Тестова стратегія — довгоживучий документ рівня продукту чи організації: які рівні тестування ми маємо, що автоматизуємо, які інструменти й середовища, як керуємо дефектами і що вважаємо достатньою якістю. Тест-план — конкретизація стратегії для одного проєкту, релізу чи фічі з датами, людьми та скоупом. Стратегія живе роками, план — тижні чи місяці.

What it is. A test strategy is a long-lived document at product or organisation level: which test levels we have, what we automate, which tools and environments we use, how defects are managed and what we consider good enough quality. A test plan applies the strategy to one project, release or feature with dates, people and scope. A strategy lives for years, a plan for weeks or months.

Навіщо. Без стратегії кожен план винаходить підхід заново, і команди одного продукту тестують по-різному. ISTQB описує типові підходи, з яких складають стратегію: аналітичний (зазвичай ризик-орієнтований), методичний (за чек-листами чи стандартом якості), реактивний (дослідницький, у відповідь на поведінку системи), консультативний, орієнтований на регресію, процесний. На практиці їх комбінують.

Why it matters. Without a strategy every plan reinvents the approach, and teams on one product test in different ways. ISTQB lists typical approaches a strategy is built from: analytical (usually risk-based), methodical (checklists or a quality standard), reactive (exploratory, responding to how the system behaves), consultative, regression-averse and process-compliant. In practice they are combined.

Приклад. Стратегія мобільного банку каже: платежі тестуються ризик-орієнтовано з обов'язковою автоматизованою регресією API, а UI — дослідницькими сесіями. План релізу 7.3 бере це правило й уточнює: цього разу змінено переказ за номером телефону, тож глибоко тестуємо його, а решту платежів проганяє регресія.

Example. A mobile bank's strategy says payments are tested risk-based with a mandatory automated API regression, and the UI through exploratory sessions. The plan for release 7.3 takes that rule and narrows it: this time transfer-by-phone-number changed, so it gets deep testing while the rest of the payments are covered by regression.

Підводні камені. У малих компаніях стратегію часто пишуть усередині плану, і це нормально, якщо розділ підходу справді відповідає на питання «як ми тестуємо взагалі». Погано, коли стратегія — красивий документ, який суперечить тому, що команда робить щодня.

Pitfalls. Small companies often write the strategy inside the plan, and that is fine as long as the approach section really answers "how do we test in general". It goes wrong when the strategy is a polished document that contradicts what the team does every day.

Що це. Критерії входу (entry criteria) — умови, які мають виконатися, перш ніж починати тестову активність. У CTFL 4.0 їх пов'язують із definition of ready: доступні ресурси (люди, середовище, дані, інструменти), готовий тестовий базис (вимоги, AC) і прийнятна якість об'єкта тестування, наприклад пройдений смоук.

What it is. Entry criteria are the conditions that must hold before a test activity starts. CTFL 4.0 relates them to the definition of ready: available resources (people, environment, data, tools), a ready test basis (requirements, acceptance criteria) and acceptable quality of the test object, for example a passed smoke test.

Навіщо. Вони захищають час команди. Тестування збірки, у якій не працює логін, дає сотню дублікатних багів і нуль інформації про нову фічу. Явні критерії дозволяють сказати «ми не почали» з аргументами, а не з емоціями.

Why it matters. They protect the team's time. Testing a build where login is broken produces a hundred duplicate bugs and zero information about the new feature. Explicit criteria let you say "we have not started" with arguments rather than emotions.

Приклад. У п'ятницю ввечері на stage приходить збірка з оплатою частинами, але sandbox банку недоступний, а два з п'яти AC досі в статусі «обговорюється». Я не блокую все: тестую те, що вже можна (калькулятор графіку, UI-валідацію), фіксую невиконані критерії в каналі релізу і пропоную варіант з моком відповіді банку. Рішення, чи рухатися далі з ризиком, ухвалює власник релізу.

Example. On Friday evening a build with pay-in-instalments lands on stage, but the bank sandbox is down and two of the five acceptance criteria are still "under discussion". I do not block everything: I test what is already testable (the schedule calculator, UI validation), post the unmet criteria in the release channel and propose mocking the bank response. The release owner decides whether to go ahead with the risk.

Підводні камені. Критерії на кшталт «код стабільний» неможливо перевірити, тож вони не працюють. Друга пастка — використовувати їх як шлагбаум і сидіти без роботи: у гнучких командах критерій входу — привід поговорити, а не заборона торкатися збірки.

Pitfalls. Criteria like "the code is stable" cannot be checked, so they do not work. The second trap is using them as a barrier and sitting idle: in agile teams an entry criterion is a reason to talk, not a ban on touching the build.

Що це. Критерії виходу (exit criteria) — умови, за яких тестову активність вважають завершеною. У CTFL 4.0 вони відповідають definition of done і зазвичай містять міри покриття, кількість і критичність відкритих дефектів, результати нефункціональних перевірок та готовність звіту. Єдиного стандарту чисел немає: «95% виконаних кейсів» чи «0 Critical» — це приклади, які команда погоджує в тест-плані під свій продукт і ризики.

What it is. Exit criteria are the conditions under which a test activity is considered complete. In CTFL 4.0 they correspond to the definition of done and usually include coverage measures, the number and severity of open defects, results of non-functional checks and a finished report. There is no standard set of numbers: "95% of cases executed" or "0 Critical" are examples the team agrees in the test plan for its own product and risks.

Навіщо. Без них тестування закінчується тоді, коли закінчився час, і ніхто не знає, наскільки ризикованим є реліз. Явні критерії перетворюють «здається, готово» на факти, на які можна послатися на go/no-go.

Why it matters. Without them testing ends when time runs out and nobody knows how risky the release is. Explicit criteria turn "looks done to me" into facts you can point to in a go/no-go meeting.

Приклад. Нижче критерії з плану релізу та знімок стану в день рішення. Один критерій не виконано: лишився відкритий Major. QA не ухвалює рішення про реліз одноосібно; я показую факти й залишковий ризик, а власник продукту вирішує, чи випускати з обхідним шляхом.

Example. Below are the criteria from the release plan and a status snapshot on decision day. One criterion is not met: one Major is still open. QA does not make the release decision alone; I show the facts and the residual risk, and the product owner decides whether to ship with a workaround.

Підводні камені. Числа без контексту дають хибну впевненість: 100% пройдених кейсів нічого не варті, якщо кейси не покривають змінену логіку. Також пам'ятай, що критерії можна переглянути, але це має бути свідоме рішення, записане разом з прийнятим ризиком, а не тихе заниження планки.

Pitfalls. Numbers without context give false confidence: 100% passed cases are worthless if the cases do not cover the changed logic. Also, criteria can be revised, but that has to be a conscious decision recorded together with the accepted risk, not a quiet lowering of the bar.

Що це. Матриця трасованості (RTM) зв'язує вимоги з тестами, а тести — з результатами й дефектами. Звіт про покриття вимог рахує, скільки вимог мають хоча б один тест і скільки з них пройдено. Покриття коду — інша міра: частка рядків (statement) чи гілок (branch), які виконались під час автотестів; його збирають інструменти на кшталт JaCoCo, Istanbul чи coverage.py.

What it is. A requirements traceability matrix (RTM) links requirements to tests, and tests to results and defects. A requirement coverage report counts how many requirements have at least one test and how many of those passed. Code coverage is a different measure: the share of statements or branches executed while automated tests ran; tools such as JaCoCo, Istanbul or coverage.py collect it.

Навіщо. RTM відповідає на питання «що ми забули протестувати?» і «що зачепить зміна вимоги REQ-7?». Для регульованих доменів (медицина, фінанси) вона часто обов'язкова. Покриття коду показує, які частини коду тести взагалі не запускали, але не каже, чи перевіряли вони щось осмислене.

Why it matters. An RTM answers "what did we forget to test?" and "what does a change to REQ-7 affect?". In regulated domains (medical, finance) it is often mandatory. Code coverage shows which parts of the code the tests never ran, but not whether they checked anything meaningful.

Приклад. У матриці нижче одразу видно дві проблеми: REQ-4 (блокування після п'яти невдалих спроб) не має жодного тесту, а в REQ-3 тест упав і пов'язаний з відкритим дефектом. Покриття вимог тут 3 з 4, пройдено 2 з 4 — це і є рядок у звіті.

Example. The matrix below shows two problems at once: REQ-4 (lock after five failed attempts) has no test at all, and the test for REQ-3 failed and is linked to an open defect. Requirement coverage here is 3 of 4, passed 2 of 4 — that is the line that goes into the report.

Підводні камені. Один тест на вимогу — ще не повне покриття: вимога «пароль 6–20 символів» потребує кількох перевірок меж. А 90% покриття коду не гарантують якості: тест без жодної перевірки (assert) теж «покриває» рядки. Матрицю, яку ведуть вручну в Excel, швидко закидають, тому краще тримати зв'язки в трекері (Jira, TestRail, Xray).

Pitfalls. One test per requirement is not full coverage: a rule like "password 6–20 characters" needs several boundary checks. And 90% code coverage does not guarantee quality: a test with no assertion also "covers" lines. A matrix maintained by hand in Excel gets abandoned quickly, so keep the links in the tracker (Jira, TestRail, Xray).

Що це. Оцінка тестування — прогноз зусиль на аналіз, дизайн, підготовку даних і середовища, виконання, ретести та звітність. Основні техніки з CTFL 4.0: декомпозиція роботи (WBS), трьохточкова оцінка, оцінка на основі історичних даних (ratio-based, наприклад частка від зусиль розробки) і експертна оцінка, зокрема Wideband Delphi чи planning poker.

What it is. A test estimate forecasts the effort for analysis, design, data and environment preparation, execution, retests and reporting. The main techniques in CTFL 4.0 are work breakdown (WBS), three-point estimation, estimation from historical data (ratio-based, such as a share of development effort) and expert-based estimation, including Wideband Delphi or planning poker.

Навіщо. Оцінка — це не обіцянка, а інструмент планування: вона показує, що саме займе час і де невизначеність. Трьохточкова формула (O + 4M + P) / 6 з PERT враховує оптимістичний, найімовірніший і песимістичний сценарій, а стандартне відхилення (P − O) / 6 дає чесний діапазон замість одного числа.

Why it matters. An estimate is a planning tool, not a promise: it shows what takes time and where the uncertainty is. The PERT three-point formula (O + 4M + P) / 6 accounts for the optimistic, most likely and pessimistic cases, and the standard deviation (P − O) / 6 gives an honest range instead of a single number.

Приклад. Для оплати частинами я розбиваю роботу на задачі, оцінюю кожну трьома числами і окремо додаю цикл ретестів, бо його забувають найчастіше. Виходить близько 8 днів із розкидом менше ніж на день. Менеджеру я показую не лише підсумок, а й драйвери: найбільший розкид дає інтеграція з банком через нестабільний sandbox.

Example. For pay-in-instalments I break the work into tasks, estimate each with three numbers and add a retest cycle separately, because that is the part people forget most often. It comes to about 8 days, give or take less than a day. I show the manager not just the total but the drivers: the widest spread comes from the bank integration because its sandbox is unstable.

Підводні камені. Оцінювати лише виконання кейсів, забуваючи про дані, середовище й ретести. Погоджуватися на «а можна за три дні?» без зміни скоупу: правильна відповідь — «так, якщо ми приберемо ось ці пункти і приймемо такий ризик». І не порівнювати з минулими фічами без поправки на різницю в складності.

Pitfalls. Estimating only case execution and forgetting data, environments and retests. Agreeing to "can you do it in three days?" without changing the scope: the right answer is "yes, if we drop these items and accept this risk". And comparing with past features without adjusting for the difference in complexity.

Що це. Життєвий цикл дефекту (defect life cycle) — узгоджений у команді набір станів і дозволених переходів, через які проходить звіт у трекері. Типовий ланцюжок: New → Open (Assigned) → In Progress → Fixed (Resolved) → Retest → Closed. Якщо перевірка після виправлення не пройшла, звіт переходить у Reopened і повертається до розробника. Є й бічні виходи: Rejected (це не дефект), Duplicate, Deferred (відкладено на пізніший реліз) і Cannot Reproduce.

What it is. The defect life cycle is the set of states and allowed transitions a report goes through in the tracker, as agreed by the team. A typical chain is New → Open (Assigned) → In Progress → Fixed (Resolved) → Retest → Closed. If the check after the fix fails, the report goes to Reopened and returns to the developer. There are side exits too: Rejected (not a defect), Duplicate, Deferred (postponed to a later release) and Cannot Reproduce.

Навіщо. Статус відповідає на просте питання: у кого зараз м'яч. Тестувальник створює звіт і закриває його після confirmation testing; тріаж-зустріч або тімлід призначає виконавця й пріоритет; розробник переводить у In Progress і Fixed. Без чітких переходів баги тижнями висять у Fixed, і ніхто не знає, чи фікс уже доїхав на стенд.

Why it matters. The status answers one plain question: who holds the ball right now. The tester creates the report and closes it after confirmation testing; a triage meeting or the team lead assigns an owner and a priority; the developer moves it to In Progress and Fixed. Without clear transitions bugs sit in Fixed for weeks and nobody knows whether the fix has reached the test environment.

Приклад. Звіт «знижка не застосовується до другого товару в кошику» створено в New. На тріажі його відкрили й призначили на бекенд. Розробник позначив Fixed у збірці 2.14.3, але на стенді ще 2.14.2, тож тестувальник чекає деплою, а не перевіряє одразу. Після деплою перевірка пройшла, разом із нею прогнано регресію кошика — звіт закрито.

Example. The report "discount is not applied to the second item in the cart" is created as New. Triage opens it and assigns it to the back end. The developer marks it Fixed in build 2.14.3, but the environment still runs 2.14.2, so the tester waits for the deploy instead of checking at once. After the deploy the check passes, the cart regression runs alongside it, and the report is closed.

Підводні камені. Закривати звіт, не звіривши номер збірки з фіксом. Перевідкривати старий баг, коли з'явилась схожа, але інша проблема, — краще новий звіт із посиланням на старий. Назви станів у Jira, YouTrack чи Azure DevOps різняться, тому на співбесіді пояснюй логіку переходів, а не конкретну схему. Як написати сам звіт, розібрано в окремому гайді Bug Reporting на цьому сайті.

Pitfalls. Closing a report without matching the build number to the fix. Reopening an old bug when a similar but different problem appears — a new report that links to the old one is better. State names differ between Jira, YouTrack and Azure DevOps, so in an interview explain the logic of the transitions rather than one tool's workflow. How to write the report itself is covered in the separate Bug Reporting guide on this site.

Що це. Severity (серйозність) за глосарієм ISTQB — ступінь впливу дефекту на роботу системи: падіння, втрата даних, неправильний розрахунок, косметика. Її зазвичай пропонує тестувальник, бо він бачив наслідок. Priority (пріоритет) — рівень бізнесової важливості й терміновості: як швидко це треба виправити. Його остаточно ставить власник продукту або тріаж, бо він знає релізні плани, клієнтів і гроші.

What it is. Severity, per the ISTQB glossary, is the degree of impact a defect has on the operation of the system: a crash, data loss, a wrong calculation, a cosmetic glitch. The tester usually proposes it because they saw the consequence. Priority is the level of business importance and urgency: how soon it has to be fixed. The product owner or the triage meeting sets it in the end, because they know the release plans, the customers and the money involved.

Навіщо розрізняти. Це дві різні осі, і саме тому шкал дві. Технічно тяжкий дефект може чекати, якщо він у рідкісному сценарії, а дрібниця може блокувати реліз, якщо її побачать усі. Коли команда плутає осі, розробники виправляють те, що гучніше звучить, а не те, що важливіше для користувачів.

Why keep them apart. These are two different axes, which is exactly why there are two scales. A technically severe defect can wait if it lives in a rare scenario, while a trivial one can block a release if everyone will see it. When a team mixes the axes, developers fix whatever sounds loudest rather than what matters most to users.

Приклад. Падіння адмінського експорту звітів за 2019 рік, яким користуються двічі на рік, — severity висока, priority низький. Помилка в назві бренду на головній сторінці в день рекламної кампанії — severity низька (нічого не ламається), priority найвищий. Решта прикладів — у матриці нижче.

Example. The admin export of 2019 reports crashes, and it is used twice a year — high severity, low priority. The brand name is misspelled on the home page on the day an ad campaign launches — low severity (nothing breaks), top priority. The other combinations are in the matrix below.

Підводні камені. Ставити Critical усім багам, щоб їх швидше взяли, — шкала знецінюється за тиждень. Вважати, що severity визначає черговість виправлення: черговість визначає priority. Шкали (Blocker/Critical/Major/Minor/Trivial чи P1–P4) у кожній команді свої, тому їх описують у тест-плані з прикладами. Детальніше про оформлення — у гайді Bug Reporting.

Pitfalls. Marking every bug Critical so it gets picked up faster — the scale loses its meaning within a week. Assuming severity decides the fixing order: priority does. Each team has its own scales (Blocker/Critical/Major/Minor/Trivial or P1–P4), so they are described in the test plan with examples. The report format itself is covered in the Bug Reporting guide.

Що це. Root cause analysis (RCA) — пошук першопричини дефекту чи інциденту, а не лише симптому. Фікс прибирає конкретний баг; RCA відповідає, чому процес дозволив йому виникнути і дійти до користувача. Найпоширеніші інструменти — «5 чому» (питати «чому?», доки відповідь не впреться в процес чи рішення) і діаграма Ісікави (fishbone), що розкладає причини за категоріями: вимоги, код, середовище, дані, процес, люди.

What it is. Root cause analysis (RCA) looks for the underlying cause of a defect or incident, not just its symptom. A fix removes one specific bug; RCA answers why the process let it be introduced and reach users. The common tools are the 5 Whys (keep asking "why?" until the answer hits a process or a decision) and the Ishikawa (fishbone) diagram, which sorts causes into categories: requirements, code, environment, data, process, people.

Як я її веду. Спершу збираю факти: таймлайн, логи, які збірки були на проді, скільки користувачів зачепило. Потім зустріч без пошуку винних (blameless) з розробником, QA і тим, хто чергував. Для кожної гілки причин формулюємо дію з власником і терміном; дія на кшталт «бути уважнішими» не приймається. Через кілька тижнів перевіряю, що дії справді виконані.

How I run it. First I gather facts: a timeline, logs, which builds were in production, how many users were affected. Then a blameless meeting with the developer, QA and whoever was on call. For each branch of causes we write an action with an owner and a deadline; an action such as "be more careful" is not accepted. A few weeks later I check that the actions were actually done.

Приклад. Частину клієнтів списали двічі за одне замовлення. Ланцюжок «5 чому» нижче веде від подвійного кліку до відсутності ідемпотентності в API оплати і прогалини в чеклісті ризиків. У підсумку чотири дії, серед них одна для QA: регресійний тест на подвійне надсилання форми.

Example. Some customers were charged twice for one order. The 5 Whys chain below leads from a double click to a payment API without idempotency and a gap in the risk checklist. The result is four actions, one of them for QA: a regression test for double form submission.

Підводні камені. Зупинитись на першому «чому» і записати причиною «розробник помилився». Шукати винного — люди перестануть ділитись фактами. Робити RCA для кожного дрібного бага: вона потрібна для інцидентів, повторюваних класів дефектів і втікачів із регресії.

Pitfalls. Stopping at the first "why" and recording "the developer made a mistake" as the cause. Hunting for someone to blame — people stop sharing facts. Running RCA for every minor bug: it pays off for incidents, recurring defect classes and bugs that slipped past regression.

Що це. Мінімум, який реально потрібен: методи (GET читає, POST створює, PUT/PATCH змінює, DELETE видаляє), групи статус-кодів (2xx — успіх, 3xx — перенаправлення, 4xx — помилка запиту клієнта, 5xx — помилка сервера), заголовки на кшталт Content-Type і Authorization, а також тіло запиту й відповіді, найчастіше в JSON. Усе це видно у вкладці Network у DevTools, а будь-який запит звідти можна скопіювати як curl.

What it is. The minimum you really need: methods (GET reads, POST creates, PUT/PATCH changes, DELETE removes), status code groups (2xx success, 3xx redirect, 4xx client request error, 5xx server error), headers such as Content-Type and Authorization, and the request and response bodies, usually JSON. All of it is visible in the DevTools Network tab, and any request there can be copied as curl.

Навіщо. Це дозволяє локалізувати баг, а не просто описати симптом. Якщо сервер повернув правильні дані, а екран показує інше — проблема на фронтенді. Якщо відповідь уже неправильна або прийшов 500 — на бекенді. Якщо запит узагалі не пішов — шукай у JavaScript-помилках консолі. Такий звіт розробник бере в роботу без зайвих уточнень.

Why it matters. It lets you localise the bug instead of only describing the symptom. If the server returned correct data but the screen shows something else, the problem is in the front end. If the response is already wrong or a 500 arrives, it is the back end. If the request was never sent, look for JavaScript errors in the console. A developer can pick up such a report without follow-up questions.

Приклад. При додаванні двох одиниць товару в кошик UI мовчки нічого не робить. У Network видно POST на /cart/items зі статусом 422 і полем error: qty_exceeds_stock. Бекенд поводиться правильно: на складі одна штука. Баг на фронтенді — він не показує користувачу повідомлення про помилку. Той самий запит, відтворений через curl, іде в звіт як доказ.

Example. Adding two units of a product to the cart silently does nothing in the UI. Network shows a POST to /cart/items with status 422 and an error field qty_exceeds_stock. The back end behaves correctly: only one unit is in stock. The bug is in the front end, which never shows the user an error message. The same request replayed with curl goes into the report as evidence.

Підводні камені. Вважати, що 200 означає «все добре»: деякі API повертають 200 з помилкою в тілі. Вставляти у звіт curl з живим токеном Authorization — його треба замаскувати. Плутати 401 (не автентифікований) і 403 (автентифікований, але без прав).

Pitfalls. Assuming 200 means "all good": some APIs return 200 with an error in the body. Pasting curl with a live Authorization token into the report — mask it. Confusing 401 (not authenticated) with 403 (authenticated but not allowed).

Що це. Для мануального QA база — ще один оракул. Екран «Дякуємо за замовлення» лише каже, що фронтенд отримав успішну відповідь; чи записались правильна сума, статус, позиції і чи не з'явився дубль, видно тільки в даних. Достатньо впевнено писати SELECT із WHERE і ORDER BY, робити JOIN між таблицями, рахувати через COUNT, SUM і GROUP BY та шукати дублікати через HAVING.

What it is. For a manual QA the database is one more oracle. The "Thank you for your order" screen only says the front end got a successful response; whether the right total, status and line items were stored, and whether a duplicate appeared, can be seen only in the data. It is enough to write SELECT with WHERE and ORDER BY confidently, JOIN tables, aggregate with COUNT, SUM and GROUP BY, and find duplicates with HAVING.

Навіщо. Частина дефектів ніколи не з'являється на екрані одразу: неправильно округлена сума, яку побачить бухгалтерія, статус, що не змінився після оплати, позиція без ціни. Перевірка в базі ловить їх у день тестування, а не через місяць у звіті фінансистів.

Why it matters. Some defects never show on screen right away: a badly rounded total that accounting will see later, a status that did not change after payment, a line item without a price. A database check catches them on the day of testing rather than a month later in a finance report.

Приклад. Клієнт 1017 купує два товари з промокодом. Перший запит знаходить останнє замовлення клієнта, другий звіряє суму позицій зі збереженим total з урахуванням знижки, третій перевіряє, що за останні десять хвилин у клієнта не створилось два замовлення (наслідок подвійного кліку).

Example. Customer 1017 buys two items with a promo code. The first query finds the customer's latest order, the second compares the sum of the line items with the stored total after the discount, and the third checks that the customer did not get two orders in the last ten minutes (the result of a double click).

Підводні камені. Запускати UPDATE чи DELETE «щоб підготувати дані» на спільному стенді й ламати тести колегам. Ходити на прод без дозволу і без read-only доступу. Порівнювати гроші у float — суми зберігають у DECIMAL або в копійках, і порівнювати треба так само. Забувати про часові пояси в created_at.

Pitfalls. Running UPDATE or DELETE "to prepare data" on a shared environment and breaking colleagues' tests. Querying production without permission and without read-only access. Comparing money as float — amounts are stored as DECIMAL or in minor units, and must be compared the same way. Forgetting time zones in created_at.

Що це. Дефект — це розбіжність між фактичною поведінкою і тестовою базою: вимогами, критеріями приймання, дизайном, стандартом чи обґрунтованим очікуванням користувача. Запит на зміну (change request) — бажання, щоб система поводилась інакше, ніж домовлено. «Так задумано» (works as designed) — поведінка відповідає базі, навіть якщо тестувальнику вона не подобається.

What it is. A defect is a mismatch between actual behaviour and the test basis: requirements, acceptance criteria, design, a standard or a reasonable user expectation. A change request is a wish for the system to behave differently from what was agreed. "Works as designed" means the behaviour matches the basis, even if the tester does not like it.

Навіщо. Від класифікації залежить, хто і коли платить за роботу. Баг виправляють у поточному релізі в межах естімейту; зміна йде в беклог, її оцінюють і пріоритезують як нову історію. Коли все підряд заводять багами, метрики якості брешуть, а суперечки на тріажі затягуються.

Why it matters. The classification decides who pays for the work and when. A bug is fixed in the current release within the estimate; a change goes to the backlog and is estimated and prioritised like a new story. When everything is filed as a bug, quality metrics lie and triage arguments drag on.

Приклад. Фільтр каталогу скидається після переходу на другу сторінку. У критеріях приймання написано «фільтр зберігається під час пагінації» — це баг. Якщо про пагінацію нічого не сказано, але конкуренти і власна мобільна версія фільтр зберігають, — це все одно дефект через порушення узгодженості, і я посилаюсь на мобільний застосунок як на оракул. Якщо ж PO свідомо вирішив скидати фільтр, а тестувальник вважає, що так незручно, — це пропозиція на покращення.

Example. The catalogue filter resets after moving to page two. The acceptance criteria say "the filter persists across pagination" — that is a bug. If pagination is not mentioned but the company's own mobile app keeps the filter, it is still a defect because consistency is broken, and I cite the mobile app as the oracle. If the PO deliberately chose to reset the filter and the tester just finds it inconvenient, that is an improvement proposal.

Підводні камені. Сперечатися «мені здається» замість посилання на конкретний рядок вимог або на оракул. Закривати звіт як works as designed, коли вимога сама суперечлива, — тоді дефект у вимозі, і його теж варто зафіксувати.

Pitfalls. Arguing with "I feel that" instead of pointing to a specific line of the requirements or to an oracle. Closing a report as works as designed when the requirement itself is contradictory — then the defect lives in the requirement, and that deserves a record too.

Що це. Agile-тестування — це тестування, вбудоване в кожну ітерацію, а не окрема фаза після розробки. Підхід whole-team означає, що за якість відповідає вся команда: розробники пишуть компонентні тести, PO уточнює критерії приймання, а тестувальник веде тестову експертизу, ставить незручні питання і допомагає іншим тестувати краще. Роль QA не зникає — вона зсувається від «перевірити готове» до «не дати зробити неправильно».

What it is. Agile testing is testing built into every iteration rather than a separate phase after development. The whole-team approach means the entire team owns quality: developers write component tests, the PO sharpens acceptance criteria, and the tester brings testing expertise, asks the awkward questions and helps others test better. The QA role does not disappear — it shifts from "check what is finished" to "prevent building the wrong thing".

Навіщо. Двотижневий спринт не залишає часу на тижневу регресію наприкінці. Якщо тестування почнеться в останні два дні, історії масово переїдуть у наступний спринт, а команда отримає «міні-водоспад» усередині Scrum.

Why it matters. A two-week sprint leaves no room for a week-long regression at the end. If testing starts in the last two days, stories roll over to the next sprint en masse and the team ends up with a mini-waterfall inside Scrum.

Приклад. На рефайнменті тестувальник помічає, що історія «оплата частинами» не каже, що робити при поверненні товару, і це питання потрапляє в критерії ще до оцінки. На дейлі він каже не «тестую», а «API розстрочки перевірив, чекаю збірку з UI, блокер — немає тестового банку». Для планування покриття корисні квадранти Agile-тестування (Marick, Crispin і Gregory): технологічні тести, що підтримують команду, бізнес-тести, дослідницькі та нефункціональні перевірки.

Example. At refinement the tester notices that the "pay in instalments" story says nothing about refunds, and that question lands in the criteria before estimation. At the daily they do not say "testing" but "instalment API checked, waiting for the UI build, blocker — no test bank account". For planning coverage, the Agile testing quadrants (Marick, Crispin and Gregory) help: technology-facing tests that support the team, business-facing tests, exploratory and non-functional checks.

Підводні камені. Тестувальник як «воротар», який у п'ятницю вирішує, чи випускати, — ознака того, що whole-team не працює. Друга пастка — вважати, що в Agile немає документації: тест-план стає легшим, але критерії, чекліст регресії й нотатки сесій нікуди не зникають.

Pitfalls. A tester acting as a gatekeeper who decides on Friday whether to ship is a sign the whole-team approach is not working. The second trap is believing Agile has no documentation: the test plan gets lighter, but criteria, a regression checklist and session notes are still there.

Що це. Три аміго — коротка зустріч (15–30 хвилин) трьох перспектив навколо однієї історії до початку розробки: бізнесу (PO або BA — що і навіщо), розробки (як це зробити і що технічно ризиковано) і тестування (що може піти не так). Учасників може бути більше трьох, важливі саме перспективи, а не кількість людей.

What it is. Three amigos is a short meeting (15–30 minutes) of three perspectives around one story before development starts: business (PO or BA — what and why), development (how to build it and what is technically risky) and testing (what can go wrong). There can be more than three people; what matters is the perspectives, not the headcount.

Навіщо. Більшість «багів» у нових фічах — насправді різне розуміння вимоги. Коли ці розбіжності знаходять за столом, вони коштують розмову, а не переписаний код і повторне тестування.

Why it matters. Most "bugs" in new features are really different readings of a requirement. When those gaps are found at the table, they cost a conversation rather than rewritten code and another round of testing.

Приклад. Історія: «Як покупець я хочу зберегти картку, щоб платити швидше». Тестувальник питає, що буде з простроченою карткою і чи можна зберегти дві однакові; розробник уточнює, що номер картки зберігає платіжний провайдер, а ми маємо лише токен. Результат зустрічі — конкретні приклади, які стають критеріями приймання та першими тест-кейсами. Популярний формат — Example Mapping: жовта картка для історії, сині для правил, зелені для прикладів, червоні для відкритих питань.

Example. Story: "As a shopper I want to save my card so I can pay faster". The tester asks what happens to an expired card and whether the same card can be saved twice; the developer clarifies that the card number is stored by the payment provider and we only keep a token. The output is concrete examples that become acceptance criteria and the first test cases. A popular format is Example Mapping: a yellow card for the story, blue ones for rules, green for examples, red for open questions.

Підводні камені. Зустріч без результату на папері швидко забувається — фіксуйте приклади в самій історії. І не перетворюйте три аміго на оцінку або дизайн архітектури: якщо червоних карток забагато, історія не готова і її варто повернути PO.

Pitfalls. A meeting with no written output is forgotten quickly — record the examples in the story itself. And do not turn three amigos into estimation or architecture design: if there are too many red cards, the story is not ready and should go back to the PO.

Що це. Критерії приймання (acceptance criteria, AC) — умови, які конкретна історія має виконати, щоб PO її прийняв. Вони описують поведінку з погляду користувача, а не реалізацію. Пишуть їх двома способами: списком правил («знижка не поєднується з іншими промокодами») або сценаріями у форматі Given/When/Then.

What it is. Acceptance criteria (AC) are the conditions a specific story must meet for the PO to accept it. They describe behaviour from the user's point of view, not the implementation. They are written in two ways: as a list of rules ("the discount cannot be combined with other promo codes") or as Given/When/Then scenarios.

Навіщо. Для тестувальника AC — головна тестова основа (test basis) історії: з кожного критерію виходить щонайменше одна позитивна і одна негативна перевірка. Якщо критерій не можна перевірити — «швидко», «зручно», «коректно» — його треба переписати до початку розробки. Це частина літери T (Testable) у моделі INVEST.

Why it matters. For a tester AC are the main test basis of a story: every criterion yields at least one positive and one negative check. If a criterion cannot be verified — "fast", "convenient", "correctly" — it must be rewritten before development starts. This is the T (Testable) in the INVEST model.

Приклад. Історія «Як покупець я хочу застосувати промокод у кошику». Поганий критерій: «промокод працює правильно». Хороші: «код знижує суму на вказаний відсоток», «прострочений код показує повідомлення і не змінює суму», «код не чутливий до регістру». Кожен із них одразу підказує тестові дані та очікуваний результат.

Example. Story: "As a shopper I want to apply a promo code in the cart". A bad criterion: "the promo code works correctly". Good ones: "the code reduces the total by the stated percentage", "an expired code shows a message and leaves the total unchanged", "the code is case-insensitive". Each one immediately suggests test data and an expected result.

Підводні камені. AC не замінюють Definition of Done: DoD однаковий для всіх історій, а AC — унікальні для однієї. Ще одна помилка — вважати, що AC охоплюють усе: тестувальник додає крайові випадки й нефункціональні ризики, про які в критеріях не написали.

Pitfalls. AC do not replace the Definition of Done: the DoD is the same for every story, while AC are unique to one. Another mistake is assuming AC cover everything: the tester adds edge cases and non-functional risks the criteria never mention.

Що це. Definition of Ready (DoR) — домовленість команди про те, коли історію можна брати в спринт: вона зрозуміла, оцінена, має критерії й не заблокована. Definition of Done (DoD) — спільний для всіх історій список того, що має бути зроблено, щоб інкремент вважався завершеним. DoD офіційно входить у Scrum Guide як зобов'язання щодо інкременту; DoR — поширена практика, яку Scrum Guide не вимагає.

What it is. The Definition of Ready (DoR) is the team's agreement on when a story can enter a sprint: it is understood, estimated, has criteria and is not blocked. The Definition of Done (DoD) is a checklist shared by all stories of what must be finished for the increment to count as complete. The DoD is formally part of the Scrum Guide as the commitment for the Increment; the DoR is a common practice the Scrum Guide does not require.

Навіщо. DoR захищає вхід спринту від сирих історій, DoD — вихід від «майже готового». Без DoD «готово» означає для розробника «код змерджено», а для PO — «можна показувати клієнтам», і ця різниця вилазить на демо.

Why it matters. The DoR guards the sprint entrance against half-baked stories; the DoD guards the exit against "almost done". Without a DoD, "done" means "code merged" to a developer and "ready for customers" to the PO, and that gap surfaces at the demo.

Приклад. Від тестування в DoR варто внести: критерії перевірювані, відомі тестові дані й доступи, зрозуміло, на якому стенді тестувати. У DoD — усі AC перевірені, автотести на нову логіку є і зелені, немає відкритих дефектів severity critical і major за цією історією, регресія зміненої зони пройдена.

Example. Testing should put into the DoR: criteria are testable, test data and access are known, and it is clear which environment to test on. Into the DoD: all AC verified, automated tests for the new logic exist and are green, no open critical or major defects for the story, regression of the changed area passed.

Підводні камені. DoR, перетворений на бюрократичну браму, гальмує команду — історію з одним відкритим питанням часто можна взяти, якщо відповідь буде до середини спринту. Критерії приймання не є частиною DoD: вони описують конкретну історію, а DoD — загальну планку якості.

Pitfalls. A DoR turned into a bureaucratic gate slows the team down — a story with one open question can often be taken if the answer arrives by mid-sprint. Acceptance criteria are not part of the DoD: they describe one story, while the DoD is the general quality bar.

Що це. Behaviour-Driven Development — підхід, у якому поведінку системи описують конкретними прикладами, зрозумілими бізнесу, розробці й тестуванню. У ньому три практики: discovery (обговорення прикладів, наприклад на трьох аміго), formulation (запис прикладів мовою Gherkin — Given/When/Then) і automation (перетворення сценаріїв на виконувані тести через Cucumber, SpecFlow, Behave тощо).

What it is. Behaviour-Driven Development is an approach where system behaviour is described through concrete examples that business, development and testing all understand. It has three practices: discovery (discussing examples, for instance at three amigos), formulation (writing the examples in Gherkin — Given/When/Then) and automation (turning scenarios into executable tests with Cucumber, SpecFlow, Behave and so on).

Навіщо. Сценарії стають живою документацією: якщо поведінка зміниться, а сценарій ні, тест впаде. Бізнес читає ту саму специфікацію, яку виконує CI, і розбіжність між «що хотіли» та «що зробили» стає видимою.

Why it matters. Scenarios become living documentation: if behaviour changes and the scenario does not, the test fails. The business reads the same specification that CI executes, so the gap between "what we wanted" and "what we built" becomes visible.

Приклад. Для правила «безкоштовна доставка від 1000 грн» пишемо декларативний сценарій — про бізнес-правило, а не про кліки. Імперативний варіант («я клікаю кнопку з id cart, вводжу 1000 у поле…») читається як скрипт і ламається від кожної зміни UI.

Example. For the rule "free delivery from 1000 UAH" we write a declarative scenario — about the business rule, not about clicks. The imperative version ("I click the button with id cart, I type 1000 into the field…") reads like a script and breaks with every UI change.

Підводні камені. Найчастіша помилка — «BDD без розмов»: тестувальник сам пише .feature-файли після розробки, і Gherkin стає лише зайвим шаром над автотестами. Друга — сотні сценаріїв на кожну дрібницю: Gherkin варто залишати для бізнес-правил, а перевірки полів тестувати нижче.

Pitfalls. The most common mistake is "BDD without conversations": a tester writes .feature files alone after development, and Gherkin becomes an extra layer on top of automation. The second is hundreds of scenarios for every detail: keep Gherkin for business rules and test field checks at lower levels.

Що це. Test-Driven Development — практика розробки, де тест пишуть до коду короткими циклами. Red: пишемо один маленький тест, запускаємо і бачимо, що він падає з очікуваної причини. Green: пишемо мінімальний код, щоб тест пройшов. Refactor: прибираємо дублювання і покращуємо назви, не змінюючи поведінку, — тести мають лишатися зеленими.

What it is. Test-Driven Development is a development practice where the test is written before the code, in short cycles. Red: write one small test, run it and see it fail for the expected reason. Green: write the minimal code to make it pass. Refactor: remove duplication and improve names without changing behaviour — the tests must stay green.

Навіщо. TDD змушує продумати поведінку і межі до реалізації, а код виходить тестованим за побудовою. Для тестувальника це означає, що базові випадки вже перевірені на рівні компонента, тож ручне і системне тестування можна зосередити на інтеграціях, сценаріях і ризиках.

Why it matters. TDD forces you to think through behaviour and boundaries before the implementation, and the code comes out testable by construction. For a tester it means the basic cases are already checked at component level, so manual and system testing can focus on integrations, scenarios and risks.

Приклад. Функція isAdult для реєстрації з обмеженням 18+. Спершу тест на 18 — червоний, бо функції ще немає. Потім найпростіший код і другий тест на 17, який змушує написати справжню умову. Наостанок рефакторинг: магічне число стає константою. Тестувальник може підказати розробнику граничні значення 17 і 18 ще до першого рядка коду.

Example. An isAdult function for an 18+ sign-up rule. First a test for 18 — red, because the function does not exist yet. Then the simplest code, and a second test for 17 that forces a real condition. Finally a refactor: the magic number becomes a constant. A tester can suggest the boundary values 17 and 18 to the developer before the first line of code.

Підводні камені. TDD не гарантує 100% покриття і не замінює тестування: тести перевіряють лише те, що розробник уявив. Висока покриттєвість, досягнута TDD, нічого не каже про пропущені вимоги чи інтеграційні дефекти. І пропускати фазу Red небезпечно — тест, який жодного разу не падав, міг би нічого не перевіряти.

Pitfalls. TDD does not guarantee full code coverage and does not replace testing: the tests check only what the developer imagined. High coverage reached through TDD says nothing about missed requirements or integration defects. And skipping the Red step is risky — a test that has never failed might not be checking anything.

Що це. Shift-left — перенесення тестових активностей якомога раніше в життєвий цикл: рев'ю вимог і дизайну, три аміго, статичний аналіз, компонентні та API-тести ще до готового UI, вимоги до тестованості на етапі архітектури. Це пряме застосування третього принципу ISTQB: раннє тестування заощаджує час і гроші.

What it is. Shift-left means moving testing activities as early as possible in the life cycle: reviewing requirements and design, three amigos, static analysis, component and API tests before the UI is ready, testability requirements at the architecture stage. It is a direct application of the third ISTQB principle: early testing saves time and money.

Навіщо. Чим пізніше знайдено дефект, тим більше роботи він тягне за собою: переписати вимогу, код, тести, повторно протестувати, випустити хотфікс, а іноді ще й відшкодувати клієнтам. Проте популярні множники на кшталт «у 100 разів дорожче» походять зі старих досліджень (Boehm, 1970–80-ті) на проєктах іншого типу і сьогодні оскаржуються, тож на співбесіді краще говорити якісно, без точних коефіцієнтів.

Why it matters. The later a defect is found, the more work it drags along: rewriting the requirement, the code and the tests, retesting, shipping a hotfix, sometimes compensating customers. However, popular multipliers such as "100 times more expensive" come from old studies (Boehm, 1970s–80s) on very different projects and are disputed today, so in an interview it is better to argue qualitatively, without precise ratios.

Приклад. У вимозі сказано «повернення коштів протягом 14 днів», але не сказано, від якої дати — оплати чи доставки. На рев'ю вимоги це одне питання в коментарі. Після релізу це суперечка з клієнтами, зміна логіки, міграція даних і повторна регресія.

Example. A requirement says "refund within 14 days" but not from which date — payment or delivery. At requirement review that is one question in a comment. After release it is a dispute with customers, a logic change, a data migration and another regression round.

Підводні камені. Shift-left не означає «тестувальник приходить раніше і робить те саме»: змінюється тип роботи — більше запитань, прикладів і профілактики. Він також не скасовує shift-right: моніторинг, feature flags і канаркові релізи ловлять те, що до продакшну не відтворити.

Pitfalls. Shift-left does not mean "the tester arrives earlier and does the same thing": the kind of work changes — more questions, examples and prevention. Nor does it cancel shift-right: monitoring, feature flags and canary releases catch what cannot be reproduced before production.

Що це. Continuous testing — автоматичне виконання тестів на кожному етапі пайплайна, від коміту до продакшну, щоб кожна зміна одразу отримувала оцінку ризику. Quality gate — умова, без виконання якої збірка не йде далі: впали компонентні тести, статичний аналіз знайшов критичну проблему, smoke на стенді червоний.

What it is. Continuous testing is running tests automatically at every stage of the pipeline, from commit to production, so every change gets an immediate risk assessment. A quality gate is a condition without which the build does not move on: component tests failed, static analysis found a critical issue, the smoke run on the environment is red.

Навіщо. Швидкий зворотний зв'язок: розробник дізнається про поломку через кілька хвилин, поки ще пам'ятає, що змінював. Без цього регресія накопичується до кінця спринту, і вже ніхто не знає, котрий із сорока мерджів усе зламав.

Why it matters. Fast feedback: a developer learns about a break within minutes, while they still remember what they changed. Without it, regressions pile up until the end of the sprint and nobody knows which of forty merges broke things.

Приклад. На pull request запускаються лінтер і компонентні тести — кілька хвилин. Після мерджу — API- та інтеграційні тести на ефемерному стенді. Перед релізом — короткий набір E2E на критичних шляхах і, за потреби, навантажувальний тест. Після деплою — smoke на продакшні і моніторинг помилок. Мануальний QA тут не зникає: він тестує нове дослідницьки, поки пайплайн стереже старе.

Example. On a pull request the linter and component tests run — a few minutes. After merge, API and integration tests run on an ephemeral environment. Before release, a short E2E set on critical paths and, if needed, a load test. After deploy, a production smoke and error monitoring. The manual QA does not vanish: they explore what is new while the pipeline guards what already exists.

Підводні камені. Повільний або нестабільний пайплайн люди починають обходити — перезапускають, доки не позеленіє, або вимикають гейт. Тому швидкі тести ставлять першими, а флейкі ізолюють. Ще одна пастка — перенести всю ручну регресію в UI-автотести: такий набір виконується годину і ламається від кожної зміни верстки.

Pitfalls. People start bypassing a slow or unstable pipeline — rerunning until it goes green or disabling the gate. So fast tests go first and flaky ones are quarantined. Another trap is moving the whole manual regression into UI automation: such a suite takes an hour and breaks with every layout change.

Що це. Парне тестування — дві людини тестують одну річ за одним комп'ютером: одна веде (driver, керує клавіатурою), друга спостерігає, пропонує ідеї і записує (navigator). Пара буває «тестувальник + розробник», «тестувальник + BA чи PO», «досвідчений + новачок». Якщо учасників більше, це вже mob testing — вся команда навколо одного екрана.

What it is. Pair testing is two people testing one thing at one computer: one drives (holds the keyboard), the other observes, suggests ideas and takes notes (the navigator). Pairs can be tester + developer, tester + BA or PO, senior + newcomer. With more participants it becomes mob testing — the whole team around one screen.

Навіщо. Розробник бачить, як тестувальник думає, і наступного разу сам перевіряє ці випадки. Тестувальник дізнається, як фіча влаштована всередині, і знаходить ризики, про які не здогадався б ззовні. Дефекти виправляються одразу, без баг-репорту й черги.

Why it matters. The developer sees how a tester thinks and checks those cases on their own next time. The tester learns how the feature works inside and spots risks they would not guess from outside. Defects are fixed on the spot, with no bug report and no queue.

Приклад. Розробник закінчив імпорт товарів з CSV. Сесія на 45 хвилин із чартером: «дослідити імпорт на кривих файлах». Тестувальник веде, розробник коментує: «тут ми читаємо по 500 рядків». Одразу виникає ідея — файл на 501 рядок, де помилка саме в останньому рядку. Ролі змінюються кожні 15 хвилин.

Example. A developer has finished product import from CSV. A 45-minute session with a charter: "explore the import with broken files". The tester drives, the developer comments: "we read 500 rows at a time here". An idea appears at once — a 501-row file with the error in the very last row. Roles swap every 15 minutes.

Підводні камені. Якщо розробник весь час веде, виходить демо «щасливого шляху» — тому тестувальник має керувати хоча б половину часу. Без чартера і таймбоксу сесія розпливається. І не варто спаровувати людей на кожну історію: це дорогий формат, його залишають для складних або ризикових змін.

Pitfalls. If the developer drives the whole time, you get a happy-path demo — so the tester should be at the keyboard at least half the time. Without a charter and a timebox the session drifts. And do not pair on every story: it is an expensive format, kept for complex or risky changes.

Що це. Флейкі-тест — тест, який на тому самому коді й середовищі то проходить, то падає. Типові причини: гонки й фіксовані очікування, спільні тестові дані між паралельними тестами, залежність від порядку виконання, реальний час і часові пояси, нестабільні зовнішні сервіси чи стенд. Іноді флейкі-тест насправді ловить справжній гонковий дефект у продукті.

What it is. A flaky test passes and fails on the same code and environment. Typical causes: races and fixed sleeps, test data shared between parallel tests, dependence on execution order, real time and time zones, unstable external services or environments. Sometimes a flaky test is actually catching a real race condition in the product.

Навіщо з ними боротись системно. Кожен флейкі-тест знецінює весь набір: команда звикає, що червоне «нічого не означає», і пропускає справжню регресію. Автоматичний retry ховає проблему і подвоює час пайплайна.

Why deal with them systematically. Every flaky test devalues the whole suite: the team gets used to red "meaning nothing" and misses a real regression. Automatic retries hide the problem and double the pipeline time.

Приклад політики. Вимірюємо: частка нестабільних прогонів кожного тесту за останні 14 днів. Тест, що хоч раз «пройшов після перезапуску», автоматично потрапляє в карантин — виконується, але не блокує мердж, і на нього одразу створюється задача з власником і терміном. Якщо тест не виправили за спринт, його видаляють або переписують нижчим рівнем. Retry дозволений лише як тимчасовий захід і обов'язково звітується.

Policy example. We measure: the share of unstable runs for each test over the last 14 days. A test that ever "passed on retry" goes to quarantine automatically — it still runs but does not block the merge, and a ticket with an owner and a deadline is created straight away. If it is not fixed within a sprint, it is deleted or rewritten at a lower level. Retries are allowed only as a temporary measure and are always reported.

Підводні камені. Карантин без власника перетворюється на кладовище, де лежать сотні вимкнених тестів. І не списуйте все на «інфраструктуру»: спершу перевірте, чи не падає тест через справжній дефект конкурентності.

Pitfalls. A quarantine without owners becomes a graveyard of hundreds of disabled tests. And do not blame everything on "infrastructure": first check whether the test fails because of a genuine concurrency defect.

Що це. Мутаційне тестування оцінює якість самих тестів. Інструмент робить у коді маленьку зміну — мутанта: замінює >= на >, + на -, true на false, видаляє виклик — і запускає тести. Якщо хоч один тест упав, мутанта «вбито»; якщо всі зелені, мутант «вижив», тобто тести не помітили зміни поведінки. Mutation score — частка вбитих мутантів серед усіх, крім еквівалентних.

What it is. Mutation testing assesses the quality of the tests themselves. A tool makes a small change in the code — a mutant: it replaces >= with >, + with -, true with false, removes a call — and runs the tests. If at least one test fails, the mutant is "killed"; if all stay green, it "survived", meaning the tests did not notice the behaviour change. The mutation score is the share of killed mutants among all non-equivalent ones.

Навіщо. Покриття коду каже лише, що рядок виконувався під час тестів, а не що результат перевіряли. Тест без жодного assert дає 100% покриття і вбиває нуль мутантів. Мутації показують слабкі перевірки й пропущені граничні значення.

Why it matters. Code coverage only says a line was executed during tests, not that the result was checked. A test with no assertion at all can still reach 100% line coverage and kill zero mutants. Mutations expose weak assertions and missing boundary values.

Приклад. Правило «безкоштовна доставка від 1000 грн». Тест перевіряє лише суму 1500 — покриття рядка повне. Мутант замінює >= на > і виживає, бо 1500 більше за 1000 в обох версіях. Додаємо тест на рівно 1000 — мутанта вбито. Мутаційне тестування фактично змусило нас зробити аналіз граничних значень.

Example. The rule "free delivery from 1000 UAH". The test checks only a total of 1500 — line coverage is complete. A mutant replaces >= with > and survives, because 1500 is above 1000 in both versions. We add a test for exactly 1000 — the mutant is killed. Mutation testing effectively forced us to do boundary value analysis.

Підводні камені. Це дорого: кожен мутант — окремий прогін тестів, тому запускають на критичних модулях або лише на змінених файлах у PR. Еквівалентні мутанти, які не змінюють поведінки, вбити неможливо, і їх доводиться розбирати вручну. Інструменти — PIT (pitest) для Java, Stryker для JavaScript/TypeScript і .NET, mutmut для Python.

Pitfalls. It is expensive: each mutant is a separate test run, so it is used on critical modules or only on files changed in a PR. Equivalent mutants that do not change behaviour cannot be killed and must be reviewed by hand. Tools: PIT (pitest) for Java, Stryker for JavaScript/TypeScript and .NET, mutmut for Python.

Що це. Дослідницьке тестування — підхід, у якому вивчення продукту, проєктування тестів і їх виконання відбуваються одночасно: результат попередньої перевірки підказує наступну. Від хаотичного клікання його відрізняють три речі: чітка мета (чартер), обмежений час і нотатки, з яких потім можна відтворити, що перевірили і що знайшли. ISTQB відносить його до технік, заснованих на досвіді.

What it is. Exploratory testing is an approach in which learning the product, designing tests and running them happen at the same time: the result of one check suggests the next. Three things set it apart from random clicking: a clear goal (the charter), a time box and notes from which you can later reconstruct what was covered and what was found. ISTQB classes it among experience-based techniques.

Навіщо і коли. Коли вимоги неповні, фіча нова, часу мало або скриптові тести вже «зношені» і перестали знаходити дефекти. Воно добре доповнює тест-кейси: скрипт перевіряє відоме, дослідження шукає невідоме. Корисні евристики: SFDIPOT (структура, функції, дані, інтерфейси, платформа, операції, час), CRUD, межі, переривання дії, повтор дії.

Why and when. When requirements are incomplete, the feature is new, time is short, or scripted tests have worn out and stopped finding defects. It complements test cases well: a script checks the known, exploration hunts for the unknown. Useful heuristics: SFDIPOT (structure, function, data, interfaces, platform, operations, time), CRUD, boundaries, interrupting an action, repeating an action.

Приклад. Чартер за формулою Елізабет Гендріксон: «Дослідити ціль з ресурсами, щоб виявити інформацію». Для промокодів у кошику це 60 хвилин на прострочені, комбіновані й записані різним регістром коди з метою знайти помилки розрахунку знижки. Знахідки йдуть у нотатки з часом, а баги — одразу в трекер.

Example. A charter follows Elisabeth Hendrickson's template: "Explore target with resources to discover information". For promo codes in the cart it is 60 minutes on expired, stacked and mixed-case codes, aimed at finding discount calculation errors. Findings go into time-stamped notes, and bugs go straight to the tracker.

Підводні камені. Називати дослідницьким тестуванням відсутність будь-якого плану. Не вести нотаток — тоді результат не можна ні показати, ні повторити. Роздувати чартер до «протестувати весь чекаут»: він має вміщатися в одну сесію.

Pitfalls. Calling the absence of any plan exploratory testing. Keeping no notes — then the result can be neither shown nor repeated. Inflating the charter to "test the whole checkout": it must fit into one session.

Що це. Session-based test management (SBTM) — спосіб керувати дослідницьким тестуванням, запропонований Джонатаном і Джеймсом Бахами. Робота ділиться на сесії: безперервний відрізок часу (зазвичай 60–120 хвилин) під один чартер без відволікань. Після кожної сесії тестувальник заповнює session sheet і проходить коротке обговорення з лідом (debrief).

What it is. Session-based test management (SBTM) is a way to manage exploratory testing, proposed by Jonathan and James Bach. Work is split into sessions: an uninterrupted block of time (usually 60–120 minutes) on one charter without distractions. After each session the tester fills in a session sheet and goes through a short debrief with the lead.

Навіщо. Менеджер часто питає: «Скільки ви протестували, якщо тест-кейсів немає?» SBTM дає відповідь цифрами: кількість сесій на область, розподіл часу між проєктуванням і виконанням тестів, розслідуванням багів і налаштуванням (TBS-метрики), частку роботи за чартером проти побічних знахідок. Debrief за схемою PROOF (Past, Results, Obstacles, Outlook, Feelings) перетворює нотатки на рішення: що дослідити далі.

Why it matters. A manager often asks: "How much did you test if there are no test cases?" SBTM answers with numbers: sessions per area, the split of time between test design and execution, bug investigation and setup (TBS metrics), and the share of on-charter work versus opportunity findings. A debrief following PROOF (Past, Results, Obstacles, Outlook, Feelings) turns notes into a decision about what to explore next.

Приклад. Сесія на чартер «імпорт CSV з клієнтами» тривала 90 хвилин. 20% часу пішло на підготовку файлів, 25% — на розслідування двох багів, решта — на власне тестування. Лід на debrief бачить, що підготовка даних з'їдає багато часу, і просить розробника додати набір готових файлів у репозиторій.

Example. A session on the charter "import customers from CSV" lasted 90 minutes. 20% of the time went into preparing files, 25% into investigating two bugs, and the rest into testing proper. At the debrief the lead sees that data preparation eats a lot of time and asks a developer to add a set of ready-made files to the repository.

Підводні камені. Перетворити session sheet на бюрократію на пів години — форма має заповнюватися за кілька хвилин. Пропускати debrief: без нього метрики просто лежать у папці. Порівнювати тестувальників за кількістю знайдених багів за сесію — це вбиває чесні нотатки.

Pitfalls. Turning the session sheet into half an hour of paperwork — it should take a few minutes. Skipping the debrief: without it the metrics just sit in a folder. Ranking testers by bugs found per session — that kills honest notes.

Що це. Risk-based testing — підхід, у якому обсяг, порядок і глибина тестування визначаються рівнем ризику. Ризик за ISTQB — це ймовірність × вплив. Продуктові ризики стосуються якості (неправильна знижка, витік даних), проєктні — умов роботи (стенд не готовий, розробник у відпустці). Тестування зменшує саме продуктові ризики; проєктні враховують у плані.

What it is. Risk-based testing is an approach where the scope, order and depth of testing are set by the level of risk. Risk, per ISTQB, is likelihood × impact. Product risks concern quality (a wrong discount, a data leak); project risks concern working conditions (the environment is not ready, a developer is on leave). Testing reduces product risks; project risks are handled in the plan.

Як я це роблю. Разом із PO, розробниками й підтримкою складаю список ризиків для релізу. Ймовірність оцінюємо за складністю змін, новизною коду, історією дефектів; вплив — за грошима, кількістю користувачів, юридичними наслідками. Кожен ризик отримує оцінку 1–3 за двома осями, добуток визначає рівень. Високий — формальні техніки (таблиці рішень, межі), автотести, незалежна перевірка, дослідницькі сесії. Середній — стандартні тест-кейси. Низький — smoke або чекліст.

How I do it. With the PO, developers and support I build a list of risks for the release. Likelihood is judged by change complexity, code novelty and defect history; impact by money, number of users and legal consequences. Each risk gets a 1–3 score on both axes, and the product sets its level. High means formal techniques (decision tables, boundaries), automated checks, an independent review and exploratory sessions. Medium means standard test cases. Low means smoke or a checklist.

Приклад. У релізі інтернет-магазину нова знижка лояльності, оновлений платіжний SDK, редизайн футера і новий фільтр. Матриця нижче показує, що платежі й знижка отримують найбільше часу, а футер — лише візуальну перевірку. Якщо часу забракне, спершу скорочуємо низькі ризики, і це рішення фіксується разом із залишковим ризиком.

Example. An online shop release contains a new loyalty discount, an updated payment SDK, a footer redesign and a new filter. The matrix below shows payments and the discount getting most of the time, while the footer gets only a visual check. If time runs short, low risks are cut first, and that decision is recorded together with the residual risk.

Підводні камені. Оцінювати ризики самотужки — QA не знає всіх бізнес-наслідків. Скласти матрицю один раз і не переглядати її, коли з'являються нові дефекти. Сприймати низький ризик як «не тестувати зовсім».

Pitfalls. Scoring risks alone — QA does not know every business consequence. Building the matrix once and never revisiting it as new defects appear. Treating low risk as "do not test at all".

Що це. Testability (тестованість) — міра того, наскільки легко і ефективно систему можна протестувати. Вона тримається на кількох властивостях: керованість (можу привести систему в потрібний стан), спостережуваність (бачу, що всередині сталося), ізольованість (можу перевірити частину окремо від решти), простота і стабільність (поведінка не змінюється щодня без попередження).

What it is. Testability is the degree to which a system can be tested easily and effectively. It rests on a few properties: controllability (I can put the system into the state I need), observability (I can see what happened inside), isolation (I can check one part apart from the rest), simplicity and stability (behaviour does not change every day without notice).

Навіщо. Низька тестованість не робить тестування неможливим, вона робить його дорогим і повільним. Якщо щоб перевірити знижку на день народження треба чекати справжнього дня народження, а щоб побачити помилку треба просити логи в DevOps, цикл одного тесту розтягується на години. Тому тестованість — вимога, яку QA приносить на рефайнмент, а не скарга після релізу.

Why it matters. Low testability does not make testing impossible; it makes it expensive and slow. If checking a birthday discount means waiting for an actual birthday, and seeing an error means asking DevOps for logs, one test cycle stretches into hours. So testability is a requirement QA brings to refinement, not a complaint after the release.

Приклад. Команда робить підписку з автоматичним продовженням через 30 днів і листом за 3 дні до списання. Без змін у дизайні перевірити це можна лише за місяць. Мій список запитів нижче: керування часом на стенді, тестовий платіжний шлюз, доступ до листів, стабільні атрибути для локаторів і кореляційний ID у логах.

Example. The team is building a subscription that renews automatically after 30 days, with an email three days before the charge. Without design changes this can only be checked a month later. My list of requests is below: time control on the test environment, a sandbox payment gateway, access to sent emails, stable attributes for locators and a correlation ID in the logs.

Підводні камені. Просити тестованість після того, як код написано, — тоді кожен хук коштує переробки. Лишати тестові ендпоінти відкритими на проді: їх вимикають прапорцем або захищають. Робити обхідні шляхи, які змінюють поведінку системи, — тоді тестуєш уже не те, що піде до користувачів.

Pitfalls. Asking for testability after the code is written — every hook then costs rework. Leaving test endpoints open in production: they are disabled by a flag or protected. Building shortcuts that change the system's behaviour — then you are testing something other than what users will get.

Що це. Test data management — стратегія того, звідки беруться тестові дані, хто їх створює, як вони ізольовані між тестами й людьми і коли прибираються. Основні джерела: синтетичні дані (згенеровані з нуля), замасковані або анонімізовані копії продакшну, невеликі вибірки (subsets) і статичні довідники на кшталт країн чи валют.

What it is. Test data management is the strategy for where test data comes from, who creates it, how it is isolated between tests and people, and when it is cleaned up. The main sources are synthetic data (generated from scratch), masked or anonymised copies of production, small subsets and static reference data such as countries or currencies.

Навіщо. Більшість «нестабільних» тестів на спільному стенді насправді падають через дані: хтось змінив того самого користувача, закінчився товар на складі, промокод уже використаний. Друга причина — право: персональні дані з продакшну в тестовому середовищі під дією GDPR потребують законної підстави й захисту, тому дамп проду «як є» майже завжди поганий варіант.

Why it matters. Most "flaky" tests on a shared environment actually fail because of data: someone changed the same user, a product ran out of stock, a promo code was already used. The second reason is legal: under GDPR, personal data from production in a test environment needs a lawful basis and protection, so a raw production dump is almost always a bad option.

Приклад. Команда з п'яти тестувальників і нічною регресією ділить один стенд. Рішення в таблиці нижче: кожен тест створює свого користувача через API з унікальним префіксом прогону, довідники завантажуються один раз і лише читаються, копія проду для аналітики масується до потрапляння на стенд, а нічна задача видаляє все з префіксом старших за добу прогонів.

Example. A team of five testers and a nightly regression share one environment. The solution is in the table below: each test creates its own user through the API with a unique run prefix, reference data is loaded once and only read, the production copy for analytics is masked before it reaches the environment, and a nightly job deletes everything with a prefix from runs older than a day.

Підводні камені. Залежність тесту від даних, створених іншим тестом, — порядок запуску зміниться, і все посиплеться. Маскування, яке ламає зв'язки: замінили email у таблиці users, але не в orders. Відсутність прибирання: за пів року стенд гальмує від мільйона тестових замовлень.

Pitfalls. A test relying on data created by another test — change the run order and everything collapses. Masking that breaks relationships: the email was replaced in users but not in orders. No cleanup: within six months the environment crawls under a million test orders.

Ситуація. Розробник каже: «Я додав експорт замовлень в Excel, глянь до кінця дня». Документації, історії в трекері чи макетів немає. Інтерв'юер перевіряє, чи ти не відмовишся тестувати і не тестуватимеш навмання.

Situation. A developer says: "I added an export of orders to Excel, have a look by the end of the day". There is no documentation, no ticket history and no mockups. The interviewer is checking that you neither refuse to test nor test at random.

Що роблю. Перше — збираю неявні оракули: 15 хвилин розмови з розробником і PO про мету (хто і навіщо експортуватиме), схожі функції в нашому продукті (експорт клієнтів уже є), поведінку конкурентів, загальні стандарти (формат дат, кодування, ліміти Excel на рядки). Друге — записую припущення в журнал і надсилаю PO на підтвердження: так мовчазні рішення стають явними. Третє — тестую дослідницькими сесіями за чартерами, а знайдене перетворюю на чекліст, який стане основою майбутньої регресії.

What I do. First, I gather implicit oracles: 15 minutes with the developer and the PO about the goal (who will export and why), similar features in our product (a customer export already exists), competitors' behaviour and general standards (date format, encoding, Excel row limits). Second, I write my assumptions into a log and send it to the PO for confirmation: that way silent decisions become explicit. Third, I test in exploratory sessions with charters, and turn what I find into a checklist that becomes the basis of future regression.

Результат. Журнал нижче показує, як припущення перетворюються на рішення. Два з п'яти PO виправив — без журналу це були б «баги», які насправді ніхто не просив, або навпаки, пропущені вимоги.

Outcome. The log below shows assumptions turning into decisions. The PO corrected two of the five — without the log they would have been "bugs" nobody actually asked for or, the other way round, missed requirements.

Підводні камені. Мовчки тестувати за власними уявленнями, а потім сперечатися про кожен баг. Відмовитись до появи повного ТЗ — у реальних проєктах його може не бути ніколи. Забути повернути підтверджені припущення в документацію або в критерії приймання.

Pitfalls. Silently testing against your own ideas and then arguing over every bug. Refusing until a full specification appears — in real projects it may never come. Forgetting to put the confirmed assumptions back into the documentation or the acceptance criteria.

Ситуація. Збірка прийшла о 16:00, реліз завтра о 10:00, регресія вручну займає два дні. Інтерв'юер хоче почути не «працюватиму вночі», а план пріоритезації і чесну комунікацію ризику. Рішення про реліз ухвалює бізнес; задача QA — дати йому точну картину.

Situation. The build arrived at 16:00, the release is tomorrow at 10:00, and manual regression takes two days. The interviewer wants to hear not "I will work all night" but a prioritisation plan and honest communication of risk. The business makes the release decision; QA's job is to give it an accurate picture.

Порядок. Перші 30 хвилин — smoke: збірка розгорнулась, логін, головний сценарій працює; якщо ні, далі тестувати немає сенсу. Потім зміни цього релізу: що саме змінено, за diff і тікетами, і що від цього залежить. Далі «грошові» й критичні шляхи: реєстрація, оплата, оформлення замовлення. Потім області з історією дефектів. Автотести запускаю паралельно з першої хвилини. Останнім іде все, що має низький ризик, — і саме це свідомо не встигаємо.

Order. The first 30 minutes are smoke: the build deployed, login works, the main scenario runs; if not, there is no point testing further. Then this release's changes: what exactly changed, from the diff and the tickets, and what depends on it. Next the money and critical paths: sign-up, payment, checkout. Then areas with a defect history. Automated checks run in parallel from the first minute. Last comes everything low-risk — and that is exactly what we knowingly do not reach.

Комунікація. Увечері надсилаю PO коротке повідомлення: що перевірено, що ні, які відомі дефекти лишились і яка моя рекомендація. Варіанти теж пропоную: реліз з вимкненою через feature flag ризиковою частиною, реліз зі швидким моніторингом після запуску або перенесення на день.

Communication. In the evening I send the PO a short message: what was checked, what was not, which known defects remain and what I recommend. I also offer options: release with the risky part switched off behind a feature flag, release with close monitoring right after launch, or a one-day postponement.

Підводні камені. Мовчки скоротити тестування і сказати «все ок». Взяти на себе рішення про реліз замість бізнесу. Тестувати в порядку тест-сьюта, а не за ризиком, і до ранку не дійти до оплати.

Pitfalls. Silently cutting testing and saying "all good". Taking the release decision instead of the business. Testing in test-suite order rather than by risk and never reaching payment before morning.