Справжній ризик ШІ в тестуванні: хибна впевненість, а не помилки

Панель управління світилася зеленим. Усі дим-тести пройшли успішно. ШІ-агент згенерував нові тест-кейси, очистив старі й навіть за лічені хвилини повідомив, як покращилося тестове покриття. Команда впевнено рухалася до запуску в п'ятницю.

А тепер понеділок ранку.

У службі підтримки з'явилися тікети. Клієнти, чиї збережені адреси не могли завершити оформлення замовлення. Як їхні збережені адреси зламалися? Інтерфейс виглядає повністю зламаним на звичайному мобільному пристрої. Критичний API не мав надійної обробки граничних випадків. У сукупності всі ці проблеми вказують на більшу загрозу: готовність команди сліпо покладатися на зовнішні дані, припускаючи, що все правильно.

Ось справжня небезпека, яку ШІ приносить у QA.

Справа не в тому, що ШІ привнесе помилки в наші тести. Усе програмне забезпечення має помилки. Усі QA-команди вміють їх виявляти та усувати. Однак більша загроза ШІ полягає в тому, що він може змусити команду повірити, що їхнє тестування є ретельним, навіть коли це не так. З ШІ у тестуванні QA-команда може отримати хибне відчуття впевненості, що все точно.

Ця хибна впевненість може коштувати дуже дорого. Ця надмірна самовпевненість може призвести до величезних фінансових зобов'язань. Навіть повністю протестовані ШІ-системи іноді можуть відмовити, зіткнувшись зі складностями реального світу. McDonald's нещодавно відключив ШІ-систему IBM, яку тестував на своїх пунктах обслуговування без виходу з автомобіля, після того як вона неодноразово допускала помилки в замовленнях. Це нагадування про те, що навіть надійні технології можуть мати серйозні недоліки.

Що насправді означає хибна впевненість у QA

Справжня проблема виникає, коли команда переконана, що тести достатньо перевірили дану систему. Це хибне відчуття безпеки виникає через те, що відповідні ризики безпеки або не виявлені, або не ретельно перевірені.

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

Автоматизація стає ще складнішою при впровадженні ШІ. Одна річ, яку потрібно знати про мовні моделі ШІ, — це те, що вони можуть представляти інформацію у спосіб, який здається переконливим, але насправді є оманливим. 

Ми можемо бачити виконані тести й навіть краще тестове покриття, оскільки ШІ допомагає з побудовою тестів і аналізом результатів будь-якого виконання тесту. Усе це корисно.

Але не всі переваги є абсолютно надійними.

Тест, побудований ШІ, може пропустити якийсь критичний елемент бізнес-логіки. Або він може бути розроблений тільки для тестування звичайних сценаріїв. Такий тест здаватиметься цілком адекватним. Якщо результати чисті й чітко виражені, команда, ймовірно, розглядатиме тест як адекватний, залишаючи серйозні недоліки невиявленими.

Ось чому тести часто можуть створювати можливості для команд робити хибні припущення.

Більш важливим питанням сьогодні для будь-кого, хто займається автоматизованим тестуванням програмного забезпечення з використанням штучного інтелекту, має бути не «Чи створює ШІ тести ефективніше?», а «Чи дійсно надійні тести, створені ШІ?»

Чому ШІ ускладнює виявлення проблеми

Поганий ручний тест можна швидко виявити. Скриптові тести, які написані неправильно, часто роблять помилки.

Але коли тести, побудовані штучним інтелектом (ШІ), не спрацьовують, важко зрозуміти це з першого погляду. Вони можуть робити твердження, які здаються дуже точними, назви й сценарії, які здаються реалістичними. Але вони можуть мовчки пропускати найважливіші фактори. Вони можуть неправильно інтерпретувати справжню мету функції. Вони можуть представляти одні й ті самі ідеї по-різному. ШІ також може робити надмірно впевнені звіти про випуск програмного забезпечення без достатніх доказів.

Це створює небезпечний розрив між зовнішньою плавністю й внутрішньою якістю.

У забезпеченні якості (QA) наша впевненість має виходити з відстежуваності тестів, глибини покриття, оцінки ризиків та спостережуваних результатів. А не з того, наскільки гарно виглядають дані, створені ШІ.

П'ять способів, якими ШІ створює хибну впевненість у сучасному QA

Надмірне тестування звичайних сценаріїв

ШІ відмінно працює там, де є регулярні шаблони. Тому він легко притягується до нормальних потоків, очікуваних вхідних даних і звичайної поведінки користувача.

Але серйозні дефекти програмного забезпечення часто ховаються в інших місцях:

• Переходи між станами: під час змін з одного стану в інший.
• Проблеми з таймінгом: помилки в часі виконання процесів.
• Повторні спроби й переривання: проблеми, коли невдалі транзакції повторюються або переривається.
• Межі дозволів: прогалини в безпеці на межах дозволів.
• Часткові збої: коли відмовляють лише частини системи без повного збою.
• Непослідовні вхідні дані з реального світу: випадкова інформація, надана клієнтами в реальному світі. 

Якщо тести, згенеровані ШІ, лише слідують звичайним сценаріям, задуманим дизайнером продукту, вони залишать ризиковані шляхи недоторканими. Це лише створює ілюзію того, що тести завершені.

Створює погані твердження 

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

ШІ може виконувати такі легкі автоматизовані тести набагато швидше за людину. Однак якщо умови вашого тесту (твердження) занадто загальні, погано визначені або не відповідають бізнес-кейсу, то просте виконання тесту не забезпечує великої безпеки для випуску програмного забезпечення. Тест-пас при оформленні замовлення може просто показати банер успіху й не забезпечити правильну обробку замовлення (податок, підсумки тощо), відправку електронного листа або зменшення запасів.

Більше тест-кейсів і більше недоліків

Команда може перевірити 40 тест-кейсів, написаних вручну. Але вони можуть не застосовувати той самий підхід до 400, які були швидко створені за допомогою ШІ. Це одна з найбільших пасток QA на основі ШІ: ретельне тестування природно зменшується зі збільшенням кількості.

Наявність більшої кількості тест-кейсів може дати нам певну психологічну впевненість. Коли кількість збільшується, ми відчуваємо, що набір тестів дуже широкий, а звіти бездоганні. Але збільшення кількості тест-кейсів ніколи не є заміною їхньої якості.

Без належного відображення ризиків і відстеження вимог ШІ лише допоможе записати здогади замість перевірки справжньої якості системи.

Створює сліпу довіру до зелених індикаторів

Коли звіти конвеєра завжди показують зелений колір, це дає командам сильне відчуття впевненості й заохочує швидкі рішення. Це усуває перешкоди для виконання роботи, тому це відчуття безпеки легко поширюється, коли команди починають будувати, виправляти та пріоритизувати власні тести за допомогою ШІ. Їхній інстинкт переходить від перевірки та підтвердження результатів до сліпої довіри системі. На поверхні це здається незначним, але це може назавжди змінити культуру QA. Питання перестає бути «який ризик покриває цей тест?» і стає «чи виконав ШІ тест для цього?» На цьому етапі люди схильні припускати, що все гаразд, і припиняють ставити під сумнів якість.

Робить навіть сліпі помилки, які здаються розумними

Однією з найнебезпечніших особливостей сучасних ШІ-систем є те, що вони можуть представляти навіть найочевидніші помилки з великою достовірністю. Це має велике значення в забезпеченні якості (QA).

Навіть якщо ШІ-тест написаний з неправильним розумінням вимоги або неповною інформацією, його вихід буде дуже точним і відшліфованим, щоб виглядати так, ніби він написаний правильно. Типовий тест не зможе швидко знайти помилку. Небезпека тут не тільки в самій помилці, а й у тому, наскільки легко в помилку можна повірити.

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

Що розумні QA-команди роблять інакше

Це не означає, що ШІ слід повністю уникати.

Рішення полягає в тому, щоб використовувати його, не віддаючи своє судження ШІ. Найкращі команди забезпечення якості (QA) бачать ШІ як помічника, а не щось, чому можна сліпо довіряти. Хоча вони використовують його для збільшення швидкості, вони не надають йому остаточної довіри. Тобто вони дотримуються робочого стилю, коли довіряють лише результату, наданому ШІ, після його верифікації.

Давайте подивимося, як це працює на практиці.

Розумійте ризик перед створенням тестів

Перед створенням тест-кейсів вам слід чітко визначити основні проблеми, які можуть вплинути на бізнес або користувача.

Області, пов'язані з фінансовими транзакціями, юридичними питаннями (дотриманням вимог), ідентичністю, дозволами та довірою клієнтів, повинні бути першими, на які слід звернути увагу. Які помилки трапляються дуже рідко, але спричиняють великі втрати? Де помилки легко залишаються непоміченими?

ШІ може запропонувати нові ідеї в таких сферах. Але людям належить вирішувати, де більше ризиків.

Перевіряйте, що стверджує тест, а не лише кроки

Кожен крок у тест-кейсі, згенерованому ШІ, може здаватися правильним з першого погляду. Але справжнє питання полягає в тому, чи тест дійсно тестує правильний результат.

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

Підтримуйте багаторівневе тестове покриття

Один рівень тестування сам по собі не може гарантувати, що система є повною. Модульне тестування, API, інтеграція, наскрізне (E2E), дослідницьке тестування й зворотний зв'язок з виробництва — усе це виявляє різні типи ризиків.

Якщо ШІ тестує лише один рівень, команди не повинні вважати, що їхня система повністю безпечна. Кожен рівень слід тестувати з його власною важливістю.

Майбутнє QA — це не менше людського

Багато бояться, що ШІ в тестуванні стане справою без людей. Але насправді відбувається протилежне.

Оскільки ШІ бере на себе повторювані завдання, втручання людини стає більш цінним. Виявлення ризиків, усунення неясностей, поставлення під сумнів припущень, тестування складних граничних випадків і запитання «Чи безпечна система, тому що тест пройшов?» — все це вимагає людського інтелекту.

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

Тому що помилки в системах завжди видно. Але надмірна впевненість часто змушує нас їх ігнорувати.

Уроки для вашого наступного кроку

ШІ, безумовно, може прискорити процеси QA. Він може допомогти командам створювати тести, зменшувати повторювані завдання й швидше реагувати на зміни.

Але ця неконтрольована швидкість може призвести до нового типу проблеми якості. Коли тести, згенеровані ШІ, змушують нас відчувати себе завершеними, коли глянцеві інформаційні панелі змушують нас вірити в них, коли витончені звіти мають пріоритет над ретельними оцінками, QA не є справді надійним. Натомість його легко обдурити.

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

Отже, справжня загроза, яку ШІ становить для QA, — це не помилки. Радше це хибна впевненість, яку він дає.