Если Вам еще не знакомы термины, которыми пользуется каждый тестировщик, рекомендуем вернуться к статье о важных терминах для этой профессии и ознакомиться с ними. В этой статье мы поговорим о баг-репортах и важности уметь правильно их составлять.
Но для начала немного предыстории. Еще в 1947 году в Гарвардском университете инженер обнаружил застрявшего мотылька между контактами реле, что стало причиной неисправности ЭВМ Mark II. Этим инженером была Грейс Хоппер. После изъятия, она вклеила его скотчем в технический дневник, указав, что первой ошибкой в системе был "жучок" (англ. bug). С тех пор ошибки программных систем называли багами.
Да, с тех пор тестирование системы на корректность работы и поиск неисправностей совершенствовалось и приобрело совсем иной характер, но, в целом, основной принцип работы остался прежним.
Но для начала немного предыстории. Еще в 1947 году в Гарвардском университете инженер обнаружил застрявшего мотылька между контактами реле, что стало причиной неисправности ЭВМ Mark II. Этим инженером была Грейс Хоппер. После изъятия, она вклеила его скотчем в технический дневник, указав, что первой ошибкой в системе был "жучок" (англ. bug). С тех пор ошибки программных систем называли багами.
Да, с тех пор тестирование системы на корректность работы и поиск неисправностей совершенствовалось и приобрело совсем иной характер, но, в целом, основной принцип работы остался прежним.
Баг заключается в основной идее тестирования и характеризуется как несоответствие фактической работы программного обеспечения ожидаемому результату, то есть техническому заданию или спецификации от заказчика. Проверка на баги совершается не только непосредственно уже на этапе тестирования готового продукта, но и на этапе анализа техзадания. Под тестирование может попадать как интерфейс в удобстве пользования, так и точность дизайна продукта, или же функциональная составляющая бекэнда программы.
Каждая ошибка системы должна быть задокументирована. И отчет, в котором указаны все баги называется баг-репорт. В нем указывается детальное описание ошибки, которая произошла на этапе тестирования и все действия, которые к ней привели.
Каждая ошибка системы должна быть задокументирована. И отчет, в котором указаны все баги называется баг-репорт. В нем указывается детальное описание ошибки, которая произошла на этапе тестирования и все действия, которые к ней привели.
Важно соблюдать все правила написания баг-репорта, о которых мы поговорим ниже. Но главное - чем детальнее и кратко будет написан отчет, будет указание на ключевые моменты для точного воспроизведения бага, тем более качественная будет работа тестировщика.
Каждый баг-репорт состоит из нескольких важных атрибутов, которые обязательно указываются в нем:
Каждый баг-репорт состоит из нескольких важных атрибутов, которые обязательно указываются в нем:
- Саммари (краткое описание ошибки одним предложением) - строится по принципу: что не работает? где не работает? когда? или при каких условиях не работает? Например,- "Не совершается оплата после нажатие на кнопку "Купить" на странице покупки товара".
- Описание ошибки (шаги воспроизведения), должно быть коротким и ясным программисту. Здесь указываются все шаги, то есть условия, возникновения бага, фактический результат и ожидаемый результат работы программы.
- Проект - указывается наименование приложения, сайта или другой программы, к которой относится наш баг, для подальшего отслеживания устранения данного дефекта.
- Компонент - под ним следует понимать часть программы, или участок разработки, в котором был допущен баг. Если в разных частях продукта есть похожие участки кода, рекомендуется проверить один баг на нескольких участках разработки. Например, каталог интернет-магазина подразумевает наличие фильтров для детализации поиска определенного товара, но также на разных категориях товара есть вероятность повторяющегося участка разработки кода для фильтров, которые могут быть попросту скопированы разработчиком. Если есть баг в одной части, он непременно будет и в другом участке.
- Серьезность - иными словами критичность ошибки, или на сколько сильно данная ошибка влияет на работоспособность нашего программного обеспечения. Зачастую это - несущественный (Minor), значительный (Major), критический (Critical) или блокирующий (Blocker)
- Приоритет - последовательность исправления багов, исходя из предыдущей атрибута бага. Обычно это - высокий (High), средний (Medium) и низкий (Low). Важно отметить, что приоритет тестировщик не проставляет - этим занимается проджект менеджер или тот, кто занимается распределением задач на программистов.
- Статус - это фиксация этапа устранения бага в его жизненном цикле. Например, открыт (Open), закрыт (Closed), новый (New) или переоткрыт (Reopen).
- Версия билда, то есть версия нашего продукта, в которой допущена ошибка. Иногда этот атрибут может быть не указан, если нет версии у продукта или бага воспризводится во всех версиях ПО.
- Автор - тот участник команды, который вносит информацию о баге.
- Окружение - под это понятие может попадать ОС, разряд системы, браузер, в котором была обнаружена ошибка.
Хорошим дополнением к отчету будут скрины ошибок с отметками (например, стрелками и цифрами) последовательности воспроизведения бага. Также, если баг сложный, то можно записать видео и прикрепить его к баг-репорту.
Самыми важными атрибутами для каждой ошибки в баг-репорте являются серьезность и приоритет. И если степень серьезности указывает тестировщик, то за приоритетность устранения отвечает PO (Product Owner) со стороны заказчика или проджект менеджер (PM). Поскольку, есть незначительные ошибки, которые не ломают приложение, например, наименование интернет-магазина, в котором допущена ошибка, но их устранение первоочередно важно для престижа компании заказчика.
Самыми важными атрибутами для каждой ошибки в баг-репорте являются серьезность и приоритет. И если степень серьезности указывает тестировщик, то за приоритетность устранения отвечает PO (Product Owner) со стороны заказчика или проджект менеджер (PM). Поскольку, есть незначительные ошибки, которые не ломают приложение, например, наименование интернет-магазина, в котором допущена ошибка, но их устранение первоочередно важно для престижа компании заказчика.
Рассмотрим классификации степени серьезности багов и их влияние на работоспособность программного обеспечения:
Для правильного наименования заголовка бага в атрибуте описания можно использовать золотое правило "где?", "что?" и "когда?". Где - место, в котором обнаружена ошибка, что - результат, к которому привело наличие бага, когда - при каких условиях. Чем более корректным и понятным будет описание бага, тем быстрее он будет устранен. Поскольку, если баг будет не воспроизводим, то вероятнее всего программист отклонит эту ошибку и она не будет исправлена.
Все баг-репорты вносятся в баг-трекинговые системы. По-сути, баг-трекинговые системы созданы не только для фиксации багов. В них также вносятся и User-стори, технические требования от PM для реализации в продукте и другая документация. Самыми распространенными баг-трекинговыми системами являются Jira (наиболее используемая), Asana, Redmine, Trello и Bugzilla.
- Blocker - та ошибка, которая приводит к неработоспособности нашей программы. То есть дальнейшее ее использование пользователем становится невозможным.
- Critical - есть несколько вариантов: отклонение от логики работы программного обеспечения, задуманного заказчиком; нерабочий функционал отдельных элементов ПО (например, отсутствие перехода в корзину после клика на кнопку "Купить" на сайте интернет-магазина); не сохранение данных сеанса, или пользователя.
- Major - есть схожесть с критическими ошибками, но в данном случае приложение работает, но не соответствует запросам заказчика.
- Minor - незначительный дефект, не нарушающий работоспособность ПО. Например, ошибка в дизайне приложения.
- Trivial - наименее незначительный баг программного обеспечения, например, текстовая опечатка. Она никак не влияет на работоспособность, но также не соответствует желаемому результату технического задания.
Для правильного наименования заголовка бага в атрибуте описания можно использовать золотое правило "где?", "что?" и "когда?". Где - место, в котором обнаружена ошибка, что - результат, к которому привело наличие бага, когда - при каких условиях. Чем более корректным и понятным будет описание бага, тем быстрее он будет устранен. Поскольку, если баг будет не воспроизводим, то вероятнее всего программист отклонит эту ошибку и она не будет исправлена.
Все баг-репорты вносятся в баг-трекинговые системы. По-сути, баг-трекинговые системы созданы не только для фиксации багов. В них также вносятся и User-стори, технические требования от PM для реализации в продукте и другая документация. Самыми распространенными баг-трекинговыми системами являются Jira (наиболее используемая), Asana, Redmine, Trello и Bugzilla.
После первоначальных устранений багов, разработанный продукт тестируется повторно, отдельно на воспроизведение бага, и отдельно по функционалу, который мог быть затронут в ходе исправления ошибок. Необходимо разделять повторное тестирование бага и повторное тестирование смежного компонента, чтоб не дублировать фиксацию одной ошибки.
Перед написанием баг-репорта обязательно воспроизведите ошибку несколько раз. Поскольку она могла возникнуть в связи с нестабильной работой сети, или из-за неполадок ПК и других причин, не связанных с работоспособностью самого программного обеспечения. Если возникновение бага повторяется, необходимо сразу зафиксировать ошибку и сообщить о ней программисту. Также лучше заранее проверить ошибку с разных браузеров и с мобильной версии, для того, чтоб максимально точно локализировать места, где что-то не работает. Очень часто, можно наблюдать ошибки только в браузере Chrome, в свою очередь как в Firefox все будет работать корректно. И наоборот.
Перед отправкой баг-репорта программистам необходимо перечитать его несколько раз, проверить на орфографические ошибки, еще раз оценить краткость и ясность написанного отчета. Баг-репорт является одним из самых важных документов тестировщика, он показывает вашу грамотность и квалифицированность.
Более детально о правилах написания баг-репорта мы рассказываем на курсе тестировщика с нуля. Присоединяйтесь к следующему потоку курса. Мы поможем освоить самую востребованную профессию легко и получить качественные знания.
Перед написанием баг-репорта обязательно воспроизведите ошибку несколько раз. Поскольку она могла возникнуть в связи с нестабильной работой сети, или из-за неполадок ПК и других причин, не связанных с работоспособностью самого программного обеспечения. Если возникновение бага повторяется, необходимо сразу зафиксировать ошибку и сообщить о ней программисту. Также лучше заранее проверить ошибку с разных браузеров и с мобильной версии, для того, чтоб максимально точно локализировать места, где что-то не работает. Очень часто, можно наблюдать ошибки только в браузере Chrome, в свою очередь как в Firefox все будет работать корректно. И наоборот.
Перед отправкой баг-репорта программистам необходимо перечитать его несколько раз, проверить на орфографические ошибки, еще раз оценить краткость и ясность написанного отчета. Баг-репорт является одним из самых важных документов тестировщика, он показывает вашу грамотность и квалифицированность.
Более детально о правилах написания баг-репорта мы рассказываем на курсе тестировщика с нуля. Присоединяйтесь к следующему потоку курса. Мы поможем освоить самую востребованную профессию легко и получить качественные знания.
По всем вопросам свяжитесь с нами любым удобным способом:
Телефоны:
E-mail:
Мы в соцсетях: