Основи QA: SDLC, STLC, види тестування, тестова піраміда

QA (Quality Assurance) — гарант якості ПЗ. У 2026 році QA-інженер не лише натискає кнопки, а й автоматизує, працює з API, читає SQL, інтегрує AI-інструменти. Junior QA — найдоступніший вхід в IT.

Хто такий QA-інженер

• Тестувальник ≠ хакер у фільмах. Це інженер, який:

  • Розуміє продукт
  • Шукає, де може зламатись
  • Документує помилки так, щоб розробник зрозумів і виправив
  • Автоматизує перевірки, які потім запускаються в CI

• Manual QA — ручне тестування (тести, чеклісти, баг-репорти)

• AQA (Automation QA) — пише код для автоматичних перевірок

• Performance QA — навантажувальне тестування

• Security QA — пошук уразливостей

Базовий шлях: Manual Junior → Manual Middle → AQA → Performance/Security/Lead.

SDLC — Software Development Life Cycle

Етапи створення продукту:

1. Requirements — вимоги, аналіз
2. Design — архітектура, UX
3. Development — кодування
4. Testing — перевірка
5. Deployment — реліз
6. Maintenance — підтримка, виправлення

Сучасний підхід — Agile: ці етапи переплітаються, працюємо ітераціями (спринтами по 1-2 тижні).

Waterfall vs Agile

• Waterfall — лінійно, кожен етап завершується перед наступним. Жорстко, повільно реагує на зміни. Використовується в bank/healthcare/aviation, де вимоги стабільні.
• Agile — ітераційно, гнучко. Стандарт у продуктових компаніях 2026.

STLC — Software Testing Life Cycle

Окремий цикл усередині SDLC, специфічно для тестування:

1. Requirements Analysis — що тестуємо, що не тестуємо
2. Test Planning — стратегія, ресурси, тулзи
3. Test Case Design — конкретні тест-кейси
4. Test Environment Setup — БД, тестові дані, акаунти
5. Test Execution — виконати тести, зафіксувати результати
6. Test Closure — звіт, lessons learned

Види тестування

За рівнем

Рівень	Що	Хто
Unit	Функція/клас ізольовано	Розробник
Integration	Кілька модулів разом	Розробник / QA
System	Уся система end-to-end	QA
Acceptance (UAT)	Замовник перевіряє	Бізнес

За методом

• Manual — людина клікає
• Automation — скрипти запускають перевірки
• Exploratory — без скрипта, дослідницьке (творче)

За доступом до коду

• Black box — без знання коду (як юзер)
• White box — знаючи код (як розробник)
• Gray box — частково

За об'єктом

• Functional — функціонал працює як описано
• UI — інтерфейс зручний, відображається правильно
• Performance — швидкість, навантаження
• Security — захищеність
• Compatibility — на різних браузерах/OS/devices
• Usability — UX
• Accessibility — доступність (a11y)
• Localization — переклади, формати дат/валют

Тестова піраміда

Класична модель балансу типів тестів:

        /\
       /UI\         мало, дорогі, повільні (хв)
      /----\
     /API   \       помірно, швидші (сек)
    /--------\
   /  Unit    \     багато, дуже швидкі (мс)
  /------------\

70% Unit / 20% API / 10% UI — типове співвідношення в здоровому проєкті. UI-тести найкрихкіші, найдорожчі в підтримці.

Принципи тестування (ISTQB)

7 класичних:

1. Тестування показує наявність дефектів — але не їх відсутність.
2. Exhaustive testing неможливе — не можна перевірити ВСЕ.
3. Чим раніше — тим дешевше — баг знайдений на етапі вимог в 100x дешевший, ніж у проді.
4. Кластеризація дефектів — більшість багів живе у вузьких ділянках.
5. Парадокс пестициду — ті самі тести з часом стають неефективними.
6. Контекст залежний — тестування банку ≠ тестування гри.
7. Хибне переконання у відсутності дефектів — баг-фрі ПЗ не існує.

Bug vs Defect vs Error vs Failure

• Error — помилка людини (програміст щось забув)
• Defect / Bug — слід помилки в коді
• Failure — як це проявляється для користувача

«Програміст написав = замість ==» → дефект → «застосунок крашиться при вході» — failure.

Severity vs Priority

Severity (тяжкість) — наскільки баг ламає функціонал:

• Blocker — нічого не працює
• Critical — основний flow зламаний
• Major — суттєва функція зламана
• Minor — мала проблема
• Trivial — типо/косметика

Priority (пріоритет) — наскільки терміново правити:

• P1 — зараз!
• P2 — наступний спринт
• P3 — колись
• P4 — backlog

Опечатка в назві компанії — severity Trivial, але priority P1 (бренд). Краш у нікомудoсі функції — severity Critical, але priority P4 (мало кого зачіпає).

Скільки заробляє QA в Україні (2026)

• Trainee / Junior: $400–800
• Middle: $1500–2500
• Senior: $3500–5000
• Lead: $5000+

AQA з Python/JavaScript на 30-50% більше за Manual.

Тест: перевір себе

1. Що таке STLC?
2. Чим Manual відрізняється від AQA?
3. У чому різниця між Severity і Priority?
4. Чому 70% тестів мають бути Unit, а не UI?
5. Хто пише unit-тести?

Відповіді

1. Software Testing Life Cycle — цикл етапів тестування: аналіз вимог → планування → тест-кейси → setup → execution → закриття. Аналог SDLC, але для QA.
2. Manual — людина натискає кнопки і перевіряє результат. AQA — пише код (Python/JS/etc), який автоматично виконує перевірки. AQA швидший, повторюваний, інтегрується в CI.
3. Severity — наскільки баг технічно поганий (blocker → trivial). Priority — наскільки терміново фіксити (бізнес-перспектива). Можливо minor severity + P1 priority (мала проблема, але впливає на репутацію).
4. Unit-тести швидкі (мс), легко підтримувати, надійні. UI-тести крихкі (поломалися від зміни класу div), повільні (хв), дорогі. Якщо ти тестуєш бізнес-логіку лише через UI — у тебе flaky CI і десятки годин на тиждень на підтримку тестів.
5. Розробники. QA не пишуть unit-тести за дефолтом — це частина DefiniteOfDone розробника. QA інтегрується на рівні API/UI/Integration.