Приёмочное тестирование (UAT) почти всегда проходит одинаково. Вы даёте группе людей — сотрудникам, команде клиента, нескольким бета-клиентам — доступ к сборке и неделю на то, чтобы её опробовать. В конце вы получаете таблицу.
В таблице шестьдесят строк. С пятнадцатью, может быть, можно сразу работать. Двадцать — это те же три бага, описанные пятью разными способами. Десять — «так и задумано». По десяти нужно задать уточняющий вопрос, прежде чем кто-то сможет начать. А ещё пять звучат примерно как «пытался сохранить, не сохранилось» — без указания страницы, браузера или дня.
Первое желание — винить обучение. Написать шаблон получше, провести занятие о том, как правильно заводить баги, требовать шаги воспроизведения. Это немного помогает и выветривается за пару недель.
Выветривается потому, что дело в устройстве самого процесса. Тестеры на UAT — не QA-инженеры, и просить их вести себя как QA-инженеры — значит просить того, чего такая схема не поддерживает.
Почему тестеры сообщают не обо всём
Три ограничения, и ни одно из них не про старание.
Они не видят доказательств. У тестера на UAT не открыты DevTools. Он не знает, что запрос вернул 500. Он видит спиннер, который так и не остановился, и записывает «всё зависло». Информация, по которой баг нашли бы за девяносто секунд, была у него на экране — за сочетанием клавиш, которое ему никто не показал.
Сообщить о баге дороже, чем он того стоит. Тестер, которому нужно переключиться на таблицу, найти нужные столбцы, описать контекст и сделать скриншот, сделает это ради падения. А съехавшую подпись и непонятное сообщение об ошибке он отметит в голове и пойдёт дальше. Хотя именно ради таких находок вы и собирали раунд UAT.
Они тестируют, а не документируют. Тестер в потоке исследует сценарий. Каждый перерыв на отчёт сбивает этот поток, поэтому отчёты откладываются на конец сессии — когда детали уже забылись, а воспроизведение давно перезаписано двадцатью следующими действиями.
Каждое из этих ограничений — свойство канала отчётов, а не человека. Поменяйте канал, и поведение изменится.
Встройте отчёты в то, что тестируют
Самое действенное изменение — перенести отчёты из отдельного инструмента в само тестируемое приложение.
Кнопка отчёта на странице снимает все три ограничения сразу. Переключаться никуда не нужно, поэтому отчёты отправляются в момент находки, а не пачкой в конце. Цена падает до одного клика, поэтому о мелких находках тоже сообщают. А браузер тут же, поэтому доказательства прикладываются, даже если тестер не знает, что это такое.
Так работает инструмент на основе виджета — BugDump ставится на стейджинг-сборку одним тегом script:
<script src="https://bugdump.com/sdk/latest.js" data-api-key="your-api-key"></script>Тестер нажимает кнопку, пишет «пытался сохранить, не сохранилось» и отправляет. Приходит эта фраза вместе с логом консоли, включая всё, что логировалось до открытия виджета, сетевыми запросами со статусами и временем, воспроизведением сессии, его кликами и вводом по порядку, а также браузером, ОС, вьюпортом и URL.
Тестер не стал лучше писать баг-репорты. Просто канал перестал выбрасывать доказательства.
Настройте специально под раунд UAT
Несколько решений в настройке важнее при тестировании, чем в продакшене.
Идентифицируйте тестеров. В продакшене вы можете не знать, кто прислал отчёт. На UAT вы знаете это всегда, и это стоит подключить: вызовите identify() с именем и почтой тестера, а setContext() — с назначенной ему ролью, тестовым аккаунтом и сценарием, который ему дали. Когда приходят четыре отчёта о правах доступа и видно, что все четыре от тестеров с ролью «только чтение», — это и есть диагноз.
Прикладывайте сборку. Добавьте хеш коммита или номер сборки в контекст. Раунд UAT обычно охватывает несколько деплоев, и без этого на вопрос «это всё ещё сломано после исправления во вторник?» не ответить.
Сделайте кнопку заметной. В продакшене неприметная плавающая кнопка — то, что нужно. На UAT — нет: включите подсказку рядом с кнопкой с текстом, который прямо говорит, чего вы хотите, — что-то вроде «Нашли что-то? Расскажите», а не молчаливая иконка. Тестеры, которые забыли про инструмент, присылают отчёты на почту.
Включайте тела запросов осознанно. Тела запросов и ответов — самое полезное, что можно приложить, и самое чувствительное. На стейджинге с синтетическими данными captureNetworkBodies обычно можно включать не раздумывая, и это убирает целый класс уточняющих вопросов. На раунде UAT с продакшен-данными и настоящими записями клиентов — нельзя: оставьте выключенным или отфильтруйте эндпоинты с персональными данными.
Отфильтруйте шум. Стейджинг шумный. networkFilter, который отбрасывает эндпоинты с опросом, и consoleFilter, который отбрасывает отладочную болтовню, делают отчёты гораздо читабельнее, а читабельные отчёты разбирают, а не откладывают.
Спрашивайте три вещи, а не двенадцать
Когда данные собираются автоматически, форма должна спрашивать только о том, чего никто, кроме тестера, не знает:
Что пошло не так — своими словами
Что ожидалось вместо этого
Как часто — впервые, иногда, каждый раз
Всё остальное — браузер, ОС, URL, консоль, сеть, время — приходит само.
Третий вопрос стоит отстоять, даже если хочется его убрать. «Каждый раз» или «иногда» — это разница между детерминированным багом и состоянием гонки, и от неё зависит, куда разработчик посмотрит первым делом. И частоту не даст никакое инструментирование: она хранится в памяти тестера о последних двадцати минутах.
Не добавляйте выпадающий список серьёзности. Каждый тестер выберет «Высокая», потому что изнутри заблокированного сценария высоким кажется всё. Частота плюс число людей, которые сообщили о проблеме, делают ту же работу на лучших данных.
Дубликаты — это и есть смысл
Привычный рефлекс после раунда UAT — считать повторные отчёты мусором: двадцать строк про три бага. Всё наоборот.
Пять человек, сообщивших об одной и той же сломанной кнопке сохранения, дают вам пять окружений, пять наборов шагов, пять сетевых логов. Если у четырёх из них Safari, а у одного Chrome с узким вьюпортом, причина известна ещё до того, как кто-то откроет код. Один отчёт об этом баге сказал бы гораздо меньше.
Вам нужно не меньше дубликатов, а такая структура, где они складываются в стопку, а не разлетаются. Именно поэтому BugDump разделяет отчёты и задачи: отчёт — это доказательства одного человека, задача — то, что вы в итоге исправляете, и к одной задаче прикрепляется много отчётов. Двадцать отчётов превращаются в шесть задач, у каждой — полный набор доказательств, и двадцать строк перестают быть мусором и становятся матрицей.
Если включить allowTaskAttach, тестеры могут прикрепить свой отчёт к существующей задаче по её публичному ID. Тогда «наверное, кто-то уже об этом сообщил» перестаёт быть причиной промолчать и становится подтверждением в один клик: у меня тоже так.
Отвечайте, иначе раунд умрёт
Самый надёжный способ убить участие в раунде UAT — молчание. Тестер, который отправил шесть отчётов в первую неделю и ничего не услышал, во вторую не отправит ни одного. Не из обиды: он просто понял, что отчёты ни на что не влияют, и он прав.
Это исправляют две вещи, и обе дешёвые.
Направляйте отчёты туда, где уже работает команда. Канал в Telegram, Slack или Discord, куда приходит сообщение о каждом отчёте, делает раунд живым для всех, включая тестеров. Если баги должны становиться issues, интеграция с GitHub Issues или Jira избавляет от перепечатывания таблицы в трекер.
Дайте тестерам страницу статуса. Публичный портал, где автор отчёта видит, как его задача переходит из «Подтверждено» в «Готово», — вот и весь механизм. Тот, кто видит, что его отчёт исправили, присылает следующий — и присылает его на третьей неделе, когда всплывают самые интересные баги.
Как это выглядит в конце раунда
Вместо таблицы — доска. Шестьдесят отчётов сжались в пару десятков задач, у каждой — доказательства от всех, кто на неё наткнулся. Бесполезных строк больше нет: поля, из-за которых с ними нельзя было работать, заполнил браузер, а не человек, который гадал, что важно.
Работа тестера вернулась к тому, какой и должна была быть: пользоваться программой и говорить, что показалось не так. Разбираться, что это значит, — работа разработчика, и теперь у него есть всё, что для этого нужно.
Бесплатного тарифа BugDump — 500 отчётов в месяц на проект, без карты — с запасом хватает на большинство раундов UAT, так что поставьте виджет на стейджинг-сборку за день до начала тестирования.
Читайте также
Как собирать баг-репорты от бета-тестеров и не терять половину — кнопка внутри продукта, автоматический контекст и ответ каждому тестеру.
От 40 отчётов к 6 багам: как должен работать триаж — как разделение отчётов и задач не даёт входящим превратиться в кладбище.
Как написать хороший баг-репорт (с чек-листом) — чек-лист для отчётов, которые человек пишет сам, и для тех, что собирает инструмент.