vyvchy
    Теми розділу

    01 · Основи тестування

    Статичне тестування і рев'ю

    Зміст

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

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

    Статичне vs динамічне тестування

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

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

    Є і глибша відмінність — у тому, що саме знаходиться. Динамічний тест бачить (failure) — зовнішній прояв проблеми: неправильну цифру на екрані, помилку 500. Щоб дістатися від відмови до самого дефекту в коді, потрібен ще дебаг. Статичне тестування знаходить дефект (defect) безпосередньо: ти дивишся прямо в суперечливе речення вимоги чи проблемний рядок коду, і шукати більше нічого не треба. Ланцюжок error → defect → failure ми розбирали у базових поняттях.

    КритерійСтатичнеДинамічне
    Виконання кодуНіТак
    Що потрібноАртефакт, який можна прочитатиБілд, середовище, дані
    Що знаходитьДефект напрямуВідмову, дефект — після дебагу
    Коли доступнеЗ перших днів проєктуКоли є що запустити
    Хто/що виконуєЛюди (рев'ю) та інструменти (статичний аналіз)Люди й автотести на працюючій системі

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

    Що перевіряють без запуску коду

    Майже будь-який робочий продукт (work product), який можна прочитати:

    • Вимоги, user story, acceptance criteria — найвигідніший обʼєкт: дефект тут ще нічого не коштує виправити (структуру й атрибути хороших вимог розбираємо у главі про вимоги);
    • архітектура і дизайн — схеми, описи інтеграцій, контракти API;
    • код — класичне код-рев'ю в pull request;
    • тестові артефакти — тест-плани, тест-кейси і чеклисти: свіже око колеги ловить пропущені негативні сценарії та кроки, очевидні лише автору;
    • документація і конфігурація — інструкції з розгортання, CI-конфіги, юзер-гайди.

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

    Статичне тестування

    Рев'ю — виконують люди

    Статичний аналіз — виконують інструменти

    Неформальне рев'ю

    Walkthrough

    Технічне рев'ю

    Інспекція

    Лінтери

    Компілятор, перевірка типів

    Сканери безпеки й залежностей

    Статичне тестування

    Рев'ю — виконують люди

    Статичний аналіз — виконують інструменти

    Неформальне рев'ю

    Walkthrough

    Технічне рев'ю

    Інспекція

    Лінтери

    Компілятор, перевірка типів

    Сканери безпеки й залежностей

    Типи рев'ю: від коментаря в PR до інспекції

    ISTQB виділяє чотири типи рев'ю за зростанням формальності. Розрізняються вони не «суворістю обличчя», а трьома речами: хто веде процес, чи обовʼязкова індивідуальна підготовка і наскільки задокументований результат.

    Неформальне рев'ю (informal review) — без визначеного процесу і обовʼязкового протоколу. Попросив колегу глянути тест-кейси, кинув драфт вимоги в чат, отримав коментар у PR — це воно. Найдешевший і на практиці найпоширеніший тип: у більшості команд саме такі рев'ю переважають.

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

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

    (inspection) — найформальніший тип. Повний визначений процес, чеклисти і правила, чітко розділені ролі (автор не може бути ані модератором, ані ), обовʼязкова підготовка, формальний протокол і збір метрик. Головна ціль — знайти максимум дефектів; додаткова — покращити сам процес розробки, аналізуючи, звідки дефекти беруться.

    НеформальнеWalkthroughТехнічне рев'юІнспекція
    Хто ведебудь-хтоавторфасилітаторфасилітатор
    Підготовка заздалегідьнінеобовʼязковаобовʼязковаобовʼязкова
    Документований результатнеобовʼязковийзалежить від цілітактак, формальний
    Головна цільшвидкий фідбекспільне розуміння, навчанняконсенсус, технічне рішеннямаксимум дефектів, метрики

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

    Сам процес рев'ю (за ISO/IEC 20246, на якому базується ISTQB) складається з пʼяти активностей: планування → ініціація → індивідуальне рев'ю → обговорення знахідок → виправлення і звітування. Індивідуальне рев'ю виділене недарма: найбільше дефектів знаходять саме тоді, коли кожен рецензент читає артефакт наодинці, у своєму темпі. Звичка «прочитаю по діагоналі прямо на зустрічі» вбиває головну цінність процесу.

    Звичне код-рев'ю у pull request на цій шкалі — неформальне рев'ю, іноді з елементами технічного (обовʼязковий апрув, чеклист у шаблоні PR). Знати про це корисно на співбесіді: питання «які типи рев'ю бували у вас на проєкті» не має заганяти тебе в ступор через те, що інспекцій за Фаганом ти не бачив. Мало хто бачив — у сучасних Agile-командах переважають неформальні рев'ю і walkthrough, а формальна інспекція здебільшого лишилася в регульованих доменах (авіоніка, медицина).

    Статичний аналіз: коли артефакт читає машина

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

    • лінтери (ESLint) — підозрілі патерни й порушення домовленостей: невикористані змінні, недосяжний код, небезпечні конструкції;
    • перевірка типів (компілятор TypeScript, tsc) — виклик неіснуючого методу, неправильний тип аргументу, звертання до поля, якого може не бути;
    • сканери безпеки й залежностей — відомі вразливості у сторонніх пакетах, секрети, закомічені в репозиторій;
    • аналізатори складності (SonarQube тощо) — метрики на кшталт цикломатичної складності, задубльований код.

    Для AQA це не абстракція: статичний аналіз щодня рятує тестовий код. Класичний приклад — забутий await у Playwright:

    test('користувач бачить дашборд після логіну', async ({ page }) => {
  page.goto('/login'); // забутий await: тест побіжить далі, не дочекавшись переходу
  await page.getByLabel('Email').fill('user@example.com');
});

    Динамічно цей дефект проявиться як — падатиме через раз, і причину шукатимуть годинами. Статично його ловить правило @typescript-eslint/no-floating-promises прямо в редакторі, підкресливши рядок ще до першого запуску. Це найкоротша ілюстрація цінності статики: та сама проблема, знайдена за секунду замість години.

    Лінтер і перевірка типів зазвичай вбудовані у : код, який їх не проходить, просто не потрапляє в основну гілку (як це влаштовано — у розділі про Git і CI/CD).

    Дві межі тут варто знати точно, бо їх легко переказати неточно. Перша: різницю між warn і error дока ESLint означує через exit-код, а не через тон повідомлення. Дослівно: «"warn" or 1 - turn the rule on as a warning (doesn’t affect exit code)» проти «"error" or 2 - turn the rule on as an error (exit code is 1 when triggered)». Саме тому гейт у пайплайні будують на error: попередження пайплайн не зупиняє. Друга: рекомендація ставити error у CI подана з модальністю typically, а не як вимога — «Rules are typically set to "error" to enforce compliance with the rule during continuous integration testing, pre-commit checks, and pull request merging because doing so causes ESLint to exit with a non-zero exit code». Тобто це усталена практика, а не припис: warn дока радить свідомо — коли правило тільки вводять, коли воно ловить не потенційну помилку збірки чи виконання, або коли не може впевнено сказати, що проблема справді є.

    Чому статика — найдешевша

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

    Статичне тестування — найраніше з можливих, і в цьому його економіка:

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

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

    Роль QA у рев'ю вимог

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

    • Неоднозначність. «Пошук має працювати швидко» — це скільки? 200 мс чи 2 секунди? На якому обсязі даних? Поки немає числа, вимогу неможливо ані реалізувати однозначно, ані перевірити.
    • Неповнота. «Користувач може завантажити файл» — які формати? Який максимальний розмір? Що побачить користувач при перевищенні? Кожне питання без відповіді — майбутній баг-репорт зі статусом «а це взагалі баг чи так задумано?».
    • Суперечності. У сторі написано «неактивні акаунти видаляються через 90 днів», а в сусідній — «історія замовлень зберігається завжди». Обидві не можуть бути правдою одночасно.
    • (testability). Головний фільтр QA: якщо до вимоги неможливо придумати перевірку з очікуваним результатом — вимога не готова. Це практичний сенс критеріїв Definition of Ready у Scrum-процесі.

    Кожне таке питання, поставлене до початку розробки, — це дефект, який не був написаний: його не треба ловити тестами, репортити, чинити й перевіряти. Формат хороших acceptance criteria, які роблять вимогу перевірною за побудовою, розбираємо у главі про вимоги та user story.

    І правило гігієни, спільне для будь-якого рев'ю: коментарі стосуються артефакту, а не людини. «У кроці 3 не описано поведінку при таймауті» працює; «ти знову написав неповний кейс» — руйнує довіру, і наступного разу тобі просто не принесуть драфт на рев'ю.

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

    • Виглядає як «статичне тестування — це тестування статичних сторінок або коду, який не змінюється», а насправді «статичне» стосується способу перевірки: артефакт не виконується. Сам артефакт може змінюватися хоч щодня.
    • Виглядає як «рев'ю — це синонім код-рев'ю», а насправді рев'ювлять будь-який робочий продукт: вимоги, архітектуру, тест-кейси, документацію. Для QA рев'ю вимог важливіше за рев'ю коду.
    • Виглядає як «лінтер зелений — значить, код правильний», а насправді статичний аналіз бачить форму, а не поведінку: він зловить забутий await, але не скаже, що тест перевіряє не той інваріант.
    • Виглядає як «walkthrough та інспекція — однакові зустрічі з різними назвами», а насправді walkthrough веде автор із ціллю досягти спільного розуміння, а інспекцію — фасилітатор за формальним процесом із ціллю знайти максимум дефектів.
    • Виглядає як «QA підключається, коли зʼявляється білд», а насправді найдешевші знахідки QA робить до першого рядка коду — питаннями до вимог.

    Підсумок

    • Статичне тестування перевіряє артефакти без виконання коду і тому доступне з першого дня проєкту; воно знаходить дефект напряму, тоді як динамічне бачить відмову, від якої до дефекту ще треба дійти дебагом.
    • Рев'ювлять будь-який читабельний робочий продукт — вимоги, код, тест-кейси, архітектуру; рев'ю тест-кейсів — теж статичне тестування.
    • Чотири типи рев'ю за зростанням формальності: неформальне → walkthrough (веде автор, ціль — спільне розуміння) → технічне рев'ю (веде фасилітатор, ціль — консенсус) → інспекція (формальний процес, ціль — максимум дефектів).
    • Статичний аналіз — це статичне тестування інструментами: лінтери, перевірка типів, сканери; для AQA це щоденний захист тестового коду від дефектів на кшталт забутого await.
    • Статика — найдешевша точка знаходження дефекту, бо не потребує білда й середовища, а дефект у вимозі, знайдений на рев'ю, коштує одне виправлене речення. Але вона доповнює динамічне тестування, а не замінює його.

    Можливі питання

    • «Чим статичне тестування відрізняється від динамічного?» — базове питання-фільтр. Очікувана відповідь: без виконання коду vs із виконанням, плюс наслідки — статика доступна раніше і знаходить дефект напряму. Сильний кандидат додає приклад дефекту, який ловиться лише статикою (суперечність у вимогах).
    • «Які типи рев'ю знаєш?» — чотири типи за формальністю. Інтервʼюер дивиться, чи розрізняєш walkthrough й інспекцію (хто веде і навіщо), а не просто перелічуєш назви.
    • «Що таке статичний аналіз? Чим відрізняється від рев'ю?» — рев'ю виконують люди, аналіз — інструменти. Плюс балів — конкретика зі свого стека: ESLint, перевірка типів TypeScript.
    • «Навіщо тестувальнику брати участь у рев'ю вимог?» — тут перевіряють зрілість: очікують аргумент про вартість дефекту і тестопридатність, а не «бо так написано в процесі».
    • «Наведи приклад, коли рев'ю зекономило команді час» — питання на практичний досвід. Годиться навіть маленький кейс: питання на рефайнменті, яке виявило неузгодженість, або коментар у PR колеги, який зловив пропущений негативний сценарій. Інтервʼюер слухає, чи є за теорією реальна звичка.

    Джерела

    Статичне vs динамічне тестування

    • ISTQB CTFL Syllabus v4.0 — розділ 3: статичне тестування не виконує обʼєкт і знаходить дефект напряму, тоді як динамічне бачить відмову; підходи ловлять різні класи дефектів.

    Що перевіряють без запуску коду

    • ISTQB CTFL Syllabus v4.0 — перелік робочих продуктів, до яких застосовне статичне тестування — від вимог і архітектури до коду, тестових артефактів і конфігурації.

    Типи рев'ю: від коментаря в PR до інспекції

    • ISTQB CTFL Syllabus v4.0 — чотири типи рев’ю за формальністю, ролі учасників і пʼять активностей процесу рев’ю, що спираються на ISO/IEC 20246.

    Статичний аналіз: коли артефакт читає машина

    • ISTQB CTFL Syllabus v4.0 — статичний аналіз як форма статичного тестування, яку виконують інструменти, і класи проблем, що ним ловляться.
    • ISTQB Glossary — канонічне означення static analysis — розбір артефакту без його виконання.
    • ESLint — Configure Rules — рівні off/warn/error, означені через exit-код, і модальність typically для рекомендації ставити error у CI.
    • typescript-eslint — no-floating-promises — правило, яке статично ловить забутий await — типовий дефект тестового коду.

    Чому статика — найдешевша

    • ISTQB CTFL Syllabus v4.0 — вигоди статичного тестування: раннє виявлення дефекту, коли виправлення найдешевше, і знахідки, яких динамічне тестування не дає в принципі.

    Роль QA у рев'ю вимог

    • ISTQB CTFL Syllabus v4.0 — класи дефектів, які ловляться в вимогах — неоднозначність, неповнота, суперечності, брак тестопридатності — і фактори успіху рев’ю, серед них — коментувати артефакт, а не людину.

    Відео до теми

    28. Статичні типи тестування. РецензуванняПопелюха 👾 Тестування ПЗISTQB Foundation 3. Статичне тестування.Попелюха 👾 Тестування ПЗ

    Пояснення

    «Поясни» працює з власним API-ключем Anthropic: запит іде з вашого браузера прямо до Anthropic.

    Свій API-ключ (BYOK)

    Вставте власний ключ Anthropic — пояснення працюватиме на реальній моделі. Ключ зберігається лише у вашому браузері (localStorage), нікуди не надсилається, крім api.anthropic.com, і не логується.

    Знайшли помилку?