Приёмочное тестирование силами сотрудников — это пять рабочих дней, в течение которых будущие пользователи проходят заранее написанные сценарии на копии боевых данных и сдают замечания по единой форме. Оно ищет не ошибки в коде: их находит подрядчик. Оно ищет расхождение между тем, как система устроена, и тем, как в компании на самом деле работают, — а это расхождение не видно ни на демонстрации, ни в техническом задании.
Модельный пример на всю статью: оптовая компания на 60 человек, проект внедрения на 850 000 ₽, три роли пользователей — менеджер по продажам, кладовщик, бухгалтер. В прогоне участвуют семь человек, сценариев 31, календарь — одна рабочая неделя перед приёмкой этапа.
Здесь речь именно про организацию прогона: сценарии, график, часы, форма замечания. Юридическая сторона — протокол, классы замечаний, мотивированный отказ и сроки устранения — разобрана отдельно, в материале про приёмку работ по автоматизации. Одно без другого не работает: без процедуры замечания повисают, без прогона процедуре нечего оформлять.
Откуда берутся сценарии и сколько их нужно
Единица проверки — операция целиком, от начала до результата: «менеджер принимает заявку из письма и доводит её до отгруженного заказа». Не «открыть карточку», не «нажать кнопку» — экраны проверяет разработчик. Правило составления простое: один сценарий на каждую операцию, которую сотрудник выполняет не реже раза в неделю, и ещё один на каждое исключение, случающееся не реже раза в месяц.
| Роль | Основных сценариев | Сценариев-исключений | Всего |
|---|---|---|---|
| Менеджер по продажам | 9 | 5 | 14 |
| Кладовщик | 6 | 3 | 9 |
| Бухгалтер | 3 | 2 | 5 |
| Сквозные, через все три роли | 2 | 1 | 3 |
| Итого | 20 | 11 | 31 |
Ориентир для проекта на три роли — 25–40 сценариев. Меньше пятнадцати означает, что процесс описан не полностью: скорее всего, пропущены исключения. Больше пятидесяти в пять дней не помещается физически, и тогда прогон разбивают на два этапа по ролям. Исключения — самая ценная треть списка: именно там живут заявки без адреса, возвраты частями, отгрузки задним числом и клиенты, у которых два юрлица с одинаковым названием.
Из трёх источников за один час: журнал заявок за прошлый месяц с отбором нетиповых, список ситуаций, из-за которых сотрудники звонят руководителю, и колонка «примечание» в текущей таблице. Если карта процесса собиралась на обследовании, исключения уже перечислены в ней — их достаточно переписать в сценарии, а не выдумывать заново.
Горизонтальная лента на пять рабочих дней с подписями. День 1 — «Разбор системы и один сценарий вместе с инженером, 2 ч». День 2 — «Основные сценарии своей роли, 3 ч». День 3 — «Исключения и плохие данные, 2,5 ч». День 4 — «Сквозной прогон: заявка проходит все три роли, 2 ч». День 5 — «Повторная проверка исправленного и протокол, 1,5 ч». Под лентой три дорожки с часами по ролям: «Менеджеры, 3 человека — 11 ч каждый», «Кладовщики, 2 человека — 8 ч», «Бухгалтер — 6 ч», плюс отдельная дорожка «Координатор — 14 ч». Справа итог: «69 человеко-часов, 68 764 ₽». Чертёжный стиль, подписи по-русски.
Пять дней: график, часы и деньги
Прогон устроен по нарастающей: сначала человек проходит один сценарий вместе с инженером и учится сдавать замечания, потом свои основные операции, потом исключения, потом сквозной случай, где заявка идёт через все роли подряд. Последний день — только повторная проверка того, что успели починить. Разносить эти дни по неделям нельзя: система за это время меняется, и половина замечаний устаревает вместе с ней.
- 1День 1 — 2 часа
Короткий разбор системы и один сценарий, пройденный вместе с инженером подрядчика. Здесь же участник заполняет свой первый бланк замечания под наблюдением — дальше он делает это сам.
- 2День 2 — 3 часа
Основные сценарии своей роли, по порядку. Самый плотный день: у менеджера это девять сценариев, у кладовщика шесть.
- 3День 3 — 2,5 часа
Исключения и плохие данные: заявка без адреса, возврат частями, клиент с двумя юрлицами. Именно здесь находится большая часть блокирующих замечаний.
- 4День 4 — 2 часа
Сквозной прогон: одна заявка проходит через все три роли подряд, от письма клиента до отгруженного и проведённого заказа. Участвуют все одновременно.
- 5День 5 — 1,5 часа
Повторная проверка только того, что подрядчик успел починить за три дня, и подписание протокола. Новые сценарии в этот день не запускают.
Координатор — обычно руководитель подразделения, в котором внедряется система, и его 14 часов складываются из четырёх на подготовку списка сценариев и графика, семи на присутствие все пять дней и трёх на сведение протокола. Это единственный человек, которого нельзя заменить: без него замечания расползаются по чатам и личным сообщениям, а на приёмке выясняется, что половина из них никем не зафиксирована. Ставки в расчёте — полная стоимость часа: оклад со взносами, отпуском и рабочим местом, делённые на реально доступные часы.
Сравнивать эту сумму надо не с нулём, а с ценой одного непроверенного сценария. В том же модельном проекте пропустили редкий случай: скидка по договору не переносилась в накладную при частичной отгрузке. Дефект нашли на шестой неделе эксплуатации, к этому моменту он задел 200 документов — по 40 накладных в неделю в течение пяти недель. Ручной пересчёт и перевыставление заняли по 15 минут на документ, то есть 50 часов бухгалтера по 844 ₽/час — 42 200 ₽, плюс 6 часов на повторную сверку с двумя контрагентами — ещё 5 064 ₽. Итого 47 264 ₽, почти 69 % стоимости всего пятидневного прогона, за один сценарий.
Прогон идёт на обезличенной копии боевой базы, а не на выдуманных записях: только там встречаются названия в 120 символов, скидки в копейках и заказы, оформленные в 23:40. Как готовят такой контур и что в нём заменяют — в материале про обезличенные данные для тестового контура.
Форма замечания: шесть полей
Замечание вида «не работает выгрузка» стоит подрядчику часа переписки и заказчику дня ожидания. Поэтому форма фиксированная, шесть полей, и заполняется она в момент, когда сотрудник упёрся, а не вечером по памяти. Единственное поле, которое сотрудник не заполняет, — класс замечания: его ставит координатор, чтобы не спорить о важности с каждым участником отдельно.
- 1Номер сценария. Не «в заказах», а «сценарий 12». Без номера непонятно, что именно проверялось и по какому пункту задания.
- 2Шаги до сбоя. Три-четыре строки в повелительном наклонении, чтобы инженер повторил ровно то же самое.
- 3Ожидаемый результат. То, что записано в сценарии: «в документе появляется скидка 7 %».
- 4Фактический результат. Что произошло вместо этого, с числом или текстом ошибки дословно.
- 5Свидетельство. Снимок экрана либо номер созданного документа — по нему инженер найдёт запись в журнале.
- 6Кто и когда. Имя и время: без них невозможно ни уточнить, ни позвать на повторную проверку.
Собирать замечания в общем чате — самая частая и самая дорогая ошибка организации прогона. В чате нет структуры, нет статуса и нет истории: через два дня никто не может сказать, какие из тридцати сообщений уже исправлены. Подойдёт что угодно с таблицей и статусами — от общей таблицы на диске до задачника, — лишь бы у каждого замечания был свой номер и своё состояние.
Абстрактный нарисованный бланк, не скриншот продукта. Шесть подписанных граф сверху вниз: «Номер сценария», «Шаги до сбоя», «Ожидаемый результат», «Фактический результат», «Свидетельство: снимок или номер документа», «Кто и когда». Все шесть заполнены рукописным начертанием на примере сценария 12 со скидкой 7 %. Внизу отдельная графа с двойной рамкой и пометкой «заполняет координатор»: три квадратика с подписями «блокирующее», «существенное», «косметическое». Сбоку от бланка перечёркнутый прямоугольник с надписью «общий чат». Чертёжный стиль, подписи по-русски.
Дефект или пожелание: правило на входе
Половина того, что приносят сотрудники, — не дефекты, а идеи: «а можно, чтобы сумма считалась сама», «нам бы ещё колонку». Это ценный материал, но он не про сдачу этапа. Разделять поток надо в момент сбора, а не на разборе: иначе список замечаний распухает, приёмка стоит, а подрядчик справедливо отказывается делать бесплатно то, чего не было в задании.
Если сотрудник может назвать номер сценария, в котором ожидаемый результат описан иначе, чем получилось, — это дефект и он идёт в протокол. Если номера нет и ожидаемого результата в сценарии не написано — это пожелание, и оно идёт в список второй очереди. Спорные случаи — а их обычно два-три на прогон — решает координатор вместе с владельцем процесса, и решение записывается, чтобы не пересматривать его через неделю.
Список второй очереди — обычная таблица с тремя колонками: что предложили, кто предложил, оценка в часах от подрядчика. Оценку запрашивают не сразу, а после запуска: через месяц эксплуатации примерно треть пожеланий отпадает сама, потому что люди привыкают к новому порядку и понимают, что колонка была нужна старому. Оставшиеся идут через нормальную процедуру изменения требований — она описана в разборе про изменения по ходу проекта.
Два столбца рядом, ось в рублях. Левый — «Пятидневный прогон, 69 человеко-часов: 68 764 ₽», разбит на четыре сегмента с подписями по ролям: менеджеры 29 700 ₽, кладовщики 8 800 ₽, бухгалтер 5 064 ₽, координатор 25 200 ₽. Правый, чуть ниже и с другой штриховкой — «Один пропущенный сценарий: 47 264 ₽», разбит на два сегмента: «пересчёт 200 накладных, 50 ч — 42 200 ₽» и «повторная сверка с контрагентами, 6 ч — 5 064 ₽». Между столбцами подпись «69 % стоимости прогона — за один сценарий». Чертёжный стиль, подписи по-русски.
Формальный прогон: признаки и лечение
Саботаж на приёмочном тестировании почти никогда не выглядит как отказ. Он выглядит как аккуратно заполненный лист, где все 14 сценариев отмечены «ок» за двадцать минут. Причина обычно не в злом умысле, а в том, что часы никто не выделил: у человека своя дневная норма заявок, и прогон он проходит поверх неё.
- Все сценарии «ок» и ни одного замечания. На первом прогоне так не бывает: нормальный результат — 8–15 замечаний на 31 сценарий, из них два-три блокирующих.
- Замечания приходят голосом и в чат. Значит, форма неудобна или её не объяснили. Лечится десятью минутами на первом дне, когда участник заполняет один бланк под наблюдением.
- Прогон закончился раньше графика вдвое. 31 сценарий физически не проходится за час: только сквозной случай занимает 20–30 минут.
- «Мне некогда, у меня заявки». Это правда, и это ошибка планирования, а не сотрудника. Часы должны стоять в графике, а на время прогона нужна подмена — иначе вы просите человека выбрать между своей выработкой и вашим проектом.
Рабочее лекарство одно и стоит почти ноль: координатор берёт три случайных сценария из отмеченных «ок» и проходит их сам вместе с автором. Если два из трёх воспроизводятся с расхождениями, прогон переназначают, и это уже никого не удивляет. Считать при этом надо не количество найденных замечаний, а количество честно пройденных сценариев: премия за отсутствие замечаний гарантированно даёт лист, в котором всё хорошо. Более глубокие причины сопротивления разобраны отдельно — почему сотрудники саботируют внедрение.
Когда пятидневный прогон не нужен
Процедура рассчитана на систему с интерфейсом, в которой ежедневно работают люди. Есть три случая, когда её проводить незачем, и в каждом дешевле сделать что-то другое.
- Сценариев меньше десяти и роль одна. Уведомления о новой заявке, автоматическая выгрузка отчёта, один бот на входящие сообщения — здесь хватает двух часов и трёх человек, а пять дней превращаются в ритуал.
- У системы нет пользовательского интерфейса. Фоновый обмен между 1С и складом сотрудники проверить не могут в принципе: там нужно интеграционное тестирование со стороны инженеров, а от людей — только сверка итоговых цифр.
- Замена системы один в один без изменения процесса. Если порядок работы не меняется, проверять надо перенос данных и права доступа, а не сценарии: люди делают то же самое, что делали вчера.
И честное ограничение самой процедуры. Пятидневный прогон не заменяет обучения: человек, впервые увидевший систему на тестировании, найдёт много замечаний про непонятность и мало — про существо. Поэтому короткий разбор перед прогоном обязателен, и это отдельная строка сметы — что бывает, когда её вычёркивают, мы считали отдельно. И не гарантирует прогон полноты: 31 сценарий покрывает частые случаи, а редкие всплывут в первый месяц эксплуатации. Для них существует гарантийный период, а не ещё одна неделя тестирования.
