Збережіть докази збою до перезапуску

Ілюстративний тест відкриває сторінку налаштувань, надсилає зміни та зазнає невдачі, оскільки очікуване значення ніколи не з'являється. Хтось публікує останній скріншот. Він показує порожню панель. Користувач вийшов із системи? Запит на збереження не вдався? Чи суперечило перевірка неправильному запису? Саме по собі зображення не може відповісти на ці питання.

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

Почніть з дії та її контексту

Playwright's Trace Viewer дозволяє перевіряти записаний тестовий слід із шкалою часу дії та відповідними знімками. Його документація описує перевірку джерела, помилок, консольного виведення та мережевої активності. Ці перегляди відповідають на різні запитання: що намагався виконати тест, що показала сторінка та що обміняла програма. Знімок екрана залишається корисним, але це один вид у більшому пакеті.

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

Передача з п'яти полів

Використовуйте п'ять полів для кожної невдачі: очікуваний результат, фактичний результат, перший невдалий крок, траса або розташування артефакту та умови відтворення. Під фактичним результатом розрізняйте отриману відповідь про помилку від відсутності видимого вмісту. За умов, зверніть увагу на відповідний початковий запис і чи міг його змінити паралельний тест.

Не дозволяйте поясненням агента замінити оригінальні докази. Впевнена розповідь є гіпотезою, поки її не підтвердить журнал дій або стан програми. Позначте підозрювані причини як підозрювані. Якщо артефакт недоступний, вкажіть цю прогалину, а не записуйте правдоподібну послідовність із останнього знімка екрана.

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

Виберіть, коли збирати слід

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

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

Захистіть пакет, перш ніж ділитися ним

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

Публічна сторінка AnyTest описує спостереження на кожному кроці та причини невдачі. Це корисний контекст продукту, але це не перевірка, що його результат ідентичний трасуванню Playwright. Зберігайте формати доказів постачальників окремо та перевіряйте, що насправді зберігає вибраний бігун.

Вимірюйте розслідування, а не кількість скріншотів

Під час пілотування запишіть хвилини від першої несправності до відтворюваного опису, а потім до підтвердженої причини. Відокремте час, витрачений на отримання відсутніх артефактів, від часу, витраченого на ремонт продукту. Agentic QA заощаджує час на розслідування, лише якщо докази придатні для використання, а рецензент може довіряти їх походженням. Менший пакет із відповідями на запитання краще, ніж великий архів, який ніхто не відкриває.