Сім принципів тестування

Назвіть сім принципів тестування. Звідки вони взялися?

Сім принципів зафіксовані в силабусі ISTQB CTFL (розділ 1.3): тестування показує наявність дефектів, а не їхню відсутність; вичерпне тестування неможливе; раннє тестування заощаджує час і гроші; дефекти скупчуються; тести зношуються (парадокс пестицидів); тестування залежить від контексту; хибність відсутності дефектів (absence-of-defects fallacy). Придумали їх не для сертифікації — це концентрат граблів, на які індустрія наступала десятиліттями, і кожен принцип — попередження про конкретну інженерну або управлінську помилку. Нюанс для співбесіди: дослівно всі сім вимагають рідко, частіше просять згадати кілька і пояснити своїми словами. Тому сильна відповідь — не зазубрений список, а кілька принципів із живим прикладом до кожного.

Що означає «тестування показує наявність дефектів, а не їхню відсутність»?

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

Як правильно звітувати за результатами тестування і чому не можна писати «багів немає»?

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

Чому неможливо протестувати все? А якщо дати необмежений час і людей?

Кількість комбінацій вхідних даних, станів і передумов зростає експоненційно, тому для будь-якої нетривіальної системи вичерпне тестування недосяжне — не «дуже важко», а недосяжне за будь-який реалістичний час. Форма з 10 незалежними чекбоксами — це вже 2^10, тобто 1024 комбінації; три дропдауни по 5 значень підіймають це до 128 000; одне текстове поле з довжинами, алфавітами, емодзі та спецсимволами робить простір значень практично нескінченним — і це без пар «браузер × ОС». Підступне продовження «а якщо дати необмежений час?» — перевірка, чи розумієте ви комбінаторну природу проблеми: не допоможе, бо простір комбінацій росте швидше за будь-який бюджет. Тому правильна відповідь — питання не в часі, а в стратегії вибірки: тестування — це завжди пріоритезація «що перевірити в першу чергу, щоб зловити найімовірніші та найдорожчі дефекти», а інструменти дає тест-дизайн і ризик-орієнтований підхід.

Що таке раннє тестування і зсув уліво (shift-left)? Чому дефект у вимогах дешевший за дефект на проді?

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

Що таке скупчення дефектів і як використовувати цей принцип у щоденній роботі?

Дефекти розподіляються по системі нерівномірно: невелика частина модулів зазвичай містить більшість багів — це відлуння принципу Парето, евристики «80/20». Скупчуються баги там, де складна логіка (розрахунок знижок, права доступу), де часті зміни, де зовнішні залежності (платіжні провайдери) і де легасі-код, якого всі бояться. У типовому e-commerce модуль чекауту з промокодами, доставкою і оплатою стабільно збирає більше дефектів, ніж усі статичні сторінки разом. Практичний наслідок: історія баг-трекера — це карта мінних полів; якщо в модулі знайшли п'ять багів, найімовірніше, там є шостий, і глибше тестувати треба саме там, а не рівномірно розмазувати зусилля. Цей принцип — один із головних аргументів при виборі обсягу регресії та пріоритетів у ризик-орієнтованому підході.

Отримали новий білд незнайомого продукту — де шукатимете баги насамперед?

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

Що таке парадокс пестицидів? Стикалися з ним на практиці?

Якщо ганяти ті самі тести раз за разом, вони перестають знаходити нові дефекти — як шкідники стають нечутливими до того самого пестициду; метафору запропонував Борис Бейзер, а в силабусі ISTQB CTFL 4.0 принцип називається «тести зношуються» (tests wear out). Механізм простий: тест знаходить дефект, дефект виправляють, тест назавжди стає зеленим — усі баги, які набір міг зловити, уже зловлено, а нові з'являються поза його покриттям. Роками зелена регресія починає давати хибне відчуття безпеки. Сильна відповідь на співбесіді містить приклад: автотест, який три роки додає в кошик той самий товар тим самим користувачем із захардкодженими даними, давно нічого не ловить — а баг на проді проходить повз зелений набір. Ліки: періодична ревізія набору, варіювання тестових даних, нові перевірки під нові фічі та знайдені на проді баги, дослідницьке тестування (exploratory testing) на додачу до скриптованих прогонів.

Парадокс пестицидів означає, що стабільну регресію треба викинути?

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

Що означає «тестування залежить від контексту»? Наведіть приклад.

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

Чому на питання «як би ти протестував X» варто починати з зустрічних питань?

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

Що таке хибність відсутності дефектів (absence-of-defects fallacy)?

Це хибне уявлення, що продукт без знайдених дефектів — успішний продукт; у попередніх версіях силабусу принцип називався absence-of-errors fallacy. Можна ідеально реалізувати й вилизати до нуля багів систему, яка не потрібна користувачам або розв'язує не ту проблему. Приклад: команда пів року тестувала систему бронювання, виправила всі знайдені дефекти, реліз пройшов бездоганно — а користувачі йдуть, бо бронювання займає дванадцять кроків, і конкурент робить те саме за два. Формально якість висока: продукт відповідає специфікації; фактично продукт провалився, бо специфікація не відповідала потребам. Тому тестувальник, який перевіряє лише відповідність вимогам і не дивиться на продукт очима користувача, закриває тільки половину роботи.

У чому різниця між верифікацією і валідацією і до якого принципу вона стосується?

Верифікація відповідає на питання «чи правильно ми зробили продукт» — відповідність вимогам і специфікації; валідація — «чи правильний продукт ми зробили» — відповідність реальним потребам користувача. Це серцевина сьомого принципу: absence-of-defects fallacy — це саме ситуація, коли верифікація пройдена ідеально, а валідація провалена. Продукт без багів, який розв'язує не ту проблему, — верифіковано, але не валідовано. Практичний наслідок: у хорошій команді QA бере участь у рев'ю вимог і має право сказати «це відповідає специфікації, але користувача заплутає» — тобто працює на обидві половини, а не лише звіряє поведінку з документом.

«Усі тести пройшли. Можемо релізити?» — як відповісти?

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

Як сім принципів працюють у зв'язці?

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

Три кейси, де сім принципів перестають бути теорією: релізний статус, який не бреше (принципи 1 і 7), таблиця рішень «куди спрямувати перші зусилля на новому білді» (принципи 2, 4 і 6) і ревізія зношеного Playwright-теста (принцип 5). Скрізь — що дивитися і чому.

Кейс 1. Релізний статус: два звіти про той самий прогін

П'ятниця, у релізному чаті менеджер питає: «Тестування закінчили? Релізимо?» Усі 500 кейсів на форму логіну зелені. Два варіанти відповіді QA.

Звіт, який бреше формулюванням:

Тестування завершено. Багів немає, можна релізити.

Звіт, який дає дані для рішення:

Прогін завершено: 500/500 кейсів пройшло.
Покрито: логін/логаут, відновлення пароля, валідація полів, блокування після 5 невдалих спроб.
НЕ покрито: одночасні сесії в кількох вкладках, паралельний логін з двох пристроїв.
Ризик: сценарії з кількома сесіями не перевірялися — у перевірених сценаріях дефектів не виявлено.

Що дивитися і чому:

• «Багів немає» — твердження, яке тестування не здатне довести в принципі. Зелений прогін каже лише, що перевірені сценарії не зловили дефектів (принцип 1). Коли за тиждень користувач змішає сесії у двох вкладках, перший звіт виглядатиме як провал QA, другий — як чесно задокументований ризик.
• Секція «НЕ покрито» — найцінніша частина звіту. Саме вона перетворює звіт з «сертифіката бездоганності» на підставу для рішення: менеджер бачить, який ризик приймає, релізячи зараз.
• Рішення про реліз лишається за бізнесом, і це нормально. QA дає картину ризиків, а не вердикт «можна/не можна»: релізити з відомим непокритим ризиком — легітимне рішення, релізити наосліп — ні (принципи 1 і 7 разом).

Кейс 2. Новий білд незнайомого продукту: таблиця рішень

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

Що дивитися і чому:

• Історія баг-трекера — перше, що варто відкрити на незнайомому проєкті. Це готова карта мінних полів: розподіл дефектів нерівномірний, і минулі скупчення — найкращий предиктор майбутніх.
• «Тут уже все виправили, шукаймо в інших місцях» — типова помилка. Звучить справедливо, але статистика каже протилежне (принцип 4): п'ять знайдених багів у модулі — аргумент шукати шостий там само.
• Рівномірно розмазати зусилля — теж рішення, але найгірше. Воно ігнорує і неможливість вичерпного тестування, і скупчення дефектів: вибірка має бути пріоритезованою за ризиком, а не «чесною».

Кейс 3. Ревізія зношеного автотеста: до і після

Автотест кошика три роки зелений і три роки не змінювався. За цей час на прод прорвався баг: після додавання другого товару лічильник кошика скидався в одиницю. Тест цього не зловив — і не міг: він перевіряє рівно один сценарій з рівно одними даними.

Було — класична ознака зношування, захардкоджені дані:

// Три роки той самий товар і той самий користувач — тест давно нічого не ловить
test('додавання товару оновлює лічильник кошика', async ({ page }) => {
  await page.goto('/product/42');
  await page.getByRole('button', { name: 'Додати в кошик' }).click();
  await expect(page.getByTestId('cart-count')).toHaveText('1');
});

Стало — той самий інваріант, але дані варіюються, а прод-баг закріплено окремим тестом:

// Варіюємо дані: різні типи товарів замість вічного /product/42
const products = [
  { id: '42', label: 'звичайний товар' },
  { id: '107', label: 'товар зі знижкою' },
  { id: '215', label: 'товар з мінімальним залишком' },
];

for (const { id, label } of products) {
  test(`додавання (${label}) оновлює лічильник кошика`, async ({ page }) => {
    await page.goto(`/product/${id}`);
    await page.getByRole('button', { name: 'Додати в кошик' }).click();
    await expect(page.getByTestId('cart-count')).toHaveText('1');
  });
}

// Новий тест під баг, що прорвався на прод: другий товар не скидає лічильник
test('другий товар збільшує лічильник, а не скидає його', async ({ page }) => {
  await page.goto('/product/42');
  await page.getByRole('button', { name: 'Додати в кошик' }).click();
  await page.goto('/product/107');
  await page.getByRole('button', { name: 'Додати в кошик' }).click();
  await expect(page.getByTestId('cart-count')).toHaveText('2');
});

Що дивитися і чому:

• Старий тест не видалено — його розширено. Принцип «тести зношуються» не вимагає викидати стабільну регресію: контроль «старе не зламалося» лишається, повторюваність тут перевага. Змінюється очікування: нових багів від старого сценарію не буде.
• Кожен прод-баг — це кандидат у постійний набір. Сценарій «два товари поспіль» тепер закріплено тестом: дефект, який одного разу прорвався повз покриття, більше не пройде тим самим шляхом.
• Варіювання даних — найдешевший спосіб відсунути зношування. Один цикл по трьох типах товарів коштує кілька рядків, а покриває стани, яких вічний /product/42 не бачив роками.
• Автотести не закривають питання повністю. Нові дефекти з'являються в сценаріях, яких скриптований набір не передбачив — тому ревізію доповнюють дослідницьким тестуванням (exploratory testing), а не лише новими скриптами.

Список і походження

• Можу назвати сім принципів тестування і знаю, що вони із силабусу ISTQB CTFL (розділ 1.3).
• Розумію, що інтерв'юер майже ніколи не хоче список — до кожного принципу маю живий приклад або побутову аналогію.

Межі тестування (принципи 1 і 2)

• Можу пояснити, чому тестування доводить наявність дефектів, але не їхню відсутність (формулювання Дейкстри).
• Знаю мову звітності: «у перевірених сценаріях дефектів не виявлено» плюс перелік перевіреного, а не «багів немає».
• Можу на пальцях показати комбінаторний вибух: 10 чекбоксів — це 2^10, тобто 1024 комбінації, а одне текстове поле робить простір практично нескінченним.
• Маю відповідь на підступне «а якщо дати необмежений час?» — не допоможе, простір комбінацій росте швидше за будь-який бюджет.
• Розумію, що тестування — завжди пріоритезована вибірка: питання не «скільки ще кейсів», а «що найризиковіше не покрито».

Раннє тестування (принцип 3)

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

Де живуть і як старіють баги (принципи 4 і 5)

• Розумію скупчення дефектів як відлуння принципу Парето («80/20») і знаю чотири фактори: складна логіка, часті зміни, зовнішні залежності, легасі.
• Використовую історію баг-трекера як карту мінних полів: п'ять багів у модулі — привід шукати там шостий, а не йти «в чисті» місця.
• Можу пояснити механізм парадоксу пестицидів (тест знайшов дефект → виправили → назавжди зелений, нові баги поза покриттям) і впізнаю ознаку зношеного автотесту — роками незмінні захардкоджені дані.
• Знаю ліки від зношування — ревізія набору, варіювання даних, нові сценарії під фічі та прод-баги, exploratory testing — і що стабільну регресію при цьому не викидають: для контролю «старе не зламалося» повторюваність — перевага.
• Знаю, що в CTFL 4.0 принцип називається «тести зношуються» (tests wear out), а метафора пестицидів — від Бориса Бейзера.

Контекст і цінність (принципи 6 і 7)

• Можу навести контрастні контексти: медичне ПЗ з аудитом і формальною документацією проти лендинга зі смоуком і чеклистом.
• Знаю, що переносити процес між проєктами треба свідомо: процес для банку задушить стартап, процес стартапу завалить банк.
• На питання «як би ти протестував X» починаю з уточнень: хто користувач, які ризики, скільки часу — відповідь без питань порушує шостий принцип.
• Можу пояснити absence-of-defects fallacy: нуль знайдених багів не означає успішний продукт — система може розв'язувати не ту проблему.
• Знаю різницю верифікації («чи правильно ми зробили продукт») і валідації («чи правильний продукт ми зробили») і до якого принципу вона прив'язана.
• Маю готову відповідь на пастку «усі тести пройшли — релізимо?»: вона б'є одразу по принципах 1 і 7, а рішення про реліз — це оцінка ризиків, а не колір прогону.