Как принимать работу у разработчиков и не пропустить проблемы
Практика3 минРедакция Innovialabs
Коротко
Принимайте работу по заранее согласованным сценариям на реальных устройствах, фиксируйте ошибки в трекере по единому шаблону и подписывайте акт только после проверки исправлений, оставив гарантийный период.
Как устроена нормальная приёмка
Приёмка — это не «посмотреть, всё ли красиво», а проверка по заранее согласованным критериям. Рабочий процесс выглядит так:
- До начала разработки согласуйте критерии приёмки для каждой функции.
- Получите сборку на тестовом стенде, а не на боевом сервере.
- Пройдите тестовые сценарии на нужных устройствах.
- Зафиксируйте ошибки в трекере по единому шаблону.
- Проверьте исправления и подпишите акт приёмки.
- Пользуйтесь гарантийным периодом для ошибок, найденных после запуска.
Если критерии не согласованы заранее, приёмка превращается в спор о вкусах.
Тестовые сценарии
Сценарий — это путь пользователя от начала до конца. Пишите их простым языком:
- «Новый пользователь регистрируется по номеру телефона, получает код, входит в личный кабинет».
- «Покупатель добавляет два товара, применяет промокод, оплачивает, получает уведомление».
- «Менеджер меняет статус заказа, клиент видит новый статус».
Проверяйте не только успешный путь, но и негативные случаи:
- неверный пароль, пустые поля, слишком длинный текст;
- отмена оплаты и повторная попытка;
- потеря интернета посреди действия;
- двойное нажатие на кнопку отправки;
- разные роли пользователей и их права доступа.
Устройства и окружение
Список устройств согласуйте заранее и опирайтесь на свою аудиторию.
| Что проверить | Почему важно |
|---|---|
| Популярные Android-смартфоны, включая недорогие | Слабые устройства выявляют проблемы скорости |
| iPhone с актуальной iOS | Safari ведёт себя иначе, чем Chrome |
| Десктопные браузеры | Вёрстка на широких экранах |
| Медленный мобильный интернет | Загрузка и обработка ошибок сети |
| Языковые версии | Длинные переводы ломают вёрстку |
Как писать баг-репорт
Плохой репорт: «Ничего не работает». Хороший содержит:
- Заголовок: что сломалось и где.
- Шаги воспроизведения: пронумерованные действия.
- Ожидаемый результат и фактический результат.
- Окружение: устройство, браузер, версия приложения, аккаунт.
- Скриншот или видео экрана.
- Критичность: блокирует работу, мешает, косметика.
Один баг — одна задача. Не смешивайте в одном сообщении пять разных проблем.
Акт приёмки
Перед подписанием проверьте:
- все критичные и серьёзные ошибки исправлены и перепроверены;
- косметические замечания либо исправлены, либо внесены в список с договорённостью о сроках;
- переданы исходный код, доступы, документация и инструкции по развёртыванию;
- в акте перечислены принятые функции или этап, а не просто «работы выполнены».
Подписанный акт обычно означает, что претензии по видимым недостаткам больше не принимаются. Поэтому не подписывайте его «авансом».
Гарантийный период
В договоре стоит прописать гарантию: в течение оговорённого срока подрядчик бесплатно исправляет ошибки, допущенные при разработке. Уточните:
- какой срок гарантии;
- что считается гарантийным случаем, а что — новой задачей;
- время реакции на гарантийные обращения;
- теряется ли гарантия, если код меняла другая команда.
Частые ошибки
- Проверять только на своём телефоне и своём аккаунте администратора.
- Принимать по скриншотам, а не на живом стенде.
- Присылать замечания голосовыми сообщениями.
- Подписывать акт до запуска, чтобы «не задерживать оплату».