DF-ПРО-005 · Как проходит работа
Как описать ошибку программы, чтобы её смогли повторить
- какие условия и версии нужно указать
- как записать воспроизводимые шаги
- чем отличаются ожидаемый и фактический результаты
- какие файлы приложить и как проверить их перед отправкой
Форма отправлена, но заявка не появилась в системе. Что написать разработчику: форма не работает или подробный рассказ обо всём, что происходило с утра? Ни один вариант не помогает быстро найти причину.
Полезное описание ошибки устроено как небольшой проверяемый сценарий. В нём есть исходные условия, последовательность действий, ожидаемый результат и то, что произошло фактически. Другой человек должен пройти те же шаги и увидеть тот же сбой либо точно зафиксировать, что повторить его не удалось.
Скриншот и запись экрана дополняют этот сценарий, но не заменяют его. Разработчику всё равно нужны версия программы, устройство или браузер, использованные данные и частота появления ошибки.
Что записать до обращения к разработчику?
Короткий заголовок должен отличать эту ошибку от остальных. Укажите действие и наблюдаемый сбой: после загрузки файла отчёт остаётся пустым. Формулировка ничего не работает не показывает ни место, ни условие возникновения проблемы.
Следом опишите среду: название и версию программы, операционную систему, браузер, тип устройства. Для веб-сервиса полезны адрес раздела и роль пользователя. Для интеграции — системы, между которыми передавались данные, без паролей и других секретов.
Важно и время появления ошибки. Если вчера тот же сценарий работал, укажите дату последней успешной проверки и что изменилось после неё: обновилась программа, появился новый шаблон файла, поменялась учётная запись или настройка.
Ошибка может возникать всегда, иногда или быть замеченной один раз — это тоже нужно записать. Mozilla в официальных рекомендациях советует указывать воспроизводимость и оформлять разные проблемы отдельными обращениями. Так в одной задаче не смешиваются сбои с разными причинами.
Как составить шаги воспроизведения?
Сначала верните программу в понятное исходное состояние. Например: пользователь вошёл с ролью менеджера, открыт раздел Импорт, выбран файл формата XLSX. Если для сбоя нужна особая настройка или запись в системе, назовите её до первого действия.
Затем перечислите действия по одному. Вместо обработать файл напишите: нажать Загрузить, выбрать orders-29-10.xlsx, дождаться окончания обработки, открыть отчёт за 29 октября. Не добавляйте шаги, которые не влияют на результат.
После последнего шага разделите два поля:
- Ожидаемый результат — что должно произойти по требованиям или по ранее работавшему сценарию.
- Фактический результат — что видно на экране, включая полный текст ошибки, состояние кнопок и созданные записи.
Не подменяйте наблюдение догадкой о причине. Фраза база данных не отвечает — предположение, если вы не проверяли соединение. Фраза после нажатия Сохранить появляется код 504, а запись в списке отсутствует — наблюдаемый результат.
Какие материалы действительно помогают?
Приложите скриншот, если на нём видны состояние интерфейса и полный текст сообщения. Оставьте системную дату и нужную область экрана, но уберите вкладки, уведомления и поля, не относящиеся к проверке. Microsoft отдельно рекомендует обрезать чувствительные и посторонние фрагменты перед отправкой снимка.
Для ошибки, которая развивается в несколько действий, полезнее короткая запись экрана. Начните её с исходного состояния и закончите сразу после появления сбоя. Рядом всё равно оставьте текстовые шаги: по видео трудно искать конкретное значение или сравнивать две проверки.
Логи, дампы и диагностические отчёты прикладывайте только за подходящий период и для нужного компонента. Перед отправкой проверьте файлы на токены доступа, пароли, персональные данные, содержимое документов и внутренние адреса. Если удалить лишнее без повреждения диагностики нельзя, согласуйте безопасный способ передачи.
Для ошибки на определённых данных подготовьте минимальный пример. Удаляйте строки, поля и зависимости по одному, пока проблема ещё повторяется. В документации Microsoft для C++ такой пример описан как минимальный, самодостаточный сценарий: тот же принцип помогает и при проверке форм, импортов и интеграций.
Как проверить описание перед отправкой?
Пройдите собственную инструкцию с начала, лучше в новой сессии или на тестовой учётной записи. Если пришлось вспомнить незаписанную настройку, уточнить имя файла или выполнить дополнительное действие, внесите это в шаги.
Проверьте, отвечает ли описание на шесть вопросов: где возникла ошибка, в какой версии, при каких данных, после каких действий, что ожидалось и что произошло. Затем сверьте результат с критериями приёмки программы, если они были согласованы. Это помогает отделить дефект от новой функции, которой не было в требованиях.
Сохраните исходные материалы до завершения проверки: файл, точное сообщение, время события и диагностические данные. После исправления повторите тот же сценарий на той же версии данных, а затем проверьте соседний рабочий сценарий. Исчезновение сообщения само по себе ещё не подтверждает, что операция завершилась правильно.
Описание ошибки можно включить в согласованный порядок работы и приёмки. На странице как проходит работа показано, где фиксируются требования, замечания и повторная проверка результата. Главное — сохранить связь между конкретным требованием, наблюдаемым отклонением и способом убедиться, что оно устранено.
Источники
Deskforge на связи
Где нас найти
Нажмите на карточку или наведите камеру на QR-код.