В предоставленной ниже статье будут подробно рассмотрены ошибки, которые совершаются при составлении описания бага в баг-трекинговых системах, а также, описаны бесценные советы для всех начинающих тестировщиков, которые находяться на старте своего карьерного пути.
Ошибка №1. Использование принципа «что, где, когда» в ситуации, когда «где» и «когда» должны быть пропущены
По правде говоря, внутри темы, не всегда обязательно использовать ответы только на вопрос «что?».
Некоторые ситуации требуют пропуска «где и когда», но только в случае, если они точно не могут нести в себе никакой информативности.Это значит, что при составлении темы необходимо всегда придерживатся формата записи бага «что, где, когда», постоянно следовать именно такой последовательности, но не забывать и про здравый смысл, иногда пропуская ответы на те вопросы, которые могут нарушить лаконичность, дублировать данные или попросту не важны по своей сути в определенной ситуации.
Неверный вариант / Корретный вариант
Одно из изображений слайдера не отображается на слайдере при входе на сайт. / Одно из изображений слайдера не отображается на слайдере.
Ошибка №2. Нет префикса внутри темы баг-репорта
Что представляет собой префикс? Очень просто – именно то, что необходимо вписывать перед темой, когда проводится проверка работоспособности приложения или тестирование другого веб ПО на смартфоне или в игре (наименование браузера, тип устройства, название версии операционной системы, региональные настройки игры).
Изучив префикс, тестировщик сразу же может может понять в каком именно тестовом окружении выполнялась проверка и как верно составить сообщение для разработчиков.Ошибка №3. Избыточность текста в предусловиях
Подобная проблема крайне актуальна только при очень большом количестве действий в предусловиях и низком количестве тестовых шагов.
Предусловие, по большому счету, не всегда необходимо. Если есть необходимость указать определенные данные, которые крайне важны для старта воспроизведения бага и число их очень большое, чтобы помещать внутрь тестовых шагов, тогда смело можно писать их внутрь предусловий.
Но не стоит забывать о том, что данные в них должны быть корректно сформулированными и понятными, и ни в коем случае нельзя туда (в тело предусловий) переносить тестовые шаги.Ошибка №4. Полное отсуствие важных дополнительных данных или шагов для воспроизведения дефекта
Бывает так, что изначально не указаны данные касательно роли пользователя или непосредственно его регистрационные данные, если ошибку можно воспроизвести только под аккаунтом определенного пользователя.
Кроме того, крайне важно добавлять тестовые шаги, которые необходимы для воспроизведения бага, так как без них очень сложно будет воспроизвести ошибку.Если ошибка будет заведена в баг-репорт, например, баг касательно нерабочего функционала в игре, стоит отдельной строкой указать платформу, где было воспроизведение дефекта с версией ОС и номер билда, на котором непосредственно выполнялась проверка.
Подобные уточнения крайне важны для того, чтобы программист самостоятельно мог воспроизводить ошибки на актуальном рабочем окружении и в актуальной версии рабочей сборки ПО.
Ошибка №5. Нет описания или отсутствует ссылка на главный домен в теле тестового шага
Как известно, в первом шаге, традиционно, всегда указывается ссылка на главный домен веб-продукта. Именно с этого действия всегда начинается процесс воспроизведения дефекта.
Если указать ее с явной ошибкой, могут возникнуть некоторые недопонимания между тестировщиком и программистом, который должен браться за исправление найденной ошибки.Именно с таких мелких деталей, иногда, возникают серьезные затягивания в процессе валидации и верификации бага, что может негативно повлиять на время выполнения тестов и проведения исправлений багов на их основании.
Ошибка №6. В шагах внесены ссылки на определенные страницы веб-сайта
В тестовых шагах должна быть только одна ссылка, только на первом тестовом шаге и исключительно на главный тестовый домен.
Это необходимо для ситуаций, когда веб-адрес страниц может меняться. Вместо прямых ссылок необходимо добавлять наименования нужных страниц и тестовые шаги, которые описывают, как к данным страницам можно быстро перейти.
Ошибка №7. Подробное описание ошибок в последнем тестовом шаге
В самом последнем шаге нужно обратить внимание на область с багом. Именно так программист или другой QA-инженер смогут быстро понять, на какой именно части ПО ему необходимо акцентировать свое внимание, чтобы самостоятельно обнаружить баг.
Не стоит описывать сам баг. Пусть его толкование будет отложено для прочих атрибутов баг-репорта.
Самый последний шаг предназначается для того, чтобы обратить внимание программиста именно на то место, где всегда воспроизводится ошибка.
Подобные действия помогут быстро найти баг, еще не ознакомившись со скриншотом или видеофайлом.
Ошибки при составлении описания бага
Ошибка №8. Один из результатов описан в форме отрицания другого
Конечно же, любой фактический результат и ожидаемый результат должны быть противоположны друг другу.
Описывать каждый из них нужно как более ожидаемый итог, чем просто добавлять к полученному фактическому результату слово «не», ведь не всегда подобного описания будет достаточно.Очень часто, подобные ситуации не дают программисту полной картины того, как именно должна выглядеть система и какая функциональность в неё заложена по требованию клиента, а какая является ошибочной.
Неверный вариант
Фактический результат: отображение системной ошибки на форме регистрации в поле ввода пользовательского номера телефона.
Ожидаемый результат: не отображается дефект на форме ввода номера телефона в соответствующей форме.
Корректный вариант
Фактический результат: отображение ошибки на форме ввода телефона после ввода валидного значения в соответствующее поле.
Ожидаемый результат: наблюдается успешная авторизация пользователя в системе после ввода корректных данных в поле формы ввода телефона.
Ошибка №9. Лишние атрибуты на скриншоте или отсутствие требуемых
Фото или видеофайл должны полностью отображать видимость используемой части веб-страницы в браузере с адресной строкой.В случае фото, на место бага должен указывать красный квадрат или направлена графическая линия.
Полное отсутствие указанных элементов или наличие лишних, отвлекающих внимание менеджера проекта, а затем и программиста, неуклонно является следствием некорректного фиксирования бага. А это лишнее время и все сопутствующие ему расходы и потери.
Ошибка № 10. Присутствие на видеозаписи посторонних или отвлекающих звуков и шумов
Для процесса снятия видео с экрана можно заручится помощью разнообразных программ и приложений.
Одна из частых ошибок при записи видео – наличие постороннего звука.
Подобные вещи решаются очень просто: при записи видео необходимо отключать возможность записи аудиодорожек.При подобном подходе фиксации бага, все внимание разработчика будет сфокусировано исключительно на ошибке.
Ошибка №11. Постоянное отображение ненужных уведомлений на скриншоте или видео
Создавая скриншот или записывая видеоролик, тестировщику необходимо убедится в том, что там нет никаких посторонних атрибутов и элементов.Ведь такие объекты могут отвлекать от багов и могут (но не всегда) содержать конфиденциальную информацию пользователей.
Ошибка №12. Наличие «простого» скриншота при сложном описании функционального дефекта
Для любого функционального бага, порой, недостаточно одного простого скриншота с отмеченной ошибкой.
Нужно отобразить все выполненные шаги, которые привели тестировщика к багу, и соединить их в одну последовательную коллекцию снимков.Приветствуется запись бага в формате короткого, но информативно наполненного видеоролика.
Ошибка №13. Наличие нескольких акцентов на скриншотах
Если добавить на один снимок больше одной области с выделенным багом и нарисовать множество графических стрелок, читающий баг-репорт человек может запросто запутаться в предоставленной ему информации.
Выделять графически нужно непосредственно сам баг, а не всю страницу, на которой данная ошибка появилась.Также, не нужно добавлять несколько стрелок к одному прямоугольнику или выделять один баг сразу двумя прямоугольниками.
Ошибка №14. Фиксирование бага на скриншоте цветом, который не контрастный с цветом дизайна
На всех скриншотах принято выделять проблемные участки красным прямоугольником и красной стрелкой.
Но если объект ПО имеет цвет очень близкий к красному, то выделять баг необходимо иным контрастирующим с фоном цветом.Ошибка №15. Отсутствие видео крэшов с устройств и файла логов во вложении к описанию бага
Описывая дефект, где есть сбой в функционировании программного обеспечения, нужно обязательно добавлять видео ошибки и желательно файл с логами.Именно благодаря наличию логов можно быстро обнаружить причины экстренного завершения функционирования ПО.
Завершение
Все описанные выше советы в простом и понятном формате должны помочь начинающим тестировщикам проанализировать свои собственные баг-репорты, и найти пути решения совершенствования своих отчетов.
Это важно, так как только качественное описание бага помогает улучшить взаимопонимание на проектах и положительно сказывается на росте эффективности всей команды.
Оставить комментарий