Тестування, QA і QC: базові поняття

Зміст

«Чим QA відрізняється від QC?» — питання, з якого починається чи не кожна перша співбесіда на позицію тестувальника. І воно не формальне: за відповіддю видно, чи розумієш ти, за що тобі платитимуть. В індустрії ці терміни вживають недбало — у вакансії пишуть «QA Engineer», а мають на увазі людину, яка тестує; кажуть «баг», маючи на увазі то помилку в коді, то падіння на проді. Поки термінологія розмита, розмита і твоя роль.

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

Навіщо тестують: знайти дефекти чи дати впевненість

У тестування дві цілі, які на перший погляд суперечать одна одній.

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

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

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

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

Що таке якість і чому вона не зʼявляється наприкінці

Якість ПЗ — це не «відсутність багів». Стандарт ISO/IEC 25010 визначає якість як ступінь, у якому продукт задовольняє заявлені та неявні потреби зацікавлених сторін. Обидва слова важливі:

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

ISO/IEC 25010 розкладає якість продукту на характеристики: функціональна придатність, продуктивність, надійність, зручність використання (у редакції 2023 року — здатність до взаємодії, interaction capability), безпека, супроводжуваність, сумісність та інші. Практичний наслідок для тестувальника: «все працює за вимогами» — це лише одна грань. Продукт може проходити всі функціональні перевірки і бути нестерпно повільним, дірявим у безпеці чи незручним.

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

Тестування, QC і QA: хто де живе

Тепер до головної термінологічної пари. Обидва поняття — частини управління якістю (quality management), але дивляться в різні боки:

Забезпечення якості (quality assurance, QA) — орієнтоване на процеси: як ми працюємо. Ідея: якщо процес налаштований правильно — вимоги ревʼюються, код проходить рев'ю, тести пишуться, реліз має чекліст — то і продукт на виході буде якісним. QA-активності: побудова процесів, стандарти, ретроспективи, аналіз причин дефектів (root cause analysis), щоб дефекти не зʼявлялися знову.
Контроль якості (quality control, QC) — орієнтований на продукт: що в нас вийшло. Це перевірка конкретного результату роботи: чи відповідає він вимогам і очікуванням.

Тестування — це форма контролю якості. Не синонім QA і навіть не його підмножина: за ISTQB, QA і QC — дві різні складові управління якістю, які працюють поруч.

Порівняння коротко:

Аспект	QA	QC (і тестування як його форма)
Фокус	Процес	Продукт
Мета	Запобігти дефектам	Виявити дефекти
Коли	Постійно, протягом усього циклу	Коли є що перевіряти
Приклад	Ввести обовʼязкове рев'ю вимог	Прогнати тести на білді

Чому ж тоді вакансії називаються «QA Engineer», якщо девʼять з десяти обовʼязків у них — тестування, тобто QC? Історично склалось, і сперечатися з ринком безглуздо. Але розуміти різницю треба: коли тестувальник пропонує додати чекліст готовності фічі до передачі в тестування або розбирає на ретро, чому дефект прослизнув у прод, — у цей момент він справді робить QA, працює з процесом. Коли клікає по стенду чи пише автотест — робить QC. Досвідчені інженери роблять і те, і те, тому назва «QA» поступово стає чесною.

Верифікація і валідація

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

Верифікація (verification) — перевірка, що продукт відповідає специфікованим вимогам. Питання: «чи правильно ми зробили продукт?» (are we building the product right). Еталон — документ: вимога, специфікація, дизайн.
Валідація (validation) — перевірка, що продукт відповідає реальним потребам користувачів і взагалі придатний для свого призначення. Питання: «чи правильний продукт ми зробили?» (are we building the right product). Еталон — потреба, а не папірець.

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

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

Error, defect, failure: ланцюжок

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

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

Ключовий нюанс, який перевіряють на співбесідах: зв'язок не автоматичний в обидва боки.

Дефект може роками не проявлятися — код з вадою просто не виконується на типових даних. Мінімальний приклад:

// Вимога: «пароль — мінімум 8 символів».
// Розробник помилився (error) і написав строгу нерівність:
function isPasswordLongEnough(password: string): boolean {
  return password.length > 8; // дефект: має бути >= 8
}

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

test('пароль із рівно 8 символів приймається', async ({ page }) => {
  await page.getByLabel('Пароль').fill('Qwerty1!'); // рівно 8
  await page.getByRole('button', { name: 'Зареєструватися' }).click();
  await expect(page.getByText('Пароль закороткий')).toBeHidden();
});

І навпаки: відмова можлива без дефекту у вашому коді — впав мережевий запит, закінчилось місце на диску, третій сервіс віддав 500 (що означають статус-коди — у главі про HTTP-статуси). Сюди ж — хибні спрацювання самих тестів: тест може впасти через власний дефект або нестабільне середовище (false positive) чи, гірше, не впасти там, де дефект є (false negative). Тому «тест упав» ще не означає «знайдено дефект застосунку» — спочатку розберися, чия це відмова.

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

Вартість дефекту: чим пізніше, тим дорожче

Один і той самий дефект коштує по-різному залежно від того, коли його знайшли:

Етап виявлення	Хто зазвичай знаходить	Що коштує виправлення
Вимоги / дизайн	Рев'ю вимог, QA на рефайнменті	Переписати кілька речень у документі
Розробка	Розробник, юніт-тести, код-рев'ю	Поправити код до мержа
Тестування	Тестувальник на стенді	Баг-репорт → фікс → ретест → шматок регресії
Прод	Користувачі, підтримка, моніторинг	Позаплановий hotfix, зіпсовані дані, підтримка, репутація, іноді прямі збитки

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

Точні множники з підручників («у 10 разів на кожному етапі», «у 100 разів на проді») походять зі старих досліджень часів Бема і сучасними даними підтверджуються нерівно — цитувати їх як закон природи не варто. Але напрямок залежності сумнівів не викликає, і саме він стоїть за принципом раннього тестування (одним із семи принципів) і за модним словом shift-left: залучати тестування якомога раніше — до вимог і дизайну, а не після «код готовий». Найдешевше дефекти ловляться взагалі без запуску коду — на рев'ю вимог і статичному аналізі (про це — глава про статичне тестування).

Роль тестувальника в команді

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

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

Окрема тема — незалежність тестування. Автор коду перевіряє свій код поблажливо — не з лінощів, а тому, що дивиться на нього крізь ті самі припущення, з якими писав: якщо помилка в припущенні, він її не побачить. Тому існують ступені незалежності: перевіряє сам автор → перевіряють колеги з його команди (інший розробник чи тестувальник) → перевіряють тестувальники поза командою автора, але в межах організації → перевіряють зовнішні тестувальники поза організацією. Що більша незалежність, то більше «чужих» дефектів знаходиться, але то довша комунікація. В Agile-командах баланс зазвичай такий: тестувальник вбудований у команду розробки (whole-team approach), але зберігає незалежний погляд — він не писав цей код і не закоханий у нього.

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

Типові помилки

Виглядає як «QA і тестування — синоніми», а насправді тестування — форма контролю якості (QC), а QA — робота з процесами. Кажеш «я забезпечую якість», а описуєш прогін тест-кейсів — інтервʼюер це чує.
Виглядає як «тестування гарантує якість», а насправді тестування лише дає інформацію про неї. Гарантувати відсутність дефектів неможливо в принципі — чому саме, розбираємо у семи принципах тестування.
Виглядає як «тест упав — знайшли баг», а насправді відмова могла прийти з середовища, тестових даних чи дефекту самого тесту. Спершу зʼясуй, чия відмова, потім заводь дефект.
Виглядає як «дефектів не знайдено — продукт якісний», а насправді дефект може просто спати, бо його умови не настали, а неявні потреби (швидкість, зручність, безпека) ти взагалі не перевіряв.
Виглядає як «валідація — це перевірка полів форми», а насправді перевірка введення (input validation) — це функціональність продукту, а валідація в термінах якості — перевірка, що продукт відповідає потребам користувачів. Однакове слово, різні речі.
Виглядає як «за якість відповідає відділ QA», а насправді якість закладається всією командою на кожному етапі, а тестування її вимірює. Команда з цапом-відбувайлом якісного продукту не робить.

Підсумок

Тестування дає інформацію про якість і знижує ризики — воно не створює якість і не може гарантувати відсутність дефектів.
QA — про процеси, QC — про продукт; тестування — форма QC; разом вони складають управління якістю. У вакансіях «QA» історично означає переважно QC-роботу.
Верифікація — «чи правильно зробили продукт» (відповідність вимогам); валідація — «чи правильний продукт зробили» (відповідність потребам).
Ланцюжок error → defect → failure: людина помиляється, у продукті зʼявляється дефект, за певних умов він проявляється відмовою. Дефект може не проявлятися роками; відмова буває і без дефекту в коді.
Чим пізніше знайдено дефект, тим дорожче виправлення — тому тестування починається з вимог, а за якість відповідає вся команда, не лише тестувальник.

Що питають на співбесіді

«Навіщо потрібне тестування, якщо розробники й так перевіряють свій код?» Інтервʼюер дивиться, чи назвеш більше однієї цілі (пошук дефектів + впевненість + інформація для рішень) і чи згадаєш незалежність погляду: автор коду сліпий до власних припущень.
«Чим QA відрізняється від QC? А тестування — це що з них?» Перевіряють не завчену фразу, а розуміння фокусів: процес проти продукту, запобігання проти виявлення. Сильна відповідь містить приклад QA-активності (рев'ю процесу, root cause analysis) і чесне «моя щоденна робота — переважно QC».
«Що таке верифікація і валідація? Наведи приклад, коли верифікація пройдена, а валідація — ні.» Без прикладу відповідь вважай неповною: саме приклад показує, що ти розумієш різницю, а не зазубрив означення.
«Що таке баг? Чим дефект відрізняється від відмови?» Дивляться на точність термінології і на розуміння, що не кожен дефект проявляється і не кожна відмова — від дефекту в коді. Бонус — згадати false positive/false negative самих тестів.
«Хто відповідає за якість продукту?» Питання-пастка. «Тестувальник» або «відділ QA» — слабка відповідь; сильна — «вся команда, а тестування дає вимірювання», з поясненням, чому інакше не працює.
«Коли дефект виправляти найдешевше і що з цього випливає для процесу?» Чекають на логіку подорожчання за етапами і висновок про раннє залучення тестування (shift-left), а не завчені множники.

Джерела

ISTQB CTFL Syllabus v4.0 — глава покриває розділ 1 «Fundamentals of Testing» (цілі тестування, тестування vs QA, error/defect/failure), зокрема 1.5.3 (незалежність тестування).
Глосарій ISTQB — канонічні означення термінів: testing, quality assurance, quality control, verification, validation, error, defect, failure.
ISO/IEC 25010 — модель якості продукту — характеристики якості ПЗ, з яких видно, що якість ширша за «відповідність функціональним вимогам».

Навіщо потрібне тестування, якщо розробники й так перевіряють свій код?

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

Чи може тестування гарантувати якість продукту?

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

Чим тестування відрізняється від дебагу (debugging)?

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

Що таке якість ПЗ? Це те саме, що «відсутність багів»?

Ні. За ISO/IEC 25010 якість — це ступінь, у якому продукт задовольняє заявлені та неявні потреби зацікавлених сторін. Заявлені — те, що записано у вимогах; неявні — те, чого ніхто не писав, бо «і так зрозуміло»: експортований PDF відкривається, кирилиця не перетворюється на кракозябри, операція не кладе сервер. Стандарт розкладає якість на характеристики: функціональна придатність, продуктивність, надійність, зручність використання, безпека, супроводжуваність, сумісність. Практичний наслідок: продукт може проходити всі функціональні перевірки і при цьому бути нестерпно повільним чи дірявим у безпеці — формально «без багів», але неякісним. Тому «все працює за вимогами» — лише одна грань якості.

Чим QA відрізняється від QC? А тестування — це що з них?

Обидва — складові управління якістю (quality management), але дивляться в різні боки. Забезпечення якості (quality assurance, QA) орієнтоване на процеси — «як ми працюємо»: якщо вимоги ревʼюються, код проходить рев'ю, реліз має чекліст, то і продукт на виході буде якісним; мета — запобігти дефектам. Контроль якості (quality control, QC) орієнтований на продукт — «що в нас вийшло»: перевірка конкретного результату проти вимог і очікувань; мета — виявити дефекти. Тестування — це форма контролю якості: не синонім QA і навіть не його підмножина. Сильна відповідь містить приклад QA-активності — root cause analysis дефектів, введення обовʼязкового рев'ю вимог — і чесне визнання: «моя щоденна робота — переважно QC».

Чому посада називається «QA Engineer», якщо девʼять з десяти обовʼязків — тестування?

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

Що таке верифікація і валідація? Наведи приклад, коли верифікація пройдена, а валідація — ні

Верифікація (verification) — перевірка, що продукт відповідає специфікованим вимогам: «чи правильно ми зробили продукт?»; еталон — документ. Валідація (validation) — перевірка, що продукт відповідає реальним потребам користувачів і придатний для свого призначення: «чи правильний продукт ми зробили?»; еталон — потреба, а не папірець. Класичний приклад: вимога каже «пароль — мінімум 12 символів зі спецсимволом і цифрою, зміна щомісяця», продукт реалізує це дослівно — верифікація пройдена. А користувачі пишуть пароль на стікері й клеять на монітор, бо запамʼятати неможливо: валідація провалена — потребу «безпечний і придатний до життя вхід» продукт не задовольняє. Без прикладу відповідь вважається неповною: саме приклад показує, що ти розумієш різницю, а не зазубрив означення. І нюанс, який плутають: перевірка введення (input validation) у формі — це функціональність продукту, а не валідація в термінах якості; однакове слово, різні речі.

Що таке error, defect і failure? Чому «баг» — неточне слово?

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

Чи може дефект роками не проявлятися? А відмова статися без дефекту в коді?

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

Що таке false positive і false negative у контексті автотестів?

False positive — тест упав, хоча дефекту в застосунку немає: причина у дефекті самого тесту, нестабільному середовищі чи кривих тестових даних. False negative — тест не впав там, де дефект є: перевірки не покривають зламану поведінку. Другий випадок гірший: false positive дратує і краде час на розбір, а false negative дає хибну впевненість — команда релізить, думаючи, що все зелене чесно. Тому розбір червоного тесту завжди починається з питання «чия це відмова: застосунку, тесту чи середовища», а зелений прогін не звільняє від думки про те, що саме тести взагалі перевіряють.

Що ти описуєш у баг-репорті — дефект чи відмову?

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

Коли дефект найдешевше виправляти і що з цього випливає для процесу?

Найдешевше — на етапі вимог і дизайну, найдорожче — на проді, і між ними вартість зростає з кожним етапом. Механізм простий: поки дефект живе у вимозі — це текст, який переписується за хвилину; коли на криву вимогу написали код, тести й документацію — виправляти треба все разом; на проді додаються наслідки — зіпсовані дані, потік звернень у підтримку, позаплановий hotfix, репутація. Точні множники з підручників («у 10 разів на кожному етапі») походять зі старих досліджень і цитувати їх як закон природи не варто — але напрямок залежності сумнівів не викликає. Звідси принцип раннього тестування і shift-left: залучати тестування до вимог і дизайну, а не після «код готовий». Найдешевші дефекти ловляться взагалі без запуску коду — на рев'ю вимог і статичному аналізі.

Хто відповідає за якість продукту?

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

Що таке незалежність тестування і які в неї ступені?

Незалежність — це дистанція між автором робочого продукту і тим, хто його перевіряє. Автор перевіряє свою роботу крізь ті самі припущення, з якими її створював, тому власні сліпі зони не бачить. Ступені зростання незалежності: перевіряє сам автор → колеги з його команди (інший розробник чи тестувальник) → тестувальники поза командою автора, але в межах організації → зовнішні тестувальники поза організацією. Компроміс: що більша незалежність, то більше «чужих» дефектів знаходиться, але то довша комунікація. В Agile-командах баланс зазвичай такий: тестувальник вбудований у команду розробки (whole-team approach), але зберігає незалежний погляд — він не писав цей код і не закоханий у нього.

Чи вирішує тестувальник, випускати реліз чи ні?

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

Три кейси на базові поняття в дії: тиждень тестувальника, розкладений на QA і QC; діагностика червоного тесту через ланцюжок error → defect → failure; і розбір однієї вимоги на верифікацію та валідацію. Скрізь — питання, яке треба собі поставити, і чому.

Кейс 1. Тиждень тестувальника: де тут QA, а де QC

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

Активність	QA чи QC	Чому
Прочитав вимоги нової фічі, знайшов суперечність між двома пунктами	QC	Перевірка конкретного робочого продукту — документа вимог. Це теж тестування, просто статичне і найдешевше
Прогнав регресію на білді перед релізом	QC	Перевірка продукту: чи нічого не розвалилось
Написав автотест на новий ендпоінт	QC	Автотест — той самий контроль якості, виконуваний швидше й частіше
На ретро розібрали, чому дефект прослизнув у прод (root cause analysis)	QA	Робота з процесом: мета — щоб дефекти такого класу не зʼявлялися знову
Запропонував чекліст готовності фічі до передачі в тестування	QA	Зміна того, як команда працює, а не перевірка конкретного результату

Що з цього взяти:

Рев'ю вимог конкретної фічі — QC, а введення обовʼязкового рев'ю вимог для всіх фіч — QA. Один і той самий предмет, різний фокус: перевірити результат проти покращити процес.
«Я роблю QA» на співбесіді звучить чесно, лише якщо в тижні є права колонка з обома значеннями. Дев'ять з десяти активностей тестувальника — QC, і це нормально; QA-моменти — ретро, чеклісти, аналіз причин.

Кейс 2. Тест почервонів: дефект, відмова чи ні те, ні інше

Вимога: «безкоштовна доставка для замовлень від 1000 грн». Розробник поспішив (це помилка, error) і написав строгу нерівність — у коді оселився дефект:

// Вимога: «безкоштовна доставка від 1000 грн», тобто >= 1000
function hasFreeShipping(orderTotal: number): boolean {
  return orderTotal > 1000; // дефект: рівно 1000 доставку не отримає
}

Дефект статичний: на замовленнях у 999 і 1500 грн усе працює, він «спить». Відмову провокує тест на граничне значення:

test('замовлення рівно на 1000 грн отримує безкоштовну доставку', async ({ page }) => {
  await addItemsForTotal(page, 1000); // кошик рівно на 1000
  await page.goto('/checkout');
  await expect(page.getByText('Доставка: безкоштовно')).toBeVisible();
});

Тест упав. Перш ніж заводити баг — зʼясувати, чия це відмова. Таблиця рішень:

Симптом	Діагноз	Дія
Відтворюється вручну: кошик на 1000 грн — доставка платна	Дефект застосунку	Баг-репорт: описуємо відмову (умови, кроки), а не здогадку «зламана нерівність у коді»
Вручну працює, падає лише тест	Дефект тесту (false positive)	Лагодимо тест: фікстуру, локатор, очікування. Баг не заводимо
Впало пів сюїти, стенд щойно деплоївся, у відповідях `500`-ті	Відмова середовища	Переконатися, що середовище піднялося, перезапустити. Баг на застосунок не заводимо
Тест зелений, а підтримка отримує скарги на платну доставку при 1000 грн	False negative	Ревізія перевірок: тест не покриває граничне значення — найгірший випадок, бо дає хибну впевненість

Що з цього взяти:

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

Кейс 3. Одна вимога — дві перевірки: верифікація і валідація

Вимога з беклогу: «користувач може завантажити аватар; файл — JPG або PNG, до 2 МБ». Розкладаємо роботу тестувальника на два різні питання.

Верифікація: чи правильно ми зробили продукт? Еталон — текст вимоги, перевірки прямі:

JPG на 1 МБ — завантажується.
PNG рівно на 2 МБ — завантажується (границя!).
Файл на 2,1 МБ — відхиляється зі зрозумілим повідомленням, а не з 500.
GIF — відхиляється: формат не заявлений.

Усе зелене — верифікація пройдена: продукт відповідає специфікації.

Валідація: чи правильний продукт ми зробили? Еталон — потреба «поставити собі аватарку», і тут починаються питання, яких у вимозі немає:

Сучасний телефон знімає фото на 4–8 МБ. Типовий користувач обере фото з галереї — і впреться у ліміт 2 МБ без жодного шансу його виконати. Вимога реалізована точно, а потреба не задоволена: більшість реальних спроб завантаження закінчиться відмовою.
Неявні потреби, про які вимога мовчить: аватар не спотворюється при обрізанні, завантаження не висить хвилину, стара аватарка не залишається в кеші.

Що з цього взяти:

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

Цілі тестування

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

Якість

Можу дати визначення якості за ISO/IEC 25010 — ступінь задоволення заявлених і неявних потреб — і навести приклад неявної потреби, про яку вимоги мовчать.
Знаю, що якість ширша за функціональні вимоги: продуктивність, надійність, зручність, безпека, супроводжуваність — продукт «за вимогами» може бути неякісним.
Можу пояснити, чому якість не можна «дотестувати» наприкінці: вона закладається у вимогах, дизайні й коді, а тестування лише показує, скільки її вийшло.

QA vs QC

Знаю різницю QA vs QC: процес проти продукту, запобігти проти виявити — і можу навести приклад кожного (root cause analysis проти прогону тестів на білді).
Памʼятаю: тестування — форма QC, не синонім і не підмножина QA; разом вони складають управління якістю (quality management).
Можу пояснити, чому вакансія «QA Engineer» історично означає переважно QC-роботу — і в які моменти тестувальник усе ж робить справжній QA.

Верифікація і валідація

Знаю різницю: верифікація — «чи правильно зробили продукт» (еталон — специфікація), валідація — «чи правильний продукт зробили» (еталон — потреба користувача).
Маю готовий приклад «верифікація пройдена, валідація — ні»: пароль на 12 символів за специфікацією — і стікер на моніторі.
Розрізняю валідацію в термінах якості та перевірку введення (input validation): однакове слово, різні речі.

Error, defect, failure

Можу розказати ланцюжок: помилка (error) людини → дефект (defect) у робочому продукті → відмова (failure) під час виконання.
Знаю, що звʼязок не автоматичний: дефект може «спати» роками (умови не настали), а відмова буває без дефекту у вашому коді — середовище, мережа, сторонній сервіс.
Можу пояснити false positive і false negative автотестів і чому «тест упав» ще не означає «знайдено дефект застосунку».
Памʼятаю: у баг-репорті описую спостережену відмову (умови, кроки), а не здогадку про дефект у коді.

Вартість дефекту і роль тестувальника

Можу пояснити механізм подорожчання дефекту за етапами (вимоги → розробка → тестування → прод) і чому множники «×10/×100» — напрямок, а не закон природи.
Знаю, що з цього випливають раннє тестування і shift-left: найдешевші дефекти ловляться на рев'ю вимог, без запуску коду.
Знаю ступені незалежності тестування (автор → колеги з його команди → тестувальники поза командою в межах організації → зовнішні тестувальники) і компроміс «більше чужих дефектів проти довшої комунікації».
Можу пояснити, чому за якість відповідає вся команда, рішення про реліз ухвалює не тестувальник, а роль «поліції якості» ламає команду.