kostyl.dev
Перша робоча версія

Перевірка першої робочої версії

Методика наскрізного тестування основного сценарію, валідація точності розрахунків, звірка з вихідними вимогами та фіксація перевіреного релізу

Перевірка першої робочої версії

🎯 Мета розділу

  • Опанувати методику ручного наскрізного тестування (End-to-End Manual Testing) головного користувацького сценарію.
  • Провести покрокову валідацію всіх елементів управління, перемикачів та форм введення.
  • Звірити фактичну поведінку продукту з початковою специфікацією та критеріями готовності.
  • Навчитися усувати виявлені критичні блокери без порушення стабільності решти кодової бази.

🔑 Ключові терміни

  • Наскрізне тестування (End-to-End Testing / E2E): перевірка роботи програмного комплексу від точки входу користувача до кінцевого результату в реальному середовищі.
  • Критичний дефект (Blocker Bug): помилка, яка повністю зупиняє виконання головного сценарію або робить отримання результату неможливим.
  • Матриця відповідності (Requirements Traceability Matrix): таблиця зіставлення кожного пункту вихідного технічного завдання з фактичною функцією в коді.
  • Перевірений знімок (Verified Snapshot): стан релізу, який пройшов повний аудит якості та готовий до подальшого ітеративного розвитку.

Методика наскрізного тестування (Happy Path Walkthrough)

Створення коду — це лише половина інженерної задачі. Друга, не менш важлива половина — переконатися, що створена система працює саме так, як очікує користувач. Навіть найкращий AI може припуститися непомітної помилки у формулі або підставити неправильний множник, через що користувач отримає викривлені цифри.

Наскрізне тестування першої версії здійснюється за чітким протоколом із чотирьох фаз:

Loading diagram...
@startuml
skinparam style plain
skinparam backgroundColor #FFFFFF
skinparam activityBorderColor #1E293B
skinparam activityFontSize 13

start
:1. Фаза початкового стану;
note right #FEF3C7
  Перевірити відсутність залишків тексту,
  прихованість блоку результату
end note

:2. Фаза введення даних;
note right #FEF3C7
  Тест числових полів,
  зміна значень у select
end note

:3. Фаза розрахунку;
note right #FEF3C7
  Клік на кнопку дії,
  перевірка появи результату
end note

:4. Фаза математичного аудиту;
if (Результат збігається з ручним розрахунком?) then (так)
  :Фіксація перевіреного релізу;
  note right #DCFCE7
    Збереження v1.0-verified
  end note
  stop
else (ні)
  :Локалізація математичної помилки;
  :Точковий запит на виправлення;
  backtrack
endif
@enduml

Чек-лист інженерної верифікації компонентів

Під час виконання тестування відкрийте ваш веб-застосунок у вікні Live Preview та послідовно виконайте кожну перевірку:

1. Перевірка полів введення

  • Введіть мінімальне допустиме значення (наприклад, 1).
  • Введіть стандартне реалістичне значення (наприклад, 25).
  • Введіть велике число (наприклад, 500): чи не ламає це верстку картки?
  • Спробуйте ввести літери: чи блокує поле нечислові символи?

2. Перевірка випадних списків (Select)

  • Оберіть кожну опцію зі списку по черзі.
  • Переконайтеся, що вибір іншої опції дійсно впливає на кінцевий результат, а не просто залишає старе значення.

3. Перевірка тригера дії (Button)

  • Кнопка повинна мати чіткий ефект при наведенні курсору (:hover) та при натисканні (:active).
  • Повторні швидкі кліки не повинні призводити до дублювання або мерехтіння блоку результату.

4. Аудит точності результату

  • Зробіть розрахунок вручну на калькуляторі для конкретного прикладу (наприклад: 10 сторінок по 3 хвилини = 30 хвилин).
  • Порівняйте ручний розрахунок із цифрою на екрані. Чи немає помилок округлення на кшталт 30.00000000004?

Виправлення знайдених дефектів

Якщо під час перевірки ви виявили помилку (наприклад, дробові числа відображаються з десятьма знаками після коми), не поспішайте самостійно переписувати код, якщо не впевнені в синтаксисі. Складіть точковий баг-репорт для вашого AI-асистента:

Знайдено дефект у першій версії:
- Очікувана поведінка: результат розрахунку округлюється до цілого числа хвилин або максимум одного знака після коми.
- Фактична поведінка: виводиться значення «42.333333333333336 хв».

Завдання:
Використай метод Math.round() або toFixed(1) у функції розрахунку у файлі main.js. 
Інші частини файлу та стилі не змінюй.

Після внесення виправлення повторіть тестовий прохід і переконайтеся, що дефект усунуто, а решта функцій продовжує працювати без змін.

Фіксація релізу: перевірений знімок (v1.0-verified)

Коли всі пункти чек-листа виконано, обов'язково зафіксуйте цей стан. Назвіть цей знімок v1.0-verified.

Цей стан є кульмінацією Модуля 2. Ви маєте стабільний, клінічно протестований та перевірений цифровий продукт, готовий до наступного етапу — підвищення надійності, оптимізації та полішингу.

Практичні завдання та запитання для самоконтролю

Доопрацювання до першої робочої версії

Усунення розбіжностей з планом, програмування обробників подій, зв'язування введення даних з бізнес-логікою та динамічне оновлення інтерфейсу

Управління точковими змінами продукту

Методологія контрольованої еволюції кодової бази, локалізація зони впливу змін, запобігання побічним ефектам та перевірка цілісності системи

Copyright © 2026