Распространенные ошибки при составлении баг-репортов
На Хабре достаточно много написано про хороший стиль программирования, naming convention. А про хороший стиль написания баг-репортов?
Конечно, дефекты хранятся в баг-трекинговой системе, которая накладывает свои ограничения и требования, конечно, есть какие-то внутрикорпоративные правила создания отчетов об ошибках, но все же есть и человеческий фактор, в результате чего появляются баги, отвечающие всем правилам оформления, но абсолютно непонятные даже коллегам-тестировщикам. Плохо описанный баг может получить резолюцию Cannot reproduce и оказаться забытым, пока случайно не выплывет у заказчика.
В этой статье я попробую описать основные проблемы отчетов об ошибках, которые я встречала за год работы на большом проекте, а также способы их улучшения.
1. Очень общий заголовок баги
Пример такой баги: Не могу создать аккаунт.
Кажется, система полностью неработоспособна. Что может оказаться при более подробном изучении проблемы:
2. Очень подробные pre-steps, очень краткое описание.
Пример: Я забил гвоздь в стену. Потом работал с болтами, гайками и листовым железом. Проблема: космолет не летает.
Дефект начинают описывать как былину: Все действия, сделанные с самого утра, и с максимальной подробностью. Через пару абзацев это надоедает, и дописывают весьма кратко. Да, описание проблемы есть, оно достаточно большое, но совершенно бесполезное как программисту, который будет фиксить, так и тестировщику, которому попадет на проверку.
3. На каждое проявление ошибки создать отдельный баг-репорт
Да, порой бывает не очевидно, что это действительно одна и та же проблема. Но иногда разные проявления одного и того же дефекта попадают на разных девелоперов и тогда начинается неразбериха.
4. Большое количество аттачей и ссылок
У такой баги обычно есть только заголовок. Шаги воспроизведения представляют собой ссылку на test-case (кстати, возможно у программиста нет прав доступа на такой ресурс), ожидаемый результат — ссылка (или аттач) 50-страничной документации. В комментарии может быть приписка что шаги воспроизведения подробно расписаны в дефекте № NNN. В качестве дополнения — лог. Весь. За все 2 недели тестирования. Все 50 мегабайт. Ну и скриншоты каждого шага бонусом.
5. Не указано, в чем именно ошибка.
Да, бывает и такое. Редко (по-этому и не первое в списке), но бывает
Пример:
Заголовок: Javascript ошибка на странице. Далее идут шаги, как добраться до этой самой страницы, но нигде не указано само сообщение об ошибке и даже нет скриншотов.
6. Использование специфических сокращений и аббревиатур
Сокращенные названия сущностей, специфических для определенной части системы могут быть не понятны даже для людей, достаточно давно работающих на проекте. Также большое количество аббревиатур в тексте делает его трудным для восприятия. Время, потраченное на разбор такого дефекта значительно превышает время, которое было сэкономлено на написании отчета об ошибке. Можно использовать общепринятые аббревиатуры и сокращения, но не стоит этим злоупотреблять.
7. Обо всем и ни о чем
Коментарий от 57DeD: Не вошёл в список наиболее распространённый (по крайней мере из тех, с которыми я работал) горе-багрепорт: «У вас программа медленно грузится, иконка не того цвета, при вводе текста ошибка случается, пункт меню — не скажу какой-именно — не работает. Да и погода к тому же плохая — дождь идёт». (видимо, от разработчкаи требуется написать Not Reproduced — дождь уже кончился)
Мне кажется, данные рекомендации могут улучшить качество описания багов:
1 Правильно настроить обязательные для заполнения поля в баг-трекинговой системе, запретить аттачить большие файлы (если это не видео воспроизведения ошибки)
2. По аналогии с code-review: Просите иногда коллег посмотреть на свежесозданный отчет об ошибке. Возможно, они подскажут, что стоит добавить и/или исключить из описания бага.
3. Проверяйте багобазу перед созданием нового отчета — возможно, такой «зверь» уже записан.
4. Золотая середина нужна везде. Пытайтесь писать не пропуская важных шагов, но и не разжевывая очевидные вещи
5. И не забывайте про золотое правило — пишите отчеты об ошибках так, чтоб вам их было приятно читать
Фундаментальная теория тестирования
В тестировании нет четких определений, как в физике, математике, которые при перефразировании становятся абсолютно неверными. Поэтому важно понимать процессы и подходы. В данной статье разберем основные определения теории тестирования.
Перейдем к основным понятиям
Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.
Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.
Для чего проводится тестирование ПО?
Принципы тестирования
QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.
К задачам контроля качества относятся:
К задачам обеспечения качества относятся:
Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.
Верификация (verification) — это процесс оценки системы, чтобы понять, удовлетворяют ли результаты текущего этапа разработки условиям, которые были сформулированы в его начале.
Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.
Пример: когда разрабатывали аэробус А310, то надо было сделать так, чтобы закрылки вставали в положение «торможение», когда шасси коснулись земли. Запрограммировали так, что когда шасси начинают крутиться, то закрылки ставим в положение «торможение». Но вот во время испытаний в Варшаве самолет выкатился за пределы полосы, так как была мокрая поверхность. Он проскользил, только потом был крутящий момент и они, закрылки, открылись. С точки зрения «верификации» — программа сработала, с точки зрения «валидации» — нет. Поэтому код изменили так, чтобы в момент изменения давления в шинах открывались закрылки.
Документацию, которая используется на проектах по разработке ПО, можно условно разделить на две группы:
Этапы тестирования:
Программный продукт проходит следующие стадии:
Требования
Требования — это спецификация (описание) того, что должно быть реализовано.
Требования описывают то, что необходимо реализовать, без детализации технической стороны решения.
Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.
Атрибуты отчета о дефекте:
Жизненный цикл бага
Severity vs Priority
Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.
Градация Серьезности дефекта (Severity):
Градация Приоритета дефекта (Priority):
Тестовые среды
Основные фазы тестирования
Основные виды тестирования ПО
Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.
Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:
Методы тестирования
Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.
Согласно ISTQB, тестирование белого ящика — это:
Тестирование чёрного ящика — также известное как тестирование, основанное на спецификации или тестирование поведения — техника тестирования, основанная на работе исключительно с внешними интерфейсами тестируемой системы.
Согласно ISTQB, тестирование черного ящика — это:
Тестовая документация
Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.
Тест план должен отвечать на следующие вопросы:
Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.
Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Атрибуты тест кейса:
Bug report что это
Что пишут в блогах
Заказать — https://shop.testbase.ru/buy/book. Пока самовывоз (см ниже где и когда!!). С почтой разберемся чуть позже.
Где: Кострома / онлайн
2 декабря буду выступать в Костроме. Приходите увидеться очно, или подключайтесь онлайн.
Онлайн-тренинги
Что пишут в блогах (EN)
Blogposts:
Разделы портала
Про инструменты
Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова
Баги, баги, баги! Нельзя обсуждать разработку ПО, не затрагивая тему багов. Поначалу термин «баг» может казаться странным жаргоном для «дефекта». По коду и машинам что, бегают жучки и паучки? Как правило, нет, но иногда таки да! В 1947 году Грейс Хоппер нашла мертвого мотылька, застрявшего в реле гарвардского компьютера Mark II, и в отчете о «жучке» шутила, что нашла настоящего жука за компьютерным дефектом. Несмотря на то, что изобретатели вроде Томаса Эдисона использовали термин «баг» для описания технологических глюков задолго до 1947 года, именно этот мотылек зафиксировал терминологию для компьютеров и ПО.
Баги случаются. Почему? Потому что никто не идеален, и поэтому не существует идеального ПО. Создание высококачественного ПО требует хорошего дизайна для устойчивости к багам, хорошего внедрения, дабы избежать багов, и хорошей обратной связи, чтобы сообщить о багах, когда они неизбежно возникнут. В статье я собрал лучшие практики для создания хороших баг-репортов.
Что такое баг-репорт?
Баг – это всего-навсего дефект. Термин относится исключительно к проблемам в ПО. Однако баг-репорт (или тикет) – это письменное описание, детализирующее дефект. Как правило, баг-репорты пишутся в инструменте управления проектом вроде Jira. Баг и отчет о нем – это две разные вещи. Естественно, что не обнаруженные баги могут отлично существовать в продукте, когда отчетов о них еще не существует.
Когда надо писать баг-репорт?
Баг-репорт надо писать, когда обнаружена новая проблема, которая выглядит как дефект. Проблемы обнаруживаются в ходе такой тест-деятельности, как прогон автотестов или ручное исследовательское тестирование. Их также находят при разработке новых фич. В худшем случае их найдут пользователи и начнут жаловаться!
Заметьте, я использую термин «проблема», а не «дефект». Всем проблемам нужны решения, но не все проблемы – это действительно дефекты. Иногда сообщивший о проблеме пользователь не знает, как должна работать фича. Иногда дело в неправильно сконфигурированном окружении. Член команды, выявивший проблему или получивший жалобу от клиента, должен провести небольшое расследование, чтобы убедиться, что проблема действительно выглядит как дефект ПО. Первоначальное расследование нужно проводить немедленно, пока еще жив контекст.
Если проблема выглядит реальным дефектом, а не недопониманием и не плохой настройкой конфигурации, детектив должен поискать эту проблему среди существующих баг-репортов. На нее или что-то похожее мог недавно наткнуться кто-то еще. Баги также могут появиться вновь даже после «исправления». Добавление информации в существующие репорты – куда лучшая практика по сравнению с созданием дубликатов.
Что, если проблема неясна? Если я не уверен, баг это или другой тип проблемы, я спрашиваю коллег. Я пытаюсь задавать вопросы вроде «Выглядит ли это правильным? Что может вызывать такое поведение? Может, я что-то сделал не так?» Слепо плодить баг-репорты для каждой проблемы – вести себя как мальчик из сказки, который кричал «Волки»: команда будет менее чувствительной к предупреждением о реальных, важных багах. Небольшое расследование демонстрирует ваши хорошие намерения и во множестве случаев избавляет команду от лишней работы позднее. Несмотря на это, в случае сомнений создать репорт лучше, чем не создать. Небольшое количество ложноположительных результатов лучше риска реальных проблем.
Зачем нужны баг-репорты?
При обнаружении реального бага команда должна написать о нем репорт. Просто поговорить о баге проще и быстрее, особенно в небольших командах, но фиксировать это письменно важно для целостности процесса разработки ПО. Письменный отчет – это артефакт, который требует решения.
Баг-репорты помогают сделать исправление багов частью процесса разработки. Они привлекают к багам внимание, и их непросто игнорировать или проморгать.
Что входит в баг-репорт?
Вне зависимости от инструмента или процесса, хорошие баг-репорты содержат следующую информацию:
Я всегда использую этот список в качестве шаблона, создавая баг-репорты. К примеру, в баг-репорте в Jira я делаю каждый пункт списка заголовком в поле «Описание». Иногда я пропускаю разделы, если мне недостаточно информации, но, как правило, не открываю баг-репорт, не имея на руках большей части этих сведений.
Как обращаться с баг-репортом?
Одним словом: профессионально. Обращайтесь с баг-репортами профессионально. Что это значит?
Давайте как можно больше информации в своих репортах. Баг-репорты – это форма коммуникации и записи. Когда вы не говорите толком ничего, кроме «ну, сломалось», это не поможет никому решить проблему. Давайте полезную, актуальную информацию, чтобы те, кто не находил этот баг, вникли в него достаточно, чтобы суметь помочь.
Приоритезируйте баги с умом. Находя проблему, исследуйте ее. Если вам нужно другое мнение, попросите о нем. Когда кто-то отправляет вам или команде баг-репорты, приоритезируйте их, исправьте баги, и отчитайтесь перед тем, кто сообщил о проблеме. Не игнорируйте проблемы и не давайте им гнить.
Относитесь к баг-репортам, как к историям. Баги – это обычно неожиданные, заковыристые сюрпризы. Информация в баг-репорте может быть неполной или даже неверной, потому что представляет из себя наиболее вероятные предположения о дефекте. Артефакт репорта – это живой документ, в него можно добавлять информацию и обновлять ее по ходу работы. Члены команды должны помогать друг другу предоставлением доступной информации.
Не стыдите и не стыдитесь. Баги случаются. Даже гениальный разработчик делает ошибки. Зрелая, здоровая команда тщательно заводит баги, быстро исправляет их, и предпринимает меры, чтобы в будущем избежать подобных дефектов. Разработчики не должны стигматизировать баги или пытаться ограничить количество багов. Тестировщики не должны хвастать количесвтмо найденных багов. Речь в репорте должна концентрироваться на ПО, а не людях. Сплетни и публичная порка за баги – это абсолютное «нет». Любой стыд за баги может толкнуть команду на путь плохих практик. Любые регулярно возникающие проблемы должны разбираться напрямую с ответственными, или с помощью менеджмента.
Хорошие баг-репорты – это важно.
Создание баг-репортов критично важно для сотрудничества команды. Организованная, точная информация может сберечь кучу времени, потраченную на бесплодные попытки воспроизвести проблему или попытаться ее исправить. Помните об этом в следующий раз, когда наткнетесь на баг!
Баг-репорты: зачем о них заботиться и когда их следует создавать?
Думаю, все тестировщики знают, зачем нужны баг-репорты и когда их следует создавать. А если кто-то забыл, мы напомним.
Итак, баг-репорты нужно разрабатывать всегда, когда найден новый дефект в ПО.
Ошибки находятся в процессе прогона тест-деятельности, начиная от автотестов, заканчивая исследовательскими проверками.
Также, их могут обнаруживать при каждом новом случае создания новых фич.
При самом худшем сценарии, их найдут пользователи и будут громко жаловаться.
Как работать с баг-репортами
Естественно, если есть проблема (проблемы), значит где-то нужно искать решения, но бывает так, что не все неразрешимые моменты это действительно проблема (ошибка, баг, некорректное поведение).
Порой случается так, что сообщивший о проблеме пользователь не понимает, как должна работать та или иная группа функционала. Еще нередки ситуации, когда пользователь сталкивается с некорректно настроенным окружением.
Член проектной группы (тестировщик или программист), который нашел баг или получивший обратную связь от пользователя, должен выполнить собственное небольшое мини-расследование, чтобы самостоятельно убедиться, что дефект реально существует непосредственно в структуре программного обеспечения.
Только быстрое расследование нужно выполнять мгновенно, пока присутствует контекст.
Если ошибка выглядит действительно серьезным багом, а не недопониманием со стороны пользователя, тестировщик должен найти эту проблему среди ранее найденных баг-репортов. На подобную проблему мог кто-то натолкнуться ранее.
Дефекты также могут появляться после их исправления.
Добавление новых данных в баг-репорты — весьма хорошая практика в сравнении с процессом создания дубликатов.
Но что делать, если найденная проблема не очень ясна? Если самостоятельно не можете разобраться с видом ошибки, лучше спросить коллег.
Можно попробовать задать вопросы вида «Является ли это правильным? Что именно может вызывать подобное системное поведение? Может что-то было сделано не так?».
Если слепо создавать баг-репорты для общего количества, со временем, вся команда получит низкий уровень чувствительности к реальным предупреждениям о критических ошибках.
Только небольшие расследования могут демонстрировать пользовательские намерения со знаком плюс и, в большинстве случаев, избавляют всю команду от дополнительной и ненужной работы.
Но, конечно же, при большом сомнении создавать баг-репорты или нет, лучше все-таки их создать.Малое количество ложно положительных итогов лучше общего риска получить реальные технические проблемы.
Почему баг-репорты настолько важны?
Когда команда тестировщиков в процессе проверки ПО находит ошибку, она в обязательном порядке должна создать о нем репорт.
В маленьких командах дефект можно просто обсудить, но все же фиксация всего этого в документах позволяет оптимизировать целостность всего процесса создания программного обеспечения.
Любой письменный отчет — это, своего рода, артефакт, который требует определенного разрешения.
Только баг-репорты помогают наладить процесс исправления багов. Именно они могут максимально привлечь внимание к дефектам, так как их сложно игнорировать и невозможно пропустить.
Как правильно вести себя с баг-репортом?
Тут можно ответить всего одним словом — профессионально. Что это означает? Далее попробуем разобраться.
Внутри баг-репорта должно содержаться максимальное количество данных о проблеме.
Классический баг-репорт — это конструкция формы для процесса коммуникации между сотрудниками.
Если детально не расписывать суть проблемы, краткая толика информации особо не поможет уладить первоочередные дилеммы и задачи.
Предоставляйте исключительно полезную информацию, чтобы те, кто такой баг еще не встречал, мог запросто в него вникнуть и постараться решить дилемму.
Приоритезация баг-репорта на первом месте. Если вы нашли баг, его обязательно нужно исследовать.
Если вы думаете, что другое мнение вам поможет понять природу дефекта, спросите его.
Если вы получили в работу несколько баг-репортов, мгновенно приоритизируйте их, выполните всю работу и отчитайтесь о результатах.
Не стоит игнорировать дефекты, и не позволяйте им оставаться неделями в теле репорта.
Баг-репорт должен стать для вас историей.
Дефекты — это традиционно неожиданные, удивительные сюрпризы.
Данные внутри баг-репорта могут быть зафиксированы не в полной мере, а иногда даже и неверно, так как они представляют из себя максимально приближенные (вероятные) пользовательские предположения о баге.
Любой артефакт баг-репорта — это, своего рода, живой файл, в который можно добавлять данные и выполнять обновление по ходу работы.
Работа с баг-репортами очень важна для максимально качественного функционирования всей проектной команды.
Точно зафиксированная информация позволяет сохранить массу времени, которое могло быть потраченным на ненужные попытки воспроизведения дефекта или процесса его исправления.
Как составить баг-репорт: мини-гайд
Среди всех вещей, связанных с тестированием, есть кое-что, с чем тестировщик сталкивается ежедневно. Это баг-репорт: документ, описывающий баг, его серьезность и приоритет, а также шаги, позволяющие его воспроизвести. Опираясь на баг-репорты, разработчики могут быстро определить, какая часть кода работает неправильно, и исправить ее.
Хорошо написанный баг-репорт гарантирует эффективное сотрудничество между командами разработчиков и тестировщиков. Поэтому умение писать баг-репорты — один из самых важных навыков тестировщика.
Как же писать баг-репорты, чтобы разработчики были ими довольны? В этой статье вы найдете несколько советов.
Как написать хороший баг-репорт
Когда дело касается написания документации, есть одно универсальное правило: пишите попроще. Чем проще, тем лучше.
Но «попроще» не значит «покороче». Баг-репорты должны содержать подробности, позволяющие читателю понять природу бага. То есть в них должно быть достаточно сведений, чтобы понять, почему описываемое поведение — баг, и как его воспроизвести. Вместе с тем нужно стараться не включать в баг-репорт лишнего и не повторяться.
Что же мы подразумеваем под «хорошим» баг-репортом? Мы можем сказать, что баг-репорт эффективен, если:
Не пытайтесь использовать баг-репорт как доказательство того, что кто-то совершил ошибку. Указывайте только значимую информацию и придерживайтесь нейтрального тона. Всегда перечитывайте то, что написали, прежде чем отправить.
Непременно воспроизведите баг два-три раза, прежде чем начать его документировать. Не включайте в репорт больше одного дефекта. Наконец, прежде чем написать репорт о новом баге, убедитесь, что его нет в списке уже известных багов (чтобы избежать дублирования).
Структура баг-репорта
Если вы ищете пример баг-репорта, вот список вещей, которые должны в нем быть:
Можете использовать этот список в качестве плана для своего следующего баг-репорта. Давайте еще разберем вкратце каждый пункт.
1. Краткое описание
В идеале, описание бага должно раскрывать ответы на три вопроса: что, где и когда. Например: «(что?) Появляется Console Error (где?) во вкладке Статистика (когда?) после того, как пользователь нажимает на кнопку Скачать». Иногда часть «где» можно опустить. Например: «Приложение падает после того, как пользователь нажимает на кнопку Войти». Можно указать страницу, на которой это происходит. Но если у вас есть единственное место, где пользователь может найти эту форму, то и так очевидно, где он нажимает на кнопку.
2. Продукт
В этой части обычно пишется версия сборки, которая тестируется. Тестировщик указывает эту информацию, чтобы разработчик мог сравнить последнюю, тестируемую версию продукта с предыдущей и посмотреть, что изменилось. Благодаря этому куда легче найти причину поломки.
3. Платформа
Тестировщик должен указать, на какой платформе проявляется баг. Для десктопных проектов укажите операционную систему. Для веб-проектов — самые важные сведения о браузере. Что касается мобильных проектов, для них нужно указать модель девайса и его операционную систему.
4. Статус
Указание статуса бага помогает держать всю команду в курсе процесса исправления. Статус может сообщать о том, что разработчик принял баг в работу, вернул на повторное тестирование, исправил и закрыл и т. п. Количество возможных статусов зависит от принятого в команде рабочего процесса.
5. Приоритет
Приоритет бага показывает, насколько критичен дефект для бизнеса, и определяет очередность исправления. Обычно приоритет устанавливают менеджер продукта, собственник продукта или тимлид.
6. Серьезность
В отличие от приоритета, серьезность определяется тестировщиком. Устанавливая уровень серьезности, он исходит из того, насколько опасен баг для всей системы, в какой степени он затрагивает самый важный функционал и т. п.О серьезности и приоритетности багов можно почитать в статье «Серьезность и приоритет багов — в чем разница?»
7. Предусловия
В предусловиях описываются действия, которые нужно выполнить, и параметры, которые нужно применить перед выполнением шагов, позволяющих воспроизвести баг. Это описание не имеет какого-то четкого формата, просто придерживайтесь логического порядка.
8. Шаги воспроизведения
Наилучший способ описать эти шаги — составить пронумерованный список с последовательностью действий пользователя, приводящих к проявлению бага. Используйте простые предложения.
9. Фактический результат
Фактический результат — это проблема, появляющаяся, когда пользователь выполняет шаги, указанные выше.
Опишите результат, придерживаясь того же правила, что и для краткого описания бага. Обозначьте, что происходит, где и когда. Это поможет разработчику понять, в чем проблема. Лаконичное и четкое описание пригодится и QA-команде в будущем.
10. Ожидаемый результат
В этом разделе опишите ожидаемый результат шагов, описанных в п.8. То есть изложите, как приложение должно было бы себя вести.
Ошибка тоже может быть ожидаемым результатом — если тестировщик проверяет негативный сценарий. Например, если пользователь вводит неправильные учетные данные, он не должен войти в систему, вместо этого он должен увидеть сообщение об ошибке.
11. Прикрепленные файлы
Это дополнительные материалы, которые можно добавить к баг-репорту. Часто с визуальными руководствами бывает проще воспроизвести баг. Особенно, если баг сложно описать словами.
Добавление скриншотов или коротких видео поможет избежать недопонимания. Только не забывайте, что визуальные материалы должны быть релевантными и понятными.
Итоги
Документацию нужно создавать так, чтобы она была легкой в использовании и понятной другим членам команды. Такая документация сэкономит вам много времени в будущем, когда проект разрастется, а в команде появятся новички.
Теперь вы знаете, как написать баг-репорт. Более того: вы знаете, как написать его так, чтобы разработчики были довольны. Сохраните себе этот план и пользуйтесь им в работе!
