Чек-лист приёмки по записи демонстрации: как составить
Как составить чек-лист приёмки по демонстрации продукта: условия, действия, ожидаемый результат и доказательства. Пример проверки без выдуманных требований.
Успешная демонстрация не равна полной приёмке
На созвоне показали, как форма отправляет заявку, и всё выглядело убедительно. Но работа под другой ролью, повторная отправка или пустое обязательное поле могли вообще не обсуждаться. Запись демонстрации помогает восстановить показанное, а не доказывает проверку всех сценариев.
Чек-лист приёмки строится на заранее согласованных требованиях. Новая идея зрителя может быть полезна, но её нужно оформить отдельно. Иначе во время приёмки незаметно меняется объём проекта, а участники спорят уже о разных версиях задачи.
Подготовьте проверку по записи
Зафиксируйте версию и условия
Укажите, какую версию или сборку демонстрировали, кто показывал и под какой ролью. Запишите тестовые данные и окружение настолько подробно, чтобы другой проверяющий мог воспроизвести сценарий. Если часть условий неизвестна, не заполняйте её предположениями.
Свяжите пункт с требованием
Возьмите согласованное поведение и найдите соответствующий фрагмент записи. Один показ может закрывать несколько проверок, но каждая должна иметь отдельный ожидаемый результат. Для обязательного требования, которое не показали, создайте пункт со статусом «не проверено».
Опишите действие и ожидание
Вместо «проверить форму» напишите, какие данные ввести, что нажать и что должно произойти. Для ошибочного ввода укажите ожидаемую реакцию. Не включайте новый крайний случай как обязательство, если он не входит в утверждённые условия.
Проведите повторную проверку
Выполните сценарии на согласованной версии, зафиксируйте фактический результат и приложите доказательство. Ошибку, заблокированную проверку и отсутствие данных разделяйте. После исправления проверяйте затронутый сценарий повторно и сохраняйте новую дату.
Приёмка формы запроса консультации
Ниже — вымышленный учебный пример. Имена, условия и результаты приведены только для объяснения метода.
Телефон обязателен. При успешной отправке заявка появляется в списке, а посетитель видит подтверждение. Без телефона форма не должна отправляться.
Эта формулировка даёт три наблюдаемых результата: проверку обязательности, создание заявки и подтверждение посетителю. Красивый экран после клика подтверждает только одну часть.
Если доступ к списку заявок у проверяющего отсутствует, статус создания записи — «заблокировано для проверки». Нельзя заменить его отметкой «пройдено» по словам демонстратора.
| Проверка | Ожидание | Что сохранить |
|---|---|---|
| Пустой телефон | Сообщение об обязательном поле; заявка не создаётся | Экран и проверка списка |
| Корректные данные | Одна заявка с введёнными значениями | Запись в тестовом списке |
| Успешная отправка | Понятное подтверждение посетителю | Экран после действия |
Шаблон проверяемого пункта
Одна строка должна отвечать на вопрос, по какому наблюдению будет поставлен итоговый статус.
ID проверки: Согласованное требование: Версия / роль / окружение: Исходные данные: Действия: Ожидаемый результат: Фактический результат: Статус: пройдено / ошибка / не проверено / заблокировано Доказательство и таймкод: Связанное исправление: Дата повторной проверки:
Проверьте сам чек-лист перед запуском
- Пункты ссылаются на согласованный объём.
- Ожидание можно увидеть или измерить.
- Показанное на записи отделено от выполненного лично.
- У ошибок есть воспроизводимые условия.
Разберём детали
Нужно ли добавлять все замечания со встречи?
Сначала разделите дефекты относительно требований и новые пожелания. Пожелания стоит оценить и согласовать отдельно, чтобы приёмка не превратилась в бесконечное расширение проекта.
Можно ли принять результат только по видео?
Это зависит от согласованных правил приёмки. Видео может подтверждать показанный сценарий, но не заменяет непоказанные проверки. В документе нужно честно указать способ и границы проверки.