Как сообщать об ошибках
Автор: Магда Пьехота
Итак, ваша команда разработчиков создала это новое приложение для вашего клиента. Вы очень гордитесь этим и хотите показать это всему миру. Но прежде чем сообщить клиенту хорошие новости, вы должны протестировать приложение, чтобы найти ошибки, и ваша команда исправит их.
Найти ошибки относительно легко, вы просто используете приложение во всех возможных сценариях и проверяете, работает ли оно так, как должно работать. Что вас интересует, так это неправильное поведение приложения, сбои, сбои и так далее. Вещи, которые не были запланированы для приложения. И, конечно же, вы их найдете, но что дальше? Как показать их команде? Как сказать им, что и когда пошло не так?
Вы можете бежать к своим разработчикам каждый раз, когда находите ошибку, и показывать им, как вы с ней столкнулись. Иногда это даже работает. Но с командами разработчиков, разбросанными по всему миру, это может быть немного неудобно или даже невозможно. Вам нужен простой и подробный способ размещения описаний ошибок вместе с пошаговым руководством по их воссозданию.
В codequest мы используем шаблон для ввода отчетов об ошибках в наши пространства JIRA. Он очень точен, и если вы только будете его придерживаться, любой на самом деле сможет свободно сообщать об ошибках. Даже твой нетехнический клиент.
Вскоре вы приобретете отличные навыки отчетности, описывая ошибки вашей команде разработчиков с легкостью и быстротой, о которых вы даже не подозревали.
Итак, как мы сообщаем об ошибках? Вот небольшое пошаговое руководство:
Название ошибки
Дайте ему осмысленный, но короткий заголовок, например, «цвета круговой диаграммы отображаются неправильно».
Дата просмотра
Определите время, когда вы заметили ошибку — чем подробнее время, тем лучше. Вы можете поставить дату и точное время суток. Это важно для разработчиков.
Окружающая обстановка
В идеальной ситуации с обеспечением качества у вас будет три разных среды: разработка, подготовка и производство.
Каждый из них виден определенной группе людей в компании: -
- Разработка — это в основном то, чем занимаются разработчики компании. -
- Постановка предназначена как для разработчиков компании, так и для обзора клиентов.
- Производство предназначено для финального продукта, выпущенного для всего мира.
Чтобы помочь разработчику выявить ошибку, вам необходимо указать версию разработки среды, которую вы тестируете, и в которой заметили ошибку, а именно Development, Staging или Production.
Версии
Теперь укажите операционную систему и ее версию, в которой вы обнаружили ошибку, а также название программы и ее версию. Вы можете добавить названия и версии любого применимого программного обеспечения (например, веб-браузеров), установленного на вашем компьютере. Это важная часть информации, которая нужна вашим разработчикам для воссоздания ошибки в той же среде в их месте.
Описание ошибки
Далее следует краткое описание проблемы. Не забудьте оставить это чистое описание, здесь не используется повествование или разговорный язык.
приоритет
Когда описание готово, наступает время определить серьезность ошибки — действительно ли это что-то незначительное? Или, может быть, полная катастрофа, мешающая работе приложения? У вас есть пять уровней на выбор: Trivial, Minor, Major, Critical или Blocker. Используйте их, чтобы сигнализировать о важности проблемы вашей команде разработчиков.
Действия по воспроизведению
А теперь наступает сложная часть, момент, когда вы должны показать, насколько хорошо вы наблюдали за поведением приложения, пошаговое руководство, ведущее к воспроизведению внешнего вида ошибки в приложении. Дайте простые, но подробные инструкции о том, что делать. Ничего не предполагайте, а точнее предполагайте, что человек, который будет читать инструкцию, вообще не знаком с приложением. Чем подробнее будет ваш список инструкций, тем проще разработчику будет воссоздать и отследить проблему. Не паникуйте, действуйте методично, держите ноги на земле, а голову хладнокровной.
Фактическое поведение
В дополнение к чистому списку инструкций вам нужно добавить описание того, что происходит, когда вы следуете инструкциям. Не жалейте кровавых подробностей, чем больше, тем лучше. Ведь это и есть проявление описываемого вами бага!
Ожидаемое поведение
Здесь можно указать то, что вы ожидали, когда следовали пошаговому руководству. Опять же это нарратив, не будьте слишком экономны на словах. Это важная часть отчета об ошибке, потому что вы могли что-то неправильно понять или пропустить какой-то шаг, и знание того, что вы ожидали увидеть, поможет разработчику понять это.
Предпринятые шаги по устранению неполадок/тестированию
Если вы пытались исправить баг самостоятельно, напишите об этом. Опишите все, что вы делали — будь то перезапуск приложения, сброс устройства или проверка кода.
Если вы будете следовать нашему шаблону, вы скоро приобретете хорошие навыки сообщения об ошибках вашей команде разработчиков с легкостью и быстротой, о которых вы даже не подозревали. Все, что вам нужно сейчас, это научиться оставаться сосредоточенным, быть наблюдательным и обращать внимание на детали. Наблюдение за каждым вашим движением, каждым щелчком или нажатием имеет решающее значение, так как позже вы будете сообщать о них своим разработчикам.
Но если вы хотите стать хорошим тестировщиком приложений, это только начало пути…
