Про це QA-інженерка розповіла на Linkedin.
«Claude може легко згенерувати вам дуже гарні тест-кейси на бізнес-вимоги, яких і близько немає у вашому продукті», — зазначає Дика.
Як приклад вона взяла таку вимогу: «Користувач може скасувати підписку». На перший погляд усе виглядає зрозуміло. Утім, на практиці одразу виникають питання. Що саме це означає? Доступ зникає одразу чи лише після завершення вже оплаченого періоду? Що буде з наступним списанням? Чи повертаються гроші? А якщо користувач натиснув «скасувати» саме тоді, коли система вже обробляє автопродовження?
Як Анастасія Дика радить використовувати ШІ
Модель можна попросити пошукати прогалини у вимогах. Наприклад, знайти ситуації, для яких поведінка продукту не визначена. У випадку з підпискою це може бути момент припинення доступу або правила повернення коштів.
Далі ШІ-помічник може допомогти сформулювати питання для бізнес-аналітика або Product Owner. Наприклад, що станеться, якщо скасування підписки збіглося з автопродовженням, і від чого ця відповідь залежить:від статусу підписки, платежу чи доступу користувача?
Потім йтиме перевірка Acceptance Criteria. Формулювання на кшталт «підписка успішно скасовується» залишає багато простору для трактувань. Тож ШІ-асистенту треба спитати про початковий стан, дію користувача та конкретний результат: який статус отримає підписка, коли завершиться доступ і що станеться з автопродовженням.
ШІ також можна використовувати для пошуку потенційних ризиків і нестандартних сценаріїв. Наприклад, що буде, якщо платіжний сервіс підтвердив скасування, але система не отримала про це повідомлення. ШІ-агент може запропонувати подібні сценарії, а потім варто перевірити, чи є вони можливими з огляду на архітектуру системи.
Так само ШІ може запропонувати додаткові сценарії. Наприклад, повторне скасування, таймаут, уже скасовану підписку або одночасне автопродовження. Якщо невідомо, яким має бути очікуваний результат, це може означати, що у вимогах чогось бракує. А ще ШІ-помічник може допомогти розбити функцію на окремі частини — наприклад, керування підпискою, платежі, права доступу та сповіщення. А потім показати залежності між ними.
Дика також радить встановлювати для моделі чіткі обмеження. Наприклад, просити агента посилатися на конкретний ID або фрагмент вимоги для кожного висновку, окремо позначати припущення та не вигадувати бізнес-правила, якщо їх немає у вхідних даних.
А після того, як бізнес-аналітик або Product Owner дадуть відповіді на запитання, оновлені вимоги можна знову передати ШІ-асистенту та попросити визначити, які тестові сценарії тепер потрібно змінити, додати або прибрати. Це допомагає не залишити в тестах застарілі очікування після зміни або уточнення бізнес-логіки.
У коментарях Senior Angular Engineer Володимир Заплатинський також розповів, що стикався зі схожою проблемою.
«Оо, це точно, стикався якраз із цим, коли AI генерує тести для того щоб захистити своє рішення. А не щоб запобігти можливому багу в коді», — розповів він.
У відповідь Дика розповіла про ситуацію, коли ШІ одного разу сам вигадав бізнес-логіку, якої не було в продукті, а потім згенерував тести під власне припущення. «Варто вчасно зупиняти таку „активність“», — зазначає Дика.
Раніше dev.ua брав інтерв’ю у QA-фахівчині Ірини Грабовської, яка також розповідала, як використовує ШІ у своїй роботі. За її словами, ChatGPT і Claude допомагають швидко складати чеклісти, рев’ювати тест-кейси та перевіряти, чи нічого не пропущено, однак повністю покладатися на відповіді моделей вона не радить.
/
Senior Software QA Engineer Анастасія Дика радить QA-фахівцям не починати роботу з Claude та іншими ШІ одразу з генерації тест-кейсів. За її словами, спочатку моделі варто дати проаналізувати вимоги та попросити знайти в них прогалини, суперечності та невизначеності. Інакше ШІ може самостійно «додумати» бізнес-логіку продукту, а потім написати тести вже під неї.
