nmk

Лабораторна робота №12 (2 години)

Тема: Управління якістю (QA) та технічний борг

Практика забезпечення якості програмного продукту. Розробка базового Плану тестування (Test Plan), написання Тест-кейсів (Test Cases) та розуміння концепції Технічного боргу (Technical Debt), як найбільшого невидимого ризику IT-проєкту.

Мета: Навчитися мислити як QA Engineer: розробляти тестові сценарії для перевірки вимог (які ми писали у Лаб №5), вміти відрізняти QA від QC, та планувати час на рефакторинг коду.

Технологічний стек: Google Sheets / MS Excel / Будь-яка система управління тестами (TestRail, Zephyr - за бажанням).

Завдання

Якість — це не лише відсутність багів (це QC - Quality Control), це процес розробки надійного ПЗ від самого початку (це QA - Quality Assurance). У цій роботі ви повернетеся до User Stories з Лабораторної №5 і напишете для них документацію, за якою тестувальники будуть перевіряти роботу програмістів.

Перелік завдань:

  1. Скласти мінімальний Test Plan (План тестування) для вашого проєкту.
  2. Написати 3 детальні Test Cases (Тест-кейси) на основі ваших вимог.
  3. Описати стратегію управління Технічним боргом у вашому проєкті.

Хід виконання роботи

Крок 1. Розробка міні-стратегії тестування (Test Plan)

Test Plan — це документ керівника (QA Lead або PM), який описує, ЩО ми будемо тестувати, ЯК, і ХТО це буде робити.

Напишіть у звіті 3 ключові розділи вашого особистого Плану тестування:

  1. Об’єкт тестування: (Що ми тестуємо? Наприклад: iOS додаток та відповідний йому API).
  2. Види тестування, які будуть застосовані: Оберіть 3 види з теорії (наприклад, Інтеграційне, Регресійне, Навантажувальне, Smoke_test) і поясніть в одному реченні, ЩО САМЕ ви будете перевіряти цим видом тестування на вашому проєкті.
  3. Критерії зупинки (Suspension / Exit Criteria): За яких умов реліз переноситься? (Наприклад: Знайдено хоча б один баг рівня Critical).

Крок 2. Написання Тест-кейсів (Test Cases)

Тест-кейс — це детальна покрокова інструкція для QA, як перевірити конкретну кнопку чи функцію.

Візьміть 1 вашу User Story з Лабораторної №5. На її основі створіть 3 Тест-кейси у вигляді таблиці:

Шаблон таблиці для 1 Тест-кейсу (відтворіть його тричі):

Поле Опис
ID та Назва: TC-01: Перевірка успішної авторизації
Передумова (Preconditions): Користувач знаходиться на екрані “Login”. Валідна пошта: test@mail.com, пароль 12345 існують в БД.
Кроки (Steps): 1. Ввести test@mail.com у поле Email.
2. Ввести 12345 у поле Password.
3. Натиснути кнопку “Увійти”.
Очікуваний результат (Expected Result): Користувач перенаправлений на екран “Головна”, у правому куті відображається його ім’я.
Фактичний результат (Actual Result): (Тестувальник заповнює це після проходження тесту. Напишіть “Pass”, якщо тест пройдено)

Крок 3. Стратегія роботи з Технічним боргом (Technical Debt)

Більшість ризиків в IT пов’язані з поганим кодом. Технічний борг — це коли ми пишемо “костурбак” (швидкий, нестабільний код), щоб встигнути до дедлайну, розуміючи, що потім його доведеться переписувати.

Напишіть у звіті коротке есе (3-4 абзаци) як PM цього проєкту:

  1. Уявіть ситуацію: інвестор вимагає випустити додаток на місяць швидше. Ваші програмісти кажуть: “Ми встигнемо, тільки якщо відмовимося від написання Unit-тестів і скопіюємо частину коду з іншого проєкту”.
  2. Опишіть: чи підете ви на цей крок свідомого створення технічного боргу?
  3. Якщо так, ЯК САМЕ ви плануєте “виплачувати” цей борг у наступних Спринтах (щоб проєкт не перетворився через півроку на систему, яку неможливо підтримувати)?

Контрольні запитання

  1. У чому фундаментальна різниця між Quality Assurance (QA) та Quality Control (QC)? Який з цих підходів є превентивним (до появи багів)?
  2. Чому вважається, що вартість виправлення бага (Cost of Defect) на етапі збору вимог (Лаб №5) у 10-100 разів менша, ніж на етапі тестування або в Production?
  3. Що таке “Smoke Test” (Димове тестування) і коли воно зазвичай виконується?
  4. Для чого тестувальникам потрібно писати негативні тест-кейси, якщо їхня головна задача — переконатися, що програма робить те, що вказано у вимогах замовника?
  5. Наведіть 2 приклади факторів, які найчастіше призводять до неконтрольованого накопичення Технічного боргу (Technical Debt) на реальних проєктах.

Вимоги до звіту

  1. У репозиторії курсу на GitHub додати файл lab_12.md.
  2. В цей файл перенести результати виконання Кроків 1, 2 і 3 (Опис Test Plan, 3 розписаних Тест-кейси у таблицях, та короткий роздум щодо роботи з технічним боргом).
  3. У файлі lab_12.md дати письмові відповіді на всі 5 контрольних запитань.
  4. Завантажити зміни на GitHub та надіслати посилання викладачу.