Пастка тестування за допомогою ШІ
Ви чуєте, як хтось каже: «цього кварталу ми випустили на 40% більше тестів», і всі кивають.
Я бачив це в одній SaaS-компанії в Токіо. QA-лід пишався. Керівництво було задоволене. Пайплайн був «зеленим».
Через шість тижнів платіжна система вийшла з ладу на 72 години. Ніхто цього не помітив, тому що ШІ писав тести, які перевіряли «відсутність помилок» замість «коректності даних».
Це «сліпота тестування» (Testing Blindness).
Це стається, коли ваша команда генерує багато тестів, але не може зрозуміти, коли ці тести вводять вас в оману. ШІ полегшує помилкове сприйняття покриття тестами як якості тестування.
Нещодавній допис на Qiita демонструє саме цю проблему. Інженер використовував ШІ для роботи над проєктами без автоматизації. Тести створювалися швидко. Метрики виглядали чудово.
Але інженеру довелося вивчати Playwright та тестування API вручну. Чому? Тому що ШІ міг писати синтаксис, але не розумів, як працює система.
Сліпота тестування має три основні симптоми:
• Атрофія асерцій (Assertion Atrophy): Тести проходять, тому що вони перевіряють, чи не «падає» код, а не те, чи працює він правильно. • Сліпота до граничних випадків (Boundary Case Blindness): ШІ зосереджується на «щасливих шляхах» (happy paths). Він пропускає граничні випадки, такі як null-введення або стан гонитви (race conditions). • Інфляція впевненості в регресії (Regression Confidence Inflation): Ви почуваєтеся в безпеці, тому що кількість тестів подвоїлася. Насправді ви просто удвічі збільшили свою хибну впевненість.
З мого досвіду, використовуючи ШІ, команди за лічені місяці проходять шлях від нуля до 1200 тестів. Звіти виглядають ідеально. Але реальний рівень виявлення багів падає.
В Японії акцент на управлінні та процесах (kanri) може змусити сприймати ці високі показники як успіх. На Заході команди часто пропускають тести, бо з ШІ це робити легко. Обидва шляхи ведуть до збоїв у продакшені.
ШІ оптимізує метрики, водночас підриваючи вашу здатність до налагодження (debugging).
Якщо ви використовуєте ШІ в QA, дотримуйтесь цих правил:
- Щотижневий аудит тестів: Оберіть 5 випадкових тестів, створених ШІ. Запитайте себе: «Що могло б змусити цей тест пройти помилково?» Якщо ви не можете швидко відповісти, у вас є «сліпа зона».
- Встановіть квоту на граничні випадки: на кожні 10 тестів від ШІ пишіть 2 тести на граничні випадки вручну.
- Використовуйте «тест о 3-й годині ночі»: Запитайте себе, чи виявлять ці тести збій о 3-й годині ночі. Якщо ви не впевнені — вони недостатньо хороші.
- Залиште один модуль для ручного тестування: Тестуйте одну критично важливу секцію вручну. Це допоможе підтримувати ваші навички налагодження у тонусі.
Не плутайте обсяг тестів із їхньою якістю. Не дозволяйте ефективності замінити розсудливість. Тести, які вас рятують, — це ті, які ви справді розумієте.
Чи помітила ваша команда зниження якості тестування після впровадження ШІ? Поділіться своїм досвідом нижче.
Додаткова навчальна спільнота: https://t.me/GyaanSetuAi