47. Объясните понятие дефекта в по. Логика построения отчёта об ошибке
Дефект – любое несоответствие фактического и ожидаемого результата (согласно требованиям или здравому смыслу). К багам относится любое некорректное поведение программы, не соответствующее оправданным ожиданиям пользователя, даже в том случае, если это поведение не документировано в требованиях и спецификациях.
Отчёт о дефекте (bug-report) – это технический документ, написанный с целью: 1. Предоставить информацию о проблеме, ей свойствах и последствиях; 2. Приоритизировать проблему по важности и скорости устранения; 3. Помочь программистам обнаружить и устранить источник проблемы.
Логика построения отчёта об ошибке: 1. Что мы сделали, т.е. шаги для воспроизведения дефекта; 2. Полученные результаты; 3. Ожидаемые результаты. Кроме того, нужно сообщить, где именно произошла проблема, при каких условиях, а также дать ошибке название.
Поля отчёта об ошибке. Основные поля: 1. Идентификатор; 2. Краткое описание; 3. Подробное описание; 4. Шаги воспроизведения; 5. Воспроизводимость (всегда, при определенных условиях); 6. Важность; 7. Срочность; 8. Симптом. Дополнительные (необязательные) поля: 1. Возможность «обойти баг»; 2. Дополнительная информация; 3. Приложения («аттачи»).
Рекомендации по написанию хороших отчётов об ошибках: 1. Тщательно объясните, как воспроизвести ошибку. 2. Описывайте всё максимально подробно. 3. Пишите отчёт понятно. 4. Если это возможно, обязательно давайте ссылку на соответствующее требование. 5. Если существует какая-либо информация, которая может помочь быстро обнаружить и исправить ошибку, – сообщите эту информацию. 6. Чётко указывайте окружение (ОС, браузер, настройки и т.п.), под которым произошла ошибка. 7. Помните, что баг-репорт – это технический документ, в котором нет места эмоциям. 8. В одном отчёте описывайте ровно одну проблему. 9. Пишите отчёт об ошибке сразу же, как только вы обнаружили ошибку (ошибки забываются, а затем теряются). 10. Если вам хватает знаний, проведите начальный анализ возможных причин возникновения ошибки. 11. Попытайтесь найти наиболее серьёзные последствия ошибки. 12. После написаний отчёта ещё раз внимательно его перечитайте. 13. Помните, что вам же самим потом придётся верифицировать баг по своему же баг-репорту.
Жизненный цикл отчёта об ошибке
1. Обнаружен - тестировщик находит дефект. 2. Назначен – на исправление кому-то из команды разработчиков. 3. Исправлен – разработчик справился, перенаправляет тестировщику на проверку. 4. Проверен - Тестировщик, который обнаружил ошибку, проверяет на новом билде. 5. Открыт заново - Если баг проявляется на новом билде, тестировщик снова открывает этот дефект. 6. Отклонён – тестировщик накосячил, фича не нужна. 7. Отложен - исправление конкретного бага сейчас не очень важно. 8. Закрытые - Закрытым считается баг в состояниях Проверен и Отклонён. 9. Открытые - баги в состояниях Обнаружен, Назначен, Открыт заново (иногда Исправлен и Отложен).
Баг-трекинговая система (bug-tracking system) – программное средство, автоматизирующее управление жизненным циклом дефекта. Разработана с целью помочь разработчикам программного обеспечения учитывать и контролировать ошибки, найденные в программах, пожелания пользователей, а также следить за процессом устранения этих ошибок и выполнения или невыполнения пожеланий. «Управление проектом — это чёткое понимание в каждый момент времени, где ты находишься». Ключевые слова во всей цепочке терминов – запрос, изменение, и отслеживание ответственности. Кто завел запись; краткое название; использованная версия системы; подробное описание. Примеры систем: Bugzilla, Atlassian JIRA, YouTrack, Redmine.