Уявіть: ви попросили AI підготувати тести для імпорту банківської виписки. Отримали акуратний список: коректний файл, порожній файл, неправильний формат, відсутня сума, некоректна дата. Перевірки проходять. Потім користувач завантажує ту саму виписку вдруге, і підсумок подвоюється.
Це вигадана ситуація, але на ній добре видно проблему. Тести можуть ретельно перевіряти форму даних і водночас пропускати поведінку, заради якої існує продукт. Додавати ще двадцять перевірок формату дати тут марно. Потрібне інше запитання: яку помилку користувач помітить у своїй роботі?
Під час розробки сервісу для обліку ФОП я використовував Codex, зокрема для створення регресійних тестів. Початковим орієнтиром були власні розрахунки в таблиці. Вони давали змогу зіставляти результат після змін із перевіреними прикладами. Нижче пропоную окрему навчальну вправу, яку можна розібрати без доступу до продукту. Усі дані вигадані, а правила навмисно спрощені. Це перевірка логіки імпорту, а не модель податкового обліку.
1. Спочатку домовимося, що означає «правильно»
Наш умовний сервіс показує суму оплат клієнтів. Для вправи діють такі правила:
-
Правило 1: У розрахунок потрапляють лише завершені гривневі операції з типом «оплата клієнта».
-
Правило 2: Внутрішні перекази між власними рахунками зберігаються, але не збільшують цей показник.
-
Правило 3: Ключ операції складається з ідентифікатора рахунку та банківського ID операції. Для вправи вважаємо цю пару стабільною й унікальною.
-
Правило 4: Повторне отримання тієї самої завершеної операції нічого не додає до суми.
-
Правило 5: Дві різні операції з однаковими датою та сумою враховуються окремо.
Останні два правила легко сплутати. Якщо видаляти дублікати за сумою та датою, повторний імпорт може працювати красиво, але один із двох реальних платежів зникне.
У справжній інтеграції стабільність ID, межі його унікальності та можливість зміни статусу потрібно перевірити за контрактом API. У цій вправі ми задаємо їх як умову, щоб не підмінити аналіз припущенням.
2. Чотири рядки, які варто порахувати без AI
Візьмемо чотири завершені операції за одну дату на рахунку A:
-
P-101: оплата клієнта, 1 200 грн.
-
P-102: оплата клієнта, 1 200 грн.
-
T-103: внутрішній переказ, 5 000 грн.
-
P-104: оплата клієнта, 800 грн.
Очікуємо чотири збережені операції та 3 200 грн оплат клієнтів: 1 200 + 1 200 + 800. Після другого імпорту тих самих даних мають залишитися чотири операції й ті самі 3 200 грн.
Тепер уявімо три помилкові реалізації. Перша додає всі додатні суми й отримує 8 200 грн. Друга вважає однакові дату та суму ознакою дубліката й отримує 2 000 грн. Третя правильно обробляє перше завантаження, але після повторного показує 6 400 грн.
Усі три можуть успішно читати CSV, приймати коректні дати та відхиляти порожні суми. Тести парсера не зобов’язані ловити ці помилки. Проблема виникає, коли ними обмежують перевірку всієї функції.
Для цих чотирьох рядків очікуваний результат легко вивести з правил вручну. Це наш тестовий оракул: підстава, за якою ми вирішуємо, чи правильна відповідь системи. Якщо розрахувати очікувану суму тією самою функцією, яку перевіряємо, її помилка може опинитися по обидва боки порівняння.
3. Дайте кожному тесту помилку, яку він має спіймати
Зручний спосіб переглянути AI-список: біля кожного правила написати, яка неправильна реалізація порушить його та який тест це покаже.
-
«Повтор не додає суму»: потрібні два послідовні імпорти в одну й ту саму базу. Якщо перед кожним запуском тест очищає базу, він щоразу перевіряє лише перше завантаження.
-
«Різні платежі не зливаються»: потрібні P-101 і P-102 з однаковими датою та сумою. Два платежі на різні суми не перевірять цю пастку.
-
Внутрішній переказ: потрібна додатна сума з відповідним типом. Якщо тест містить лише вихідний переказ, помилковий фільтр «усе додатне є оплатою» може пройти непоміченим.
-
Складений ключ: потрібна ще одна операція з ID P-101, але на рахунку B. Нехай це окрема оплата на 300 грн. Після її імпорту очікуємо п’ять збережених операцій і 3 500 грн. Так ми перевіряємо, чи система випадково не вважає банківський ID глобально унікальним.
У кожному випадку перевіряйте і підсумок, і склад збережених даних. Правильне число може вийти випадково: одна операція загубилася, інша продублювалася на таку саму суму.
4. Змініть шлях даних, залиште результат
Тепер трохи ускладнимо вправу без нових бізнес-правил. Ті самі чотири початкові операції можна подати кількома способами:
-
Варіант 1: одним файлом;
-
Варіант 2: у зворотному порядку;
-
Варіант 3: двома файлами з перетином: спочатку P-101 і P-102, потім P-102, T-103 і P-104;
-
Варіант 4: повторно після того, як частина операцій уже збережена.
За нашими умовами фінальний набір має бути однаковим: чотири унікальні операції та 3 200 грн. Для останнього сценарію потрібно явно задати, які записи вже є в базі перед повтором. Інакше словосполучення «частковий збій» залишиться лише красивою назвою тесту.
Це корисна вправа для AI: попросити змінювати порядок і спосіб подання даних, не змінюючи очікуваний зміст результату. Але межі такого правила визначає людина. Наприклад, якщо в реальному продукті пізніше повідомлення оновлює статус операції, довільна перестановка повідомлень уже потребує окремих правил обробки версій.
5. Шукайте запитання, на які модель надто швидко відповіла сама
У вимозі «показати оплати за місяць» ще немає відповіді, яку дату брати: створення операції, її завершення чи завантаження виписки. Не визначено й часовий пояс. AI може вибрати варіант і побудувати навколо нього десяток цілком послідовних тестів.
Такі місця варто виносити в запитання до власника вимог. До узгодження можна підготувати альтернативні сценарії, але не називати один із них затвердженим очікуваним результатом.
Окремий приклад: для податкового календаря кейс «дата правильна» потребує зазначеного профілю підприємця та відповідного офіційного джерела. Без цього модель може перевіряти строки для іншого режиму роботи й не помітити підміни умов.
6. Промпт для перевірки покриття
Після самостійного розбору правил можна передати AI таке завдання:
«Нижче наведено вимоги, приклад даних та наявні тести. Зістав кожну вимогу з тестами. Для кожної вкажи можливу помилкову реалізацію й конкретний тест, який її виявить. Якщо перевірки немає, запропонуй мінімальний приклад даних, початковий стан, дію та очікуваний результат. Окремо познач невизначені вимоги, суперечності та власні припущення. Не вигадуй бізнес-правила. Для кожного очікуваного результату поясни, з якої вимоги він випливає. Перевір, чи тести враховують повторний запуск і чи очікуване значення не обчислюється кодом, який вони перевіряють».
До промпту додаємо правила вправи та чотири рядки. Для робочого проєкту використовуємо синтетичні або належно знеособлені дані в дозволеному командою середовищі. Банківські виписки клієнтів не потрібні, щоб показати моделі різницю між повторною операцією і двома однаковими оплатами.
Відповідь AI знову перевіряємо за вимогами. Модель може знайти прогалину, але може й запропонувати очікування, яке суперечить узгодженому правилу. Корисний результат такої роботи: коротший шлях до конкретних перевірок і конкретних запитань.
Замість висновку: Перед тим як довіритися зеленому звіту
Тому запитайте себе:
-
Чи можу я пояснити очікуваний результат, не заглядаючи в реалізацію?
-
Чи є тест, який відрізняє повторну операцію від схожої на неї нової?
-
Чи перевіряю я стан після кількох дій, а не лише один ізольований виклик?
-
Яку очевидно неправильну реалізацію цей набір поки що пропустить?
-
Де в тестах заховане рішення, якого немає у вимогах?