Прибуток:
- Можливість розрізнити, де штучний інтелект економить реальний час у процесі контролю якості, а де рішення щодо якості, наприклад «готовий до публікації», залишаються за людьми залежно від рівня ризику завдання
- Здатність розпізнавати ризик помилкових проходів і впроваджувати дисципліну перевірки, яка перевіряє кожен тест ШІ шляхом навмисного порушення коду
- Здатність захищати тестові дані, особисті дані та ключі, а також набути звички виконувати тестування безпеки лише в рамках авторизації та з метою захисту.
Подумайте про вечір випуску. Було проведено сотні тестів, усі вони отримали зелене світло, команда відчула полегшення, і програмне забезпечення запрацювало. Наступного ранку клієнт повідомив, що вийшов збій платіжний екран. Тести були зелені, але він не бачив помилки. Це найпідступніший кошмар професії із забезпечення якості (QA), тобто дисципліни, яка систематично гарантує, що програмне забезпечення має бажану якість: тест, який світиться зеленим, але насправді нічого не підтверджує. Коли штучний інтелект (AI — програмне забезпечення, яке витягує шаблони з історичних даних і генерує текст і код) входить у цю професію, відбувається одночасно величезне прискорення та посилення саме цього кошмару. Початкова обіцянка цього модуля зрозуміла: штучний інтелект є помічником у тестуванні, генератором схем і мультиплікатором ідей; Ви тестувальник, який приймає рішення «чи готове це програмне забезпечення до випуску».
У цьому першому розділі ми зосередимося на дисципліні, а не на інструменті. Ви дізнаєтеся, де штучний інтелект заощаджує реальний час у процесі перевірки якості, де це небезпечно, чому оманливий зелений так званий «хибний пропуск» є найбільшим ризиком, як перевірити кожен результат і які дані ви можете надати якому інструменту. Без закладки цієї основи наступні одиниці залишаться в повітрі.
Як ШІ стане в нагоді в процесі тестування?
Давайте розділимо завдання тестування на два великих кластери. Перший кластер: повторювані, продуктивні, чорнові роботи. Складання тестового прикладу на основі вимоги, перерахування точок зупину, написання скелета коду автоматизації для екрана, переклад складного випадку помилки в акуратний звіт про помилку, узагальнення сотень рядків файлів журналу, вилучення схеми з відповіді API. У цих завданнях ШІ скорочує хвилини до секунд і не втомлюється.
Другий кластер: рішення, результатом яких є якість, довіра та відповідальність. Рішення на кшталт «чи може ця версія запрацювати», «чи ця помилка критична чи її можна відкласти», «чи достатнє охоплення цього тесту», «чи враховує цей сценарій реальний ризик користувача» тощо, вимагають контексту, знання продукту та відповідальності. Тут штучний інтелект генерує варіанти, чернетки — але ви вирішуєте «пройти/не пройти» та «йти/не проходити».
Давайте прояснимо різницю одним реченням: штучний інтелект сильний у тому, «які ситуації можна тестувати та як написати код, який його тестує»; За вами вирішувати питання «Чи справді це програмне забезпечення працює і хто за нього ручається?»
Порада: перш ніж передати завдання штучному інтелекту, запитайте: «Що станеться, якщо цей результат неправильний, і я не помічу?» Якщо відповідь «Я втрачу кілька хвилин», легко делегуйте. Якщо відповідь: «несправне програмне забезпечення запущено», дозвольте ШІ створити чернетку, а ви прийміть рішення та перевірку.
Помилкове проходження: ризик номер один для ШІ в QA
Коли тест світиться зеленим, це може означати дві речі: або програмне забезпечення справді працює правильно, або воно не бачить помилку, оскільки тест був написаний неправильно. Другий називається помилковим проходженням — тест говорить «пройшов», але насправді нічого не підтверджує. Цей ризик значно зростає в тестах, створених за допомогою штучного інтелекту, оскільки штучний інтелект дуже успішно пише плавні, зрозумілі, але пусті тести.
Три найпоширеніші форми псевдопереходу: (1) Тестування без твердження — код виконується, не містить твердження, завжди проходить. (2) Тест із самоперевіркою — очікуване значення тесту обчислюється на основі виводу тестованого коду; Тобто, що б код не видав, тест приймає як «правильний». (3) Тест, який перевіряє неправильну річ — assert існує, але перевіряє щось тривіальне (наприклад, «відповідь не нуль»), а не справжнє бізнес-правило.
Застереження: зелена тестова панель не є доказом якості; У найкращому випадку там написано "написані нами елементи керування зараз не зламані". Нехай вас не втішає те, що тест, який видає штучний інтелект, «пройшов» — справжнє запитання: чи стане цей тест червоним, якщо я навмисно зламаю код? Якщо він не обертається, той тест є прикрасою.
Золоте правило, яке повторюється в цьому модулі: тестуйте кожен тест штучного інтелекту, навмисно зламавши код. Якщо тест все ще зелений, цей тест не працює. (Ми поглибимо цю ідею як перевірку мутацій у блоці 10.)
Перевірочна дисципліна: три кроки
ШІ говорить впевнено; Це не означає, що це правда. Розвивайте триетапний рефлекс для застосування до кожного результату:
- Прив’яжіть його до вимоги. Кожен тестовий приклад і стверджувати, що створює ШІ, повинні базуватися на реальних вимогах або критеріях прийняття (умови, яким має відповідати робота, щоб вважатися «виконаною»). «Яке правило підтверджує цей сценарій?» запитати.
- Бачити червоний. Запустіть згенерований тест один раз, зламавши код. Якщо він не стає червоним, тест недійсний. Це необхідний крок у тестуванні ШІ.
- Пропустіть його через контекстний фільтр. Чи відповідає вихід тому, що ви знаєте, як поведінка продукту, архітектура, фактичний потік користувачів? Ваші знання домену є останнім фільтром.
Конфіденційність і безпека даних: що куди йде?
Дані, з якими ви працюєте в тестовому середовищі, часто є конфіденційними: записи реальних клієнтів, копії робочої бази даних, ключі API, внутрішні системні адреси, ще не оголошені функції. Зробіть просту класифікацію: відкриті дані (задокументовані, загальнодоступні) можуть вводити будь-який транспортний засіб. Внутрішні дані (фрагменти вихідного коду, внутрішня документація) лише для інструментів, затверджених агентством. Конфіденційні дані (справжні дані клієнта, ідентифікаційна інформація, деталі вразливостей, ключі) надходять лише в інструменти установи, які є контрактними, чиї дані не йдуть на навчання моделі, бажано замасковані.
Існує додаткове обмеження в контексті тестування безпеки: усе, що вивчається в цьому модулі, призначено для захисних цілей — для авторитетного тестування безпеки вашого власного продукту. Використання штучного інтелекту для проникнення в чужу систему без дозволу, використання реальних вразливостей або тестування системи, на яку ви не маєте повноважень, є водночас неетичним і злочинним. Образливе тестування не проводитиметься без дозволу (обсяг і дозвіл).
Порада: використовуйте синтетичні (штучно створені) тестові дані замість реальних даних клієнтів. Попросивши штучний інтелект «генерувати реалістичні, але повністю вигадані тестові дані» зберігає конфіденційність і урізноманітнює крайові випадки.
три міні-чохла
Випадок 1 — Економія часу в потрібному місці. Тестувальник команди Ekomerce витратив 6 годин на створення сценарію тестування вручну з 30-сторінкового документа з вимогами для кожного випуску. Він передав документ (частину, яка не містила комерційної таємниці) YZ і попросив структурований проект сценарію; Час скорочено до 90 хвилин. Він присвятив зекономлений час самостійній перевірці, додавши крайові випадки бізнес-правил, які ШІ пропустив. ШІ забрав повторювану роботу, залишивши судження людині.
Випадок 2 — Спіймано фальшиве проходження. Розробник попросив ШІ написати 12 модульних тестів для обчислювальної функції; вони всі були зелені. Тестер реалізував крок «бачиш червоне»: навмисно змінив знак додавання всередині функції на множення. Лише 3 з 12 тестів дали червоний колір. Інші 9 тестів не дали реального підтвердження; Він просто сказав, що "це не викинуло помилку". Видалено 9 декоративних і замість них написано 5 справжніх.
Випадок 3 — Повернення після порушення конфіденційності. Стажер вставив журнал помилок, що містить справжні електронні адреси клієнтів і останні чотири цифри картки з робочої бази даних, у загальнодоступний інструмент і сказав «поясніть цю помилку». Керівник QA втрутився: це персональні дані, що вийшли з-під контролю, і це порушення КВКК (Закон про захист персональних даних). Ту саму роботу було виконано в схваленому установою транспортному засобі, замаскувавши особисті місця та залишивши лише слід від купи.
Чотири шаблони, які можна копіювати
1) Оцінка відповідності посаді:
Ваша роль: старший керівник QA. Я опишу вам тестову роботу. Скажіть мені (1) чи є ця робота проектуванням/аналізом, який можна безпечно делегувати штучному інтелекту, чи якісне рішення, яке має прийняти людина, (2) потенційна вартість неправильного результату, (3) перевірка, яку я маю виконати перед делегуванням. Робота: [вставте тут роботу]
2) Контроль псевдопроходу:
Перегляньте тест нижче. Скажіть мені:- Яку поведінку підтверджує цей тест? (одне речення)- Як я можу зламати тестований код, щоб тест став ЧЕРВОНИМ?- Чи є слабка сторона, через яку цей тест завжди проходитиме (відсутнє твердження, самоперевірка, тривіальна перевірка)? Тест: [вставте тест тут]
3) Тестовий контроль маскування даних:
Журнал/дані, які я вам надам, можуть містити особисті або конфіденційні поля (електронна пошта, ім’я, картка, ключ, внутрішня адреса). Спочатку перелічіть поля, які потрібно замаскувати; Замаскую і відправлю повторно. Не аналізуйте це як є.
4) Генерація синтетичних тестових даних:
Згенеруйте 20 рядків повністю вигаданих, реалістичних тестових даних для [наведеної нижче структури поля]. Не використовуйте реальні дані особи/організації. Також включіть крайові випадки: порожній простір, надто довгий текст, граничні значення, недійсний формат.
Слабка підказка / Сильна підказка
Слабкий: «Напишіть тести на цьому коді».
Сильно: «Обчисліть це. Напишіть одиничні тести для функції знижки. Критерії прийнятності для функції: 10% знижка понад 1000 TL, 20% знижка понад 5000 TL; від’ємна сума має викликати помилку. Укажіть у рядку коментаря, яке правило ви перевіряєте для кожного тесту. Перевірте граничні значення (999, 1000, 1001, 5000, 0, -1) окремо. Використовуйте справжні твердження, які стануть червоними, якщо я зламаю код, або не пишу тривіальне твердження."
Потужна підказка; Він надає критерії прийнятності, граничні значення, очікування перевірки та чіткі інструкції проти спуфінгу. Слабка підказка запрошує ШІ написати декоративний тест.
Поширені помилки
- Довірливий зелений. Думаючи, що проходження тесту є доказом. Справжнє питання: чи стає він червоним, коли ви зламуєте код?
- Вимагання тесту без пояснення причини. ШІ створює загальні, часто марні тести, не знаючи, що потрібно перевірити.
- Пропуск перевірки. Сказати: «ШІ написав це, напевно, це правда». Відповідальність лежить на особі, яка використовує результат.
- Вставлення реальних/конфіденційних даних в інструмент. Робота з виробничими даними, ключами або персональними даними.
- Несанкціоноване тестування безпеки. Спроба образливого тестування без обсягу та дозволу.
- Використання ШІ для делегування прийняття рішень. Задаючи питання "Чи можна випустити цю версію?" до AI і поставивши відповідь у підписі.
Підсумовуючи
AI є потужним помічником у процесі контролю якості, який прискорює повторювану та продуктивну роботу; Але відповідальність за якісне рішення лежить на людині. Ризик номер один від штучного інтелекту в цій професії – це псевдопрохід: зелені тести, які виглядають акуратно, але нічого не підтверджують. Тестуйте кожен тест ШІ, навмисно зламавши код; Якщо він не червоніє, той тест - декорація. Прив’яжіть його до вимоги, побачите червоне, пропустіть через контекстний фільтр. Маскуйте конфіденційні дані, виконуйте перевірку безпеки лише для авторизованих і захисних цілей.
Аплікаційне завдання
Виконайте 5 модульних тестів із власного проекту, згенерованих штучним інтелектом. Для кожного: (1) запишіть в одному реченні, яку поведінку він перевіряє, (2) навмисно зламайте та запустіть код, що перевіряється, і запам’ятайте, скільки з них стало червоним, (3) позначте ті, які не стали червоними, як «декораційні тести» та перепишіть їх зі справжнім твердженням. Помістіть результат у таблицю: назва тесту/правило, яке воно перевірило/чи він зламався, коли він зламався/дія.
контрольний список
- [ ] Перед здачею роботи я задався питанням «що я втрачу, якщо піде не так?»
- [ ] Я тестував кожен тест ШІ, зламавши код; Той, що не почервонів, замінив на справжній тест.
- [ ] Я пов’язав тестові приклади з фактичними вимогами/критеріями прийняття.
- [ ] Я маскував конфіденційні/справжні дані, не передаючи їх інструменту; Я використовував синтетичні дані, якщо це можливо.
- [ ] Я розглядав тестування безпеки лише в межах повноважень і з метою захисту.
- [ ] Я залишив рішення «чи буде випущена версія» за собою, а не за ШІ.