Home

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

Баги, баги, баги! Нельзя обсуждать разработку ПО, не затрагивая тему багов. Поначалу термин "баг" может казаться странным жаргоном для "дефекта". По коду и машинам что, бегают жучки и паучки? Как правило, нет, но иногда таки да! В 1947 году Грейс Хоппер нашла мертвого мотылька, застрявшего в реле гарвардского компьютера Mark II, и в отчете о "жучке" шутила, что нашла настоящего жука за компьютерным дефектом. Несмотря на то, что изобретатели вроде Томаса Эдисона использовали термин "баг" для описания технологических глюков задолго до 1947 года, именно этот мотылек зафиксировал терминологию для компьютеров и ПО.

Баги случаются. Почему? Потому что никто не идеален, и поэтому не существует идеального ПО. Создание высококачественного ПО требует хорошего дизайна для устойчивости к багам, хорошего внедрения, дабы избежать багов, и хорошей обратной связи, чтобы сообщить о багах, когда они неизбежно возникнут. В статье я собрал лучшие практики для создания хороших баг-репортов.

Что такое баг-репорт?

Баг – это всего-навсего дефект. Термин относится исключительно к проблемам в ПО. Однако баг-репорт (или тикет) – это письменное описание, детализирующее дефект. Как правило, баг-репорты пишутся в инструменте управления проектом вроде Jira. Баг и отчет о нем – это две разные вещи. Естественно, что не обнаруженные баги могут отлично существовать в продукте, когда отчетов о них еще не существует.

Когда надо писать баг-репорт?

Баг-репорт надо писать, когда обнаружена новая проблема, которая выглядит как дефект. Проблемы обнаруживаются в ходе такой тест-деятельности, как прогон автотестов или ручное исследовательское тестирование. Их также находят при разработке новых фич. В худшем случае их найдут пользователи и начнут жаловаться!

Заметьте, я использую термин "проблема", а не "дефект". Всем проблемам нужны решения, но не все проблемы – это действительно дефекты. Иногда сообщивший о проблеме пользователь не знает, как должна работать фича. Иногда дело в неправильно сконфигурированном окружении. Член команды, выявивший проблему или получивший жалобу от клиента, должен провести небольшое расследование, чтобы убедиться, что проблема действительно выглядит как дефект ПО. Первоначальное расследование нужно проводить немедленно, пока еще жив контекст.

Если проблема выглядит реальным дефектом, а не недопониманием и не плохой настройкой конфигурации, детектив должен поискать эту проблему среди существующих баг-репортов. На нее или что-то похожее мог недавно наткнуться кто-то еще. Баги также могут появиться вновь даже после "исправления". Добавление информации в существующие репорты – куда лучшая практика по сравнению с созданием дубликатов.

Что, если проблема неясна? Если я не уверен, баг это или другой тип проблемы, я спрашиваю коллег. Я пытаюсь задавать вопросы вроде "Выглядит ли это правильным? Что может вызывать такое поведение? Может, я что-то сделал не так?" Слепо плодить баг-репорты для каждой проблемы – вести себя как мальчик из сказки, который кричал "Волки": команда будет менее чувствительной к предупреждением о реальных, важных багах. Небольшое расследование демонстрирует ваши хорошие намерения и во множестве случаев избавляет команду от лишней работы позднее. Несмотря на это, в случае сомнений создать репорт лучше, чем не создать. Небольшое количество ложноположительных результатов лучше риска реальных проблем.

Зачем нужны баг-репорты?

При обнаружении реального бага команда должна написать о нем репорт. Просто поговорить о баге проще и быстрее, особенно в небольших командах, но фиксировать это письменно важно для целостности процесса разработки ПО. Письменный отчет – это артефакт, который требует решения.

• Репорт создает петлю обратной связи для разработчиков.
• Репорт содержит всю информацию о баге в одном месте.
• Репорт можно отслеживать в инструменте управления проектами.
• Репорт можно соразмерять и приоритезировать относительно других задач разработки.
• Репорт хранит рабочую историю бага.

Баг-репорты помогают сделать исправление багов частью процесса разработки. Они привлекают к багам внимание, и их непросто игнорировать или проморгать.

Что входит в баг-репорт?

Вне зависимости от инструмента или процесса, хорошие баг-репорты содержат следующую информацию:

• Краткое описание проблемы
  • Краткое, однострочное описание дефекта
  • Которое ясно сообщает, что не так
  • И используется в заголовке репорта.
  • Идентификатор репорта
    • Уникальный идентификатор баг-репорта.
    • Как правило, генерируется автоматически инструментом управления вроде Jira
    • Полное описание
      • Подробное описание проблемы
      • Разъясняет всю релевантную информацию
      • Четкое и внятное
      • Шаги воспроизведения
        • Внятная процедура ручного воспроизведения проблемы
        • Могут быть шагами упавшего тест-кейса
        • Включают фактические и ожидаемые результаты
        • Случаи, когда дефект воспроизводится и НЕ воспроизводится
        • Версия продукта, ветка кода, название окружения, конфигурация системы, и так далее.
        • Воспроизводится ли дефект постоянно или "плавает"?
        • Артефакты
          • Приложите логи, скриншоты, файлы, ссылки, и т. п.
          • Влияние
            • Как влияет дефект на пользователя?
            • Блокирует ли он деятельность разработки?
            • Какие кейсы упадут из-за этого дефекта?
            • Анализ первопричин
              • Если это известно, объясните, чем вызван дефект
              • Если это неизвестно, предложите возможные причины
              • Внимание: явно отделяйте доказательства от спекуляций!
              • Приоритезация
                • Если это возможно, назначьте задаче хозяина
                • Назначьте ей серьезность или приоритет на основании гайдлайнов и здравого смысла
                • Если это применимо, назначьте дедлайн
                • И все остальное, что может понадобиться вашей команде.

• Воспроизводимость

Я всегда использую этот список в качестве шаблона, создавая баг-репорты. К примеру, в баг-репорте в Jira я делаю каждый пункт списка заголовком в поле "Описание". Иногда я пропускаю разделы, если мне недостаточно информации, но, как правило, не открываю баг-репорт, не имея на руках большей части этих сведений.

Как обращаться с баг-репортом?

Одним словом: профессионально. Обращайтесь с баг-репортами профессионально. Что это значит?

Давайте как можно больше информации в своих репортах. Баг-репорты – это форма коммуникации и записи. Когда вы не говорите толком ничего, кроме "ну, сломалось", это не поможет никому решить проблему. Давайте полезную, актуальную информацию, чтобы те, кто не находил этот баг, вникли в него достаточно, чтобы суметь помочь.

Приоритезируйте баги с умом. Находя проблему, исследуйте ее. Если вам нужно другое мнение, попросите о нем. Когда кто-то отправляет вам или команде баг-репорты, приоритезируйте их, исправьте баги, и отчитайтесь перед тем, кто сообщил о проблеме. Не игнорируйте проблемы и не давайте им гнить.

Относитесь к баг-репортам, как к историям. Баги – это обычно неожиданные, заковыристые сюрпризы. Информация в баг-репорте может быть неполной или даже неверной, потому что представляет из себя наиболее вероятные предположения о дефекте. Артефакт репорта – это живой документ, в него можно добавлять информацию и обновлять ее по ходу работы. Члены команды должны помогать друг другу предоставлением доступной информации.

Не стыдите и не стыдитесь. Баги случаются. Даже гениальный разработчик делает ошибки. Зрелая, здоровая команда тщательно заводит баги, быстро исправляет их, и предпринимает меры, чтобы в будущем избежать подобных дефектов. Разработчики не должны стигматизировать баги или пытаться ограничить количество багов. Тестировщики не должны хвастать количесвтмо найденных багов. Речь в репорте должна концентрироваться на ПО, а не людях. Сплетни и публичная порка за баги – это абсолютное "нет". Любой стыд за баги может толкнуть команду на путь плохих практик. Любые регулярно возникающие проблемы должны разбираться напрямую с ответственными, или с помощью менеджмента.

Хорошие баг-репорты – это важно.

Создание баг-репортов критично важно для сотрудничества команды. Организованная, точная информация может сберечь кучу времени, потраченную на бесплодные попытки воспроизвести проблему или попытаться ее исправить. Помните об этом в следующий раз, когда наткнетесь на баг!

Обсудить в форуме