Як я спробував замінити себе на ШІ в реалістичних умовах роботи тестера
Привіт, друзі! Я — Льоша, автор блогу про тестування QAMania і один з ведучих подкасту «Питання Якості» на DOU. В одному з останніх випусків подкасту ми якраз обговорювали, чи замінить ChatGPT тестерів?
Нарешті я маю трохи часу, натхнення і оптимізму поекспериментувати та зважено проаналізувати, на що здатен чат в більш-менш реалістичних умовах роботи.
⚠️ Наразі є великі безпекові ризики використання чату, оскільки не зрозуміло, що він робить з даними, які ви йому передаєте. Тому я не раджу поки використовувати його в реальних проєктах... Чи, як мінімум, проконсультуйтесь з вашим керівництвом і офіцером з безпеки.
Та, на щастя, в рамках курсу з тестування ПЗ, ми розробили низку артефактів, включаючи декілька варіантів вимог різної якості, які можна запропонувати чату для аналізу. Що я і зробив, тож розберімо отримані результати.
❗️ Дослідження я проводив, використовуючи ChatGPT-4, розраховуючи отримати найякісніші результати.
Аналіз поганих вимог
Почати я вирішив з очевидно поганих вимог, в яких постарався зібрати всі можливі проблеми: текст в стилі «потік свідомості» і відсутність будь-якої структури, граматичні і логічні помилки, дивні побажання.
Оскільки чат сам каже, що йому комфортніше працювати англійською, я попросив його перекласти вимоги, що він зробив досить успішно, вловивши контекст.
Далі я попросив його описати мені ідею ПЗ в кількох реченнях, щоб дізнатись, чи розуміє чат контекст.
It's a Tamagotchi-style game where players feed, cure, clean, and interact with a virtual pet.
Далі я попросив його згенерувати мені use cases, і вийшло добре, враховуючи, наскільки бідні оригінальні вимоги.
Use Case: Feeding the Pet Actor: Player Preconditions: The pet is hungry. Postconditions: The pet's hunger level is decreased. Flow of Events: The player selects the 'feed' option in the game menu, and the pet's hunger level is decreased.
Далі я попросив проаналізувати мої вимоги згідно стандарту IEEE 830, що описує характеристики хороших вимог, такі як точність, однозначність і т.д. І нарешті отримав від нього трохи критики: структури нема, scope незрозумілий, опис програми поверхневий і не повний. Самі вимоги не містять нефункціональних деталей, обмежень до дизайну. І згідно стандарту, це взагалі на вимоги не схоже. 😁
Ну, ок, кажу. Якщо все так погано, сформуй мені список питань і уточнень, які я можу переслати відповідальному аналітику чи product owner’у, щоб усе покращити. І тут я отримав трохи крінжі. Наприклад:
- «У вимогах написано, що гра має бути цікава людям від 3 до 93, але може і ні, давай визначимо іншу авдиторію» — це нісенітниця, оскільки вказане речення — не вимога взагалі, і не має бути присутня в SRS.
- «Як гравцю відслідковувати прогрес?» — питання валідне, але невже це топ 2, що б ти питав? Невже твоє віртуальне око нічого більше не муляє?
- «Яка в грі буде стратегія монетизації? Може преміум зробимо чи вбудовані покупки?» — гри ще нема, а вже думає про прибутки. Впевнений, EA Games вже тобі раді. 😁
Далі я попросив його переписати текст у вигляді SRS, враховуючи найкращі практики, і, якщо даних не вистачає, — спитати мене чи додумати самостійно. Чат гарно все відформатував, але всю ту нісенітницю залишив з мінімальними змінами. А те, що він дописав, — краще б не робив. Чутливим аналітикам і тестерам пропоную підготуватися і прибрати дітей від екрана, ось одна з цитат:
The game should run smoothly and without delays in response to user actions.
Наступний крок аналізу — написання тест-кейсів. І чат впорався, хоч і не з першого разу. Довелось окремо його просити прибрати з тестів всі нелогічності й неоднозначності, які він тупо скопіював з тексту.
Вже наприкінці я попросив його зробити для мене шаблон тест-плану для моєї гри на 1 сторінку. І він видав більш-менш пристойний шаблон, але зміст точно доведеться редагувати самостійно.
Аналіз нормальних вимог
Для того, щоб не мати впливу контексту попередньої розмови, я створив новий чат і дав йому нормально написаний SRS, над яким ми чесно постарались, і яким я пишаюсь.
Потім спитав майже той самий список питань. Якість вимог згідно з стандартом IEEE 830 — тут чат нас похвалив 😄
Overall, your SRS document appears to be quite thorough and well-structured based on the sections you've shared. It adheres well to the IEEE 830 standard, providing clear, detailed, and precise requirements for your Circus Ticket Application.
Питання для подальшого аналізу згенерував непогані, але досить поверхневі. Може, якось навіть допрацюю документ, враховуючи кілька коментарів, але не більше.
Тест-кейси — з першої спроби написав досить поганенько. До рівня junior QA не дотягує. Точніше, як чек-лист — все просто супер. Розробляючи вимоги, ми спеціально робили деякі секції такими, щоб бути покритими різними техніками тест-дизайну, і чат успішно їх використав. Але він не зміг зробити нормальні кроки, і передумов замало:
Test Case 1 - Coupon Discount Preconditions: User is logged in and the coupon "DISC5" exists in the database. Input: Enter coupon "DISC5" during the ticket buying process. Expected Result: The final price should be discounted by 5% of the ticket's basic price.
Я трохи засмутився, а потім вирішив дізнатись, за скільки уточнень я зможу покращити тести до еталонного рівня і попросив вивести лише один тест для роботи. І чат його не просто вивів, а насипав деталей 🔥
Test Case ID: TC_LP_01 Test Case Description: Verify that the application correctly applies a 5% discount when a valid coupon number is entered. Preconditions: The Circus Ticket Application is installed and accessible. User is registered as a Customer in the application. User is logged in and has at least one ticket in the cart. Test Steps: 1. Navigate to the Shopping Cart page. 2. Input a valid coupon number in the 'Coupon Number' field. 3. Click on the 'Apply Coupon' button. Expected Result: The application should calculate a 5% discount on the ticket's basic price and display the updated final price. Postconditions: The cart contains a ticket with a discount applied to its basic price.
Тож, якщо одразу сформулювати, в якому вигляді ви хочете тести, може вийти пристойно.
На останок, знову попросив чат підготувати тест-план, і знову отримав непоганий шаблон, з яким можна працювати.
Окремо стало цікаво, чи зможе чат проаналізувати ризики, і попросив його надати список, вказавши для кожного вплив, імовірність і сценарій пом’якшення (mitigation). Але отримав список випадкових подій з випадковими цифрами. Йому явно не вистачило контексту проєкту розробки і питати більше деталей для аналізу ризиків чат навіть не намагався.
Висновки
Я пропрацював з чатом над кожним документом трохи більше години і можу коротко підсумувати мої враження:
- Аналітики і тестери можуть поки що спати спокійно — зробити пристойний системний аналіз навіть одного документу, ми, люди, все ще можемо краще. 😁
- Не зважаючи на те, що чат не бачить очевидних логічних проблем в тексті, він чудово розуміє контекст написаного, як би погано текст не був оформлений і його можна використати, щоб він почитав будь-яку маячню і видавав вам короткий переказ.
- На додачу до попереднього пункту — чат може виділити основні use cases і навіть накидати список тест-кейсів. Так, їх всі треба буде вичитати, але це може бути простіше, ніж писати їх руками. Особливо, коли написання тест-кейсів — необхідна формальність.
- А ще чат робить гарні шаблони будь-яких документів. Я просив тести, плани, звіти. Їх не обов’язково використовувати as is, але ви завжди можете звіритись, чи не пропустили якийсь пункт при плануванні роботи чи якусь метрику при підготовці тестового звіту.
- Чат — дуже потужний інструмент, але все ще інструмент. Якщо ви знаєте, що саме від нього хочете, і можете оцінити якість результату (а не прийняти його за істину) — він може зекономити вам час на читанні і написанні документів. Але зробити роботу за вас — точно ні, бо не має таких важливих якостей як ініціативність, допитливість і розуміння.
- P.S. А ще я почав активно використовувати його в програмуванні — шукає і пропонує рішення, які я, навіть знаючи вже відповідь, не зміг знайти ні в офіційній документації тих фреймворків, що використовую, ні на stackoverflow
18 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів