Приёмочное тестирование пользователями - это момент, когда люди, которым и предстоит работать с программой, решают, делает ли она их работу. Не работает ли она вообще - это уже проверено, - а делает ли она то, о чём просили, и так, что с этим можно жить.

Это единственный этап тестирования, цель которого - решение, а не список дефектов. Приёмка заканчивается тем, что кто-то говорит релизу да или нет.

Чем оно отличается от любого другого тестирования

Каждый предыдущий этап спрашивает, соответствует ли программа спецификации. Приёмка спрашивает, верной ли была сама спецификация.

Разница выглядит теоретической, пока не увидишь её вживую. Функция может пройти все функциональные тесты, выполнить каждый критерий приёмки ровно так, как он написан, и всё равно быть отвергнутой на приёмке, потому что человек, который делает эту работу триста раз в неделю, видит: теперь понадобится четыре клика там, где раньше хватало одного. Ничего не сломано. Неверным было требование, и это последний дешёвый момент, чтобы это выяснить.

Тестирование QA
Делает ли программа то, что мы обещали? Проводят тестировщики, сверяясь со спецификацией
Приёмочное тестирование пользователями
Делает ли она то, что нужно бизнесу? Проводят те, чья это работа, сверяясь с реальностью

Кто его проводит, а кто не должен

Те, кто будет этим пользоваться. Не команда разработки, не QA и не руководитель, который подменяет их собой.

Это труднее, чем звучит. Нужные вам люди заняты той самой работой, ради которой программа и написана, и их время - самая дорогая часть всей затеи. Именно поэтому приёмку, запланированную задним числом, отдают тому, кто свободен, а релиз потом подписывает человек, который никогда не делал работу, которой этот релиз служит.

Две роли стоит назвать вслух: тот, кому принадлежит решение и кто может сказать нет, и тот, кто собирает находки тестировщиков и превращает их в то, с чем разработчик сможет что-то сделать. Без первого приёмка производит мнения и никакого исхода. Без второго она производит таблицу, с которой никто не может работать.

Что нужно дать тестировщикам

Не список функций. Список того, что они делают обычно.

1. Провести нового клиента от заявки до первого счёта
2. Оформить возврат по заказу, оплаченному картой
3. Закрыть месяц, когда два филиала отчитываются раздельно
4. Исправить адрес в заказе, который уже отгружен

Это бизнес-процессы, и каждый из них пересекает несколько функций. Тестировщик, которому дали “проверьте экран счетов”, проверит экран счетов; тестировщик, которому дали “проведите нового клиента до первого счёта”, найдёт те два места, где процесс ломается между экранами, а именно там и живут настоящие проблемы.

Дайте им настоящие данные или ближайшую безопасную копию. Приёмка на базе с Тестовым клиентом с 1 по 20 не найдёт ни одной из проблем, которые клиент по имени “O’Brien & Sons (ранее Smith)” находит сразу.

Когда она закончена

До того как она начнётся, договоритесь, что значит “да”. Письменно и в словах, которые можно проверить.

  • Какие процессы обязаны работать, а каким позволено быть неудобными
  • Что считается блокером, а что чинится в следующем релизе
  • Кто подписывает и за что именно он подписывается
  • Сколько она длится. Приёмка без даты окончания не заканчивается; она угасает

Самая частая неудача - не плохой тест, а неясный финиш. Этап, который идёт, пока люди не перестанут о чём-то сообщать, заканчивается, когда им становится скучно, и релиз, уехавший на скуке, - это релиз, с которым никто не соглашался.

Сообщения, которые рождает приёмка

Это та часть, к которой команды разработки внутренне готовятся, и причина тут структурная, а не чья-то вина.

Ваши тестировщики - не тестировщики. Это бухгалтеры, диспетчеры, медсёстры, продавцы - и они описывают случившееся на языке своей работы, а не на языке программы. “Счёт ушёл не в тот филиал” - совершенно понятная фраза, и она невоспроизводима. В ней не хватает того, какой счёт, какой филиал, что было на экране и чего они ждали вместо этого.

Две вещи помогают больше всего остального:

Спрашивайте про порядок действий, а не про диагноз. “Что вы делали и чего ожидали?” уводит дальше, чем любая форма, потому что догадка бизнес-пользователя о причине обычно неверна и обычно вытесняет факты.

Заберите у них техническую часть. Никого на приёмке не следует просить о версии браузера, логе консоли или шагах, написанных для разработчика. Сделать это правильно - задача инструментов, и чем меньше вы просите у тестировщика, тем больше он сообщит.

Session Replay

Бесплатное расширение для Chrome. Один клик на странице, которая ведёт себя не так, захватывает скриншот, консоль и сетевой журнал и отдаёт вам ссылку, которую можно вставить в задачу.

Установить расширение

Тому, кто собирает сообщения, всё равно придётся превращать каждое в то, с чем разработчик сможет что-то сделать, и руководство по описанию ошибок - это та форма, которую оно принимает. Если находку приёмки не удаётся воспроизвести, её закроют нерешённой, какой бы настоящей она ни была.

Коротко

Приёмка спрашивает, делает ли программа работу, и решают это те, чья это работа. Дайте им процессы вместо экранов, настоящие данные вместо тестовых строк, согласованное определение “да” и как можно меньше технических домашних заданий. Пришедшее назад будет сформулировано на их языке, и превратить это в воспроизводимое - и есть работа, а не признак того, что они тестировали неправильно.