ChatGPT, Gemini та TestCraft. Як використовувати штучний інтелект у мануальному тестуванні

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Вітаю, спільното! Мене звати Діана, я тестувальниця з понад трьома роками досвіду. За цей час я мала досвід роботи у різних проєктах та доменах — від фінтеху до маркетингових платформ.

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

Як ШІ змінює рутину мануального тестування

Зазвичай мануальні тестувальники відповідають за оцінювання продукту, фокусуючись на real-user сценаріях і застосовуючи своє розуміння контексту, креативність та, у деяких випадках, інтуїцію — ті задачі, з якими ШІ справляється недосконало.

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

Генерування тестових даних

Одне з типових завдань тестувальника — згенерувати набір валідних та невалідних даних (ПІБ, номери телефонів, емейли й так далі) для проведення тестування. Штучний інтелект допоможе не витрачати на це час та створити набір даних згідно з вимогами, які ви пропишите у промті.

Інструменти:

  • ChatGPT
  • Claude.ai

Промпт:

Generate 3 valid and 5 invalid email addresses for testing a form field that only accepts Latin characters. The field allows only the following symbols: «@», ".","_«. It should not accept any other special characters, non-Latin letters, spaces, or missing parts (e.g., no domain, no @ symbol).

Приклади результатів:

Відповідь ChatGPT:

Відповідь Claude.ai:

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

Генерування тест-кейсів/чеклістів

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

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

Інструменти:

  • ChatGPT
  • Gemini
  • Claude.ai

Промт:

Write 5 positive and 5 negative test cases for the login function on this site rozetka.com.ua. Put into consideration all available login methods: phone number, Google, Apple, Facebook and email. The test case should contain the following fields: Summary, Preconditions (optional), Test steps, Expected result.

Приклади результатів:

Відповідь ChatGPT:

Відповідь Gemini:

Відповідь Claude.ai:

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

Оформлення баг-репортів

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

Інструменти:

1. Jam.dev — це розширення для браузера, яке спрощує репорт багів та допомагає QA зафіксувати баг та кроки його відтворення. Воно пропонує запис екрану, скріншоти, автоматичний збір системних даних (перегляд Headers, Console, Network). Внутрішній ШІ-агент пропонує опис бага з кроками, а також доступна функція AI debug, яка пояснює суть та можливу причину помилки, яка виникла. Можна одразу підключити інтеграцію із вашими інструментами на проєкті для пришвидшення роботи та покращення комунікації. Більш детально з особливостями роботи Jam.dev можна ознайомитись у моєму попередньому топіку.

2. GPT, Claude, Gemini — допоможуть з оптимізацією баг-репорту під шаблон вашого проєкту (формулювання у Jam.dev можуть бути недосконалі та недостатньо детальні).

Приклад роботи з Jam.dev:

Після відтворення багу за допомогою Jam.dev можна переглянути автоматично сформовані кроки відтворення, запити у Network, помилки у Console.

На скріні зліва бачимо відеозапис відтворення багу, справа розписані кроки відтворення, а також доступний перегляд вкладок Info, Console, Network, Actions, Backend, AI-Debug.

Приклад комунікації з AI-Debug на основі відеозапису багу:

AI-Debug проаналізував можливі причини виникнення багу та запропонував подальші дії. Наприклад, перевірити, чи немає помилки зі сторони юзера (пункт 2 — переконатись, що номер телефону та код передані у правильному форматі) — перш ніж заводити цей баг-репорт.

Написання звітів та перевірка текстів

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

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

Інструменти:

  • ChatGPT
  • Gemini
  • Claude.ai
  • Grammarly, LanguageTool, DeepL Write AI (перевірка тексту на помилки, перефразування)

Промт:

Write short monthly QA summary using these details:

*your details*

The summary should be clear, concise, and suitable for a manager or stakeholder. Keep the tone confident and structured.

Приклади результатів:

Відповідь ChatGPT:

Відповідь Claude.ai:

У порівнянні із СhatGPT, Claude.ai надав нам більш формальний та детальний репорт, який можна використовувати для комунікації щодо тестового прогресу. СhatGPT надав досить стисле самарі, яке підійде для більш неформального огляду тестового процесу. На мою думку, Claude.ai впорався із цієї задачею краще, але, звичайно, все залежить від ваших очікувань та встановлених процесів на проєкті.

Генерація тестових сценаріїв, автоматизація, перевірки a11y через інструмент TestCraft

Ще один ШІ-інструмент, який допомагає збільшити ефективність тестування та пришвидшити рутинні процеси — TestCraft.

Розглянемо, що саме можна виконувати за його допомогою.

1. Генерування ідей для тестування. Ви обираєте елемент на вебсторінці (кнопка Pick Element) та ШІ генерує вам ідеї для можливих перевірок функціоналу (кнопка Generate Test Ideas).

Ідеї, які запропонував TestCraft для перевірки різних способів логіну на сайт:

Ідеї для тестових сценаріїв згенеровані досить добре, але, як на мене, головний недолік — не враховані всі можливі форми логіну. Наприклад, поле «Номер телефону» залишилось неврахованим. Тому покладатися тільки на TestCraft при генеруванні списку тестових сценаріїв не варто, але як допоміжний інструмент він справився досить непогано.

2. Перевірка accessibility. TestCraft перевіряє вебсторінки на доступність, а також пропонує свої рекомендації, які варто зробити для зручності користувачів.

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

Переваги та ризики використання ШІ

Основні переваги застосування ШІ у моїй щоденній роботі:

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

Але, як і будь-яка технологія та інструмент, ШІ має свої недоліки, які не варто ігнорувати:

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

Як почати застосовувати ШІ у своїй QA-рутині

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

  1. Почати з однієї-двох конкретних задач — наприклад, написання тижневого/місячного QA-звіту або генерації чеклістів для задач. Не варто одразу намагатись робити всі задачі з ChatGPT тільки тому, що ШІ зараз у тренді — завжди оцінюйте раціональність застосування цих інструментів для конкретних задач :)
  2. Тренуватись у написанні промтів для отримання якісного результату — на початку можна вести нотатки з промтами, щоб потім не витрачати час на їхнє написання «з нуля».
  3. Обовʼязково перевіряти результат, який вам надає штучний інтелект. ШІ — це ваш помічник, але він не знає усіх тонкощів та особливостей вашого продукту і може надавати не зовсім адекватні та коректні відповіді. Якщо бачите якісь помилки — переформулюйте промт, уточніть деталі та попросіть пояснити результат.
  4. Не намагатись одразу зробити все ідеально — спочатку результат може бути недостатньо вражаючим, як ви очікуєте, але з регулярною практикою ШІ може значно пришвидшити рутинну роботу.

Висновок

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

На мою думку, ШІ не замінить мануальних тестувальників повністю, але наразі варто активно освоювати роботу з ним, щоб розуміти, коли і як це доцільно.

👍ПодобаєтьсяСподобалось23
До обраногоВ обраному10
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

ШІ треба давати доступи до документації проєкту, щоб там не було абракадабри. За умови, що вона є і актуальна. Наприклад, .md доки по API, PRD нових фіч.
Кожного разу описувати в промпті задачу і додавати файли прикладів, мені не виглядає полегшенням чи прискоренням. Схиляюсь до: один раз розробити інструкції та підключити різні MCP

Скажите. а если смысл самому писать апиху для тестирования? Например, мспользование собственного (самописного) API в сочетании с такими инструментами, как ChatGPT, Gemini и TestCraft в мануальном тестировании оправдано по нескольким причинам:
Гибкость и кастомизация. Самописное API позволяет тонко настраивать взаимодействие с системами ИИ и автоматизации под специфические задачи вашей команды разработки, бизнес-процессы и тестовые сценарии, чего нельзя достичь при использовании стандартных внешних интерфейсов.
Интеграция с внутренними системами. Часто бывает, что требуется связать AI с внутренними базами данных, системами баг-трекинга, CI/CD пайплайнами, что возможно только через собственные API, учитывающие особенности архитектуры проекта.
Безопасность и контроль данных. Самописное API обеспечивает более полный контроль с моей точки зрения над потоками данных, позволяет ограничивать доступ, а также реализовывать внутренние политики защиты, что критично для конфиденциальной информации при тестировании.
Оптимизация производительности. Самостоятельная разработка API даст в будущем возможность реализовывать оптимизированные алгоритмы кэширования, балансировки нагрузки и обработки, что повышает общую скорость и отзывчивость системы автоматизации тестирования.
Адаптация под новые задачи и технологии. В быстро меняющейся среде ИИ также быстро меняются технические требования, бывает, несколько раз, некоторые вещи не були учтены заранее и так далее поэтому автоматизации возможность модифицировать API под новые требования и интеграции может является большим преимуществом.Были ли у вас подобные кейсы, если да, то можете рассказать если это конечно не секрет?

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

Дякую за коментар! Крім того, що зазначала у статті, ШІ можна застосовувати для аналізу логів і виявлення «критичних» кейсів при тестуванні функціоналу. Більше прикладів можна знайти у QA-спільнотах та на LinkedIn (там обговорюють безліч ШІ-інструментів, відгуки щодо їх використання, реальні результати).

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

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

Дякую за ваш коментар. У статті представлені можливі варіанти застосування ШІ у вашій роботі, кожен може обирати для себе, які задачі йому виконувати за допомогою ШІ. Як і зазначала раніше, треба перевіряти результат, щоб не допускати «зайву абкарадабру» — в принципі, як і при виконанні технічних завдань/написанні коду через ШІ.

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

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

Підтримую. Написати шматок коду, порадитись як з «жовтою качечкою» — так. Але коли просили написати тест-кецс по заданих умовах acceptance criteria, то була дурня, бо ШІ не в контексті. Наприклад в нас є копіювання без оновлення даних, а є копіювання з оновленням даних і контенту. Але «копіювання з оновленням даних і контенту» це одна функціональність, а не або-або. А ШІ написав ТК ніби це різне. Короче довше писати ШІ правильний промт/редагувати результат/навчати його контексту, ніж самій написати
Тим більше, що в роботі дозволений тільки певний ШІ. І хоч він на основі openAI, але всеодно тугіший.

Підписатись на коментарі