Bug Hunter’s Diary: введення в тестування та роль QA

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привіт, спільното! 👋

Мене звати Настя, і я QA Engineer з досвідом у сфері тестування програмного забезпечення. Не багато, не мало — 7 років. За роки роботи я переконалася, що тестування — це не просто «клацання по кнопках» або пошук багів. Це цілий світ, де кожен тест, кожен звіт про помилку і кожен виявлений баг — це крок до створення якісного продукту, який радуватиме користувачів.

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

Готовий/готова? Тоді поїхали!

Основа основ — це знання і головне розуміння понять «тестування» та «якість». Якщо ти новачок, то це перше, що тебе спитають на співбесіді 🤗.

Тестування — це процес перевірки програмного забезпечення (ПЗ) на відповідність заданим вимогам, виявлення дефектів (багів) та оцінка його якості.

Основні цілі тестування:

1️⃣ Переконатися, що ПЗ працює коректно і відповідає вимогам.

2️⃣ Знайти дефекти та помилки до того, як продукт потрапить до кінцевого користувача.

3️⃣ Забезпечити впевненість у якості продукту.

Якість програмного забезпечення — це ступінь відповідності ПЗ встановленим вимогам та очікуванням користувачів.

1. Хто такий QA Engineer і навіщо він потрібен?

QA Engineer (Quality Assurance Engineer) — це фахівець, який контролює якість програмного забезпечення, допомагаючи знаходити та усувати помилки (баги) ще до того, як продукт потрапить до користувача.

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

• Тестувальник допомагає команді знаходити слабкі місця продукту 👩‍💻.
• Він стежить за тим, щоб ПЗ відповідало вимогам 📝.
• Його мета — мінімізувати ризики та запобігти критичним помилкам 📉.

Розберемо кілька ключових термінів:

• QA (Quality Assurance) — забезпечення якості (широкий процес, що включає тестування, контроль процесів розробки, покращення якості на всіх етапах).
• QC (Quality Control) — контроль якості (перевірка того, що продукт відповідає вимогам).
• Тестування (Testing) — безпосередній процес перевірки ПЗ на наявність помилок.

Або іншими словами:

• QA — це стратегія, підхід, що включає покращення процесів розробки.
• QC — це частина QA, яка займається перевіркою якості продукту.
• Testing — це конкретні дії з перевірки продукту (ручне або автоматизоване тестування)

2. Основні принципи тестування

Тестування базується на кількох ключових принципах:

✔️ Тестування показує наявність дефектів, але не їх відсутність.

✅ Приклад: Ти тестуєш калькулятор і знаходиш помилку при діленні. Це доводить, що в системі є баг. Але навіть, якщо ти не знайшов інших помилок, це не означає, що їх немає.

📌 Висновок: Тестування допомагає знаходити баги, але не може гарантувати, що їх взагалі немає.

✔️ Неможливо довести, що система абсолютно безпомилкова.

✅ Приклад: Ти перевірив сайт інтернет-магазину: всі сторінки завантажуються, товари додаються до кошика, оплата проходить. Помилок немає! Але чи може хтось гарантувати, що завтра на іншому пристрої чи при іншому навантаженні не з’явиться баг?

📌 Висновок: Навіть якщо тести нічого не знайшли, це не означає, що продукт ідеальний.

✔️ Вичерпне тестування неможливе.

✅ Приклад: Уяви, що у тебе є форма входу з двома полями:

• Логін (1000 можливих значень)
• Пароль (1000 можливих значень)

Всього комбінацій: 1 000 000! А якщо додати перевірку різних браузерів, мов, екранів?

📌 Висновок: Повністю протестувати все неможливо, тому тестування будується на аналізі ризиків.

✔️ Раннє тестування економить гроші та час.

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

📌 Висновок: Чим раніше знайдена помилка, тим дешевше її виправити.

✔️ Скупчення дефектів.

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

📌 Висновок: Зазвичай більшість багів зосереджено в найскладніших або часто змінюваних частинах системи.

✔️ Парадокс пестициду.

✅ Приклад: Ти кожного дня тестуєш мобільний додаток, натискаючи одні й ті самі кнопки, але нові помилки не знаходиш. А якщо спробувати інші сценарії (наприклад, змінювати мову, перевіряти темну тему)? Баги можуть з’явитися!

📌 Висновок: Якщо повторювати одні й ті самі тести, з часом вони перестануть знаходити нові помилки. Потрібно оновлювати тест-кейси!

✔️ Тестування залежить від контексту.

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

📌 Висновок: Методи тестування залежать від типу продукту.

✔️ Відсутність помилок не означає, що продукт придатний для використання.

✅ Приклад: Розробники створили ідеально працюючий мобільний банк:

• Всі кнопки натискаються.
• Дані завантажуються без помилок.
• Перекази проходять успішно.
• Немає багів або зависань.

Але при цьому:

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

Користувачі не розуміють інтерфейс — складно розібратися без інструкції.
Результат? Хоча додаток не містить багів, користувачі ним незадоволені і переходять до конкурентів.

📌 Висновок: Протестувати лише технічну сторону недостатньо — важливо враховувати користувацький досвід (UX), зручність використання та відповідність реальним потребам.

3. Життєвий цикл розробки ПЗ (SDLC) та місце тестування в ньому

SDLC (Software Development Life Cycle) — це структурований процес розробки програмного забезпечення, який включає всі етапи створення, тестування, впровадження та підтримки ПЗ. Основна мета SDLC — забезпечити високу якість продукту, відповідність вимогам замовника та ефективне управління ресурсами і часом.

У розробці ПЗ прийнято використовувати різні моделі життєвого циклу. Основні з них:

• Waterfall (Каскадна модель) — кожен етап (аналіз, проектування, розробка, тестування, впровадження) виконується послідовно. Мінус — пізнє тестування.
• Agile (Гибкі методології, наприклад, Scrum, Kanban) — розробка йде ітераціями (спринтами), тестування виконується на кожному етапі.
• Shift Left передбачає, що тестування починається ще на етапі проектування, що допомагає знаходити проблеми заздалегідь.

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

🟢 Функціональне тестування — перевіряє, чи відповідає ПЗ вимогам.

🟢 Нефункціональне тестування — оцінює продуктивність, зручність використання, безпеку тощо.

🟢 За рівнем автоматизації:

• Ручне тестування — тестувальник сам перевіряє додаток.
• Автоматизоване тестування — тести виконуються програмними скриптами (наприклад, за допомогою Selenium, Playwright, Cypress).

🟢 За часом виконання:

• • Smoke testing — швидка перевірка критично важливої функціональності.
  • Regression testing — перевірка, чи не зламалося щось після змін.
  • Exploratory testing — дослідницьке тестування без строгих сценаріїв.

5. Основні техніки тест-дизайну

Тест-дизайн — це процес проектування тестів для ефективного виявлення багів.

Популярні техніки:

📌 Еквівалентне розбиття — розділення вхідних даних на групи (наприклад, якщо поле приймає вік 18–99 років, то достатньо перевірити 18, 50 і 99).

📌 Аналіз граничних значень — перевірка крайніх значень діапазону (наприклад, 17, 18, 99, 100).

📌 Попарне тестування — скорочення кількості тестів за рахунок комбінування вхідних параметрів.

Приклад попарного тестування:

Тестуємо форму реєстрації з трьома полями:

Операційна система: Windows, macOS, Linux

Браузер: Chrome, Firefox, Safari

Мова інтерфейсу: Англійська, Українська

Замість 18 тестів (3 ОС × 3 браузери × 2 мови) використовуємо 9 тестів, перевіряючи кожну пару значень хоча б раз.

6. Інструменти тестувальника

Тестувальнику потрібно вміти працювати з різними інструментами, наприклад:

• JIRA, Trello — для управління задачами та багами.
• Postman — для тестування API.
• DevTools — для аналізу веб-додатків.
• SQL — для роботи з базами даних.

і багато інших, але то вже теми наступних постів 😇.

7. Як увійти в професію та розвиватися

Якщо ти хочеш стати тестувальником, почни з базових навичок:

✍🏼 Вивчи теорію тестування.

✍🏼 Опануй роботу з баг-трекінговими системами.

✍🏼 Розберися з інструментами тестування API та баз даних.

✍🏼 Почни вивчати основи програмування (Python, JavaScript) для автоматизації.

Отже, ми розглянули основи тестування ПЗ і з’ясували, що QA Engineer — це не просто «шукач багів», а важлива ланка у процесі створення якісного продукту. Ми дізналися, що тестування — це не лише технічний процес, а й стратегія, яка допомагає запобігти проблемам на ранніх етапах, заощадити час і гроші, а також забезпечити високий рівень задоволеності користувачів.

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

Бажаю тобі натхнення, терпіння і багато цікавих проектів! І нехай твої тести завжди знаходять баги до того, як їх знайдуть користувачі. 😊