Lesson 06. Поиск и документирование дефектов

Август 1, 2022

Главная
Информатика
Lesson 06. Поиск и документирование дефектов

Содержание

2. Тестирование — это не поиск ошибок! Главное правило тестирования – не надо стараться найти как можно
3. Тестирование vs. Поиск ошибок
4. Рассмотрим несколько определений дефекта: «Быстрое тестирование» (Роберт Калбертсон, Крис Браун, Гэри Кобб): «Программная ошибка – ни
5. Мы будем использовать простое определение: Дефект – это несоответствие требованиям или функциональным спецификациям. Также следует помнить,
6. «Днём рождения» первого компьютерного бага считается 9 сентября 1945 года. В Гарвардском университете, где работал этот
7. Задокументировать дефект может кто угодно, обнаруживший некорректное поведение программы: Тестировщики и специалисты по обеспечению качества Разработчики
8. Новый (New). Итак, тестировщик находит дефект и представляет его на рассмотрение в систему управления дефектами. С
9. Иллюстрация жизненного цикла дефекта
10. Закрытые (closed) баги. Закрытым считается баг в состояниях Проверен (verified) и Отклонён (declined) Дублирован (duplicated). Открытые
11. Баг/Дефект Репорт (Bug Report) - это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе
12. Отчеты об ошибках пишутся с целью: предоставить информацию о проблеме, ее свойствах и последствиях; приоритизировать проблему
13. Основные атрибуты: Идентификатор (id) Краткое описание (summary) Подробное описание (description) Шаги воспроизведения (steps to reproduce, STR)
14. Дополнительные (необязательные) атрибуты: Возможность «обойти баг» (workaround) Дополнительная информация (additional information) Воспроизводимость (reproducible) Приложения (attachments) Атрибуты
15. У каждого отчета об ошибке должен быть уникальный идентификатор. Как правило, системы управления ошибками (bug tracking
16. Хорошее краткое описание должно давать ответы на три вопроса: Что? Где? При каких условиях? Например: «Отсутствует
17. В отличие от краткого описания, которое, как правило, является одним предложением, здесь можно и нужно давать
18. Несколько рекомендаций: – Описывайте каждый шаг, пока не столкнётесь с дефектом. – Найдите точный путь, чтобы
19. Пример: 1. Перейти по ссылке: http://www.site.com/login/ 2. Ввести в поле «Логин» значение «admin». 3. Ввести в
20. Это поле показывает, насколько серьёзна найденная ошибка. Обычно, выделяют следующие уровни важности: Критическая (critical). Это самые
21. Это поле показывает, как быстро необходимо исправить ошибку. Обычно, выделяют такие значения срочности: Наивысшая (ASAP, as
22. Это поле косвенно влияет на важность и срочность устранения ошибки. Если некое действие можно выполнить в
23. В это поле можно писать всё то, что вы считаете необходимым отметить, но что не подходит
24. Это поле показывает, воспроизводится ли баг всегда («always») или лишь иногда («sometimes»). Баги, воспроизводящиеся всегда, гораздо
25. Лучший способ указать на баг – приложить к баг-репорту некую наглядную информацию: скриншоты, видеоролики, логи (журналы
26. Пример отчета об ошибке
27. Пример отчета об ошибке
28. Как обращаться с найденными багами?
29. Отчёт, который не даёт достаточной информации «Программа не работает», «Приложение виснет». Отчёт об ошибках в той
30. Формула совершенного баг-репорта состоит из трёх простых пунктов: Что мы сделали (steps required to reproduce the
31. Программист так и не смог воспроизвести у себя ошибку по той или иной причине. Ошибке выставлены
32. Отсутствуют необходимые для понимания ошибки скриншоты, логи и т.д. Для описания новой ошибки, похожей на старую,
33. Тщательно объясните, как воспроизвести ошибку. Сообщите всю необходимую для этого информацию, а также свои размышления о
34. Если существует какая-либо информация, которая может помочь быстро обнаружить и исправить ошибку, – сообщите эту информацию.
35. Пишите отчёт об ошибке сразу же, как только вы обнаружили ошибку. Откладывание записи «на потом» приводит
36. Хороший отчёт об ошибках помогает: Сократить количество ошибок, «возвращаемых» разработчиками (отклонённых или открытых заново). Ускорить устранение
37. JIRA Redmine Bugzilla QC Баг-трэкинговые системы
38. Рабочий процесс в JIRA
40. Скачать презентацию

Слайд 2

Тестирование — это не поиск ошибок!
Главное правило тестирования – не надо

стараться найти как можно больше ошибок, надо стараться пропустить как можно меньше!

Введение

Слайд 3

Тестирование vs. Поиск ошибок

Слайд 4

Рассмотрим несколько определений дефекта:
«Быстрое тестирование» (Роберт Калбертсон, Крис Браун, Гэри Кобб):

«Программная ошибка – ни что иное, как изъян в разработке программного продукта, который вызывает несоответствие ожидаемых результатов выполнения программного продукта и фактически полученных результатов.»
«Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах» (Роман Савин): «Итак, баг (bug) – это отклонение фактического результата (actual result) от ожидаемого результата (expected result). В соответствии с законом исключённого третьего у нас есть баг при наличии любого фактического результата, отличного от ожидаемого.»
Википедия. «В целом, разработчики различают дефекты программного обеспечения и сбои. В случае сбоя программа ведёт себя не так, как ожидает пользователь. Дефект – это ошибка/неточность, которая может быть (а может и не быть) следствием сбоя.»
Сергей Мартыненко (блог «255 ступеней»). «Дефект – поведение программы, затрудняющее или делающее невозможным достижение целей пользователя или удовлетворение интересов участников. Подразумевает возможность исправления. При невозможности исправления переходит в разряд ограничения технологии.»

Определения дефекта

Слайд 5

Мы будем использовать простое определение:
Дефект – это несоответствие требованиям или функциональным

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

Определение дефекта

Слайд 6

«Днём рождения» первого компьютерного бага считается 9 сентября 1945 года. В

Гарвардском университете, где работал этот компьютер, в этот день с машиной возникли проблемы, и исследование показало, что мотылёк попал между контактами панели. Операторы извлекли мотылька и сделали соответствующую запись в журнале: «Обнаружен первый настоящий баг». (Англ. «bug» – жук, насекомое).

Немного истории

Слайд 7

Задокументировать дефект может кто угодно, обнаруживший некорректное поведение программы:
Тестировщики и специалисты

по обеспечению качества
Разработчики
Представители службы технической поддержки
Продавцы и специалисты по маркетингу
Представители заказчика
Конечные пользователи

Кто может задокументировать дефект?

Слайд 8

Новый (New). Итак, тестировщик находит дефект и представляет его на рассмотрение в

систему управления дефектами. С этого момента баг начинает свою официальную жизнь и о его существовании знают необходимые люди.
Назначен (assigned). Далее ведущий разработчик рассматривает дефект и назначает его исправление кому-то из команды разработчиков.
Исправлен (fixed). Разработчик, которому было назначено исправление дефекта, исправляет его и сообщает о том, что задание выполнено.
Проверен (verified). Тестировщик, который обнаружил ошибку проверяет на новом билде (в котором исправление данной ошибки заявлено), исправлен ли дефект на самом деле. И только в том случае, если ошибка не проявится на новом билде, тестировщик меняет статус бага на Verified.
Открыт заново (reopened). Если баг проявляется на новом билде, тестировщик снова открывает этот дефект. Баг приобретает статус Reopened.
Отклонён (reject). Баг может быть отклонён. Во-первых, потому, что для заказчика какие-то ошибки перестают быть актуальными. Во-вторых, это может случится по вине тестировщика из-за плохого знания продукта, требований (дефекта на самом деле нет).
Отложен (deferred). Если исправление конкретного бага сейчас не очень важно или заказчик пока думает, или мы ждём какую-то информацию, от которой зависит исправление бага, тогда баг приобретает статус Deferred.
Дублирован (duplicate). Если уже существует открытый баг, который направлен на выявление той же самой ошибки.

Жизненный цикл дефекта

Слайд 9

Иллюстрация жизненного цикла дефекта

Слайд 10

Закрытые (closed) баги. Закрытым считается баг в состояниях Проверен (verified) и Отклонён

(declined) Дублирован (duplicated).
Открытые (open) баги. Открытыми являются баги в состояниях Обнаружен (submitted), Назначен (assigned), Открыт заново (reopened). Иногда к открытым относят и баги в состояниях Исправлен (fixed) и Отложен (deferred).

Открытые и закрытые баги

Слайд 11

Баг/Дефект Репорт (Bug Report) - это документ, описывающий ситуацию или последовательность

действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
Отчёт об ошибке («баг-репорт», «bug report») – один из основных результатов работы тестировщиков. И, к слову, именно этот результат работы видят коллеги (другие тестировщики и люди, не входящие в команду тестировщиков).

Отчеты об ошибках

Слайд 12

Отчеты об ошибках пишутся с целью:
предоставить информацию о проблеме, ее свойствах

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

Цель написания отчета об ошибке

Слайд 13

Основные атрибуты:
Идентификатор (id)
Краткое описание (summary)
Подробное описание (description)
Шаги воспроизведения (steps to reproduce,

STR)
Важность (severity)
Срочность (priority)

Атрибуты отчета об ошибке

Слайд 14

Дополнительные (необязательные) атрибуты:
Возможность «обойти баг» (workaround)
Дополнительная информация (additional information)
Воспроизводимость (reproducible)
Приложения (attachments)
Атрибуты

отчета об ошибке

Слайд 15

У каждого отчета об ошибке должен быть уникальный идентификатор. Как правило, системы управления

ошибками (bug tracking systems) позволяют формировать идентификатор в виде некоторого шаблона, например: Аббревиатура проекта + дата + порядковый номер WSVELC20080625001 Или WS_VELC_20080625_001

Идентификатор (id)

Слайд 16

Хорошее краткое описание должно давать ответы
на три вопроса:
Что?
Где?
При каких

условиях?
Например:
«Отсутствует логотип на странице приветствия, если пользователь является администратором».
«Невозможно открыть файл с именем длиннее 500 символов».
«Приложение виснет при попытке ввести пустой пароль на странице авторизации пользователей»

Краткое описание (summary)

Слайд 17

В отличие от краткого описания, которое, как правило, является одним предложением,

здесь можно и нужно давать подробную информацию. Хорошее подробное описание содержит необходимую информацию об ошибке, а также (обязательно!) описание ожидаемого результата, актуального результата и ссылку на требование (если это возможно). Например: «Если в систему входит администратор, в окне приветствия отсутствует логотип. Ожидаемый результат: логотип присутствует в левом верхнем углу страницы. Фактический результат: логотип отсутствует. Требование: R245.3.23b»

Подробное описание (description)

Слайд 18

Несколько рекомендаций: – Описывайте каждый шаг, пока не столкнётесь с дефектом. – Найдите

точный путь, чтобы воспроизвести дефект. – Попытайтесь найти кратчайший путь. – Повторите все описанные шаги несколько раз и убедитесь, что всё верно. – Описывайте каждое действие, которое вы делаете, в отдельном шаге.
Ещё одна рекомендация (особенно актуальная для начинающих тестировщиков) состоит в том, чтобы последним шагом писать «Возникает ошибка <предельно сжатое описание ошибки>». Это позволяет исключить ситуацию, когда тестировщик забывает записать последний, самый важный шаг, который как раз и приводит к возникновению ошибки.

Шаги воспроизведения (steps to reproduce, STR)

Слайд 19

Пример: 1. Перейти по ссылке: http://www.site.com/login/ 2. Ввести в поле «Логин» значение «admin». 3.

Ввести в поле «Пароль» значение «admpwd». 4. Кликнуть по кнопке «Войти». 5. Баг: в левом верхнем углу вместо логотипа – пустое место.

Шаги воспроизведения (steps to reproduce, STR)

Слайд 20

Это поле показывает, насколько серьёзна найденная ошибка. Обычно, выделяют следующие уровни

важности:
Критическая (critical). Это самые страшные ошибки, выражающиеся в крахе приложения или операционной системы, серьёзных повреждениях базы данных, падению веб-сервера или сервера приложений.
Высокая (major). Серьёзные ошибки, такие как: потеря данных пользователя, падение значительной части функциональности приложения, падение браузера или иного клиента и т.п.
Средняя (medium). Ошибки, затрагивающие небольшой набор функций приложения. Как правило, такие ошибки можно «обойти», т.е. выполнить требуемое действие иным способом, не приводящим к возникновению ошибки.
Низкая (minor). Ошибки, не мешающие непосредственно работе с приложением. Как правило, сюда относятся всевозможные косметические дефекты, опечатки и т.п.

Важность (severity)

Слайд 21

Это поле показывает, как быстро необходимо исправить ошибку. Обычно, выделяют такие

значения срочности:
Наивысшая (ASAP, as soon as possible). Присваивается ошибкам, наличие которых делает невозможным дальнейшую работу над проектом или передачу заказчику текущей версии проекта. Высокая (high). Присваивается ошибкам, которые нужно исправить в самое ближайшее время. Обычная (normal). Присваивается ошибкам, которые следует исправлять в порядке общей очереди. Низкая (low). Присваивается ошибкам, которыми отделу разработки следует заниматься в последнюю очередь (когда и если на них останется время).

Срочность (priority)

Слайд 22

Это поле косвенно влияет на важность и срочность устранения ошибки. Если

некое действие можно выполнить в обход сценария, приводящего к ошибке, поле принимает значение «да» («yes»), в противном случае – поле принимает значение «нет» («no»).

Возможность «обойти баг» (workaround)

Слайд 23

В это поле можно писать всё то, что вы считаете необходимым

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

Дополнительная информация (additional info)

Слайд 24

Это поле показывает, воспроизводится ли баг всегда («always») или лишь иногда

(«sometimes»). Баги, воспроизводящиеся всегда, гораздо проще диагностировать. Однако, очень важно подчеркнуть, что баг воспроизводится не каждый раз при выполнении шагов воспроизведения, если так и есть. Иначе программист сразу же поставит вашему багу статус Отклонён (declined) с резолюцией «Не удалось воспроизвести», если при первом же проходе по шагам воспроизведения баг не появится.

Воспроизводимость (reproducible)

Слайд 25

Лучший способ указать на баг – приложить к баг-репорту некую наглядную

информацию: скриншоты, видеоролики, логи (журналы событий).

Приложения («аттачи») (attachments)

Слайд 26

Пример отчета об ошибке

Слайд 27

Пример отчета об ошибке

Слайд 28

Как обращаться с найденными багами?

Слайд 29

Отчёт, который не даёт достаточной информации «Программа не работает», «Приложение виснет».
Отчёт

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

Какой отчёт об ошибке является плохим?

Слайд 30

Формула совершенного баг-репорта состоит из трёх простых пунктов:
Что мы сделали (steps required

to reproduce the problem)
Что мы получили (actual results)
Что мы ожидали получить (expected results)
Кроме того, нужно сообщить, где именно произошла проблема, при каких условиях, а также дать ошибке название.

Формула совершенного отчета об ошибке

Слайд 31

Программист так и не смог воспроизвести у себя ошибку по той

или иной причине.
Ошибке выставлены неверная важность и/или приоритет.
Отсутствует описание некорректного поведения (актуального результата).
Отсутствует описание ожидаемого результата или оно не обосновано(нет ссылок на требования).
Отчёт написан безграмотно, расплывчато, непонятно.

В каких случаях баг может остаться неисправленным?

Слайд 32

Отсутствуют необходимые для понимания ошибки скриншоты, логи и т.д.
Для описания новой

ошибки, похожей на старую, тестировщик сделал «повторное открытие» уже исправленной ошибки.
Тестировщик не сумел убедить команду в важности проблемы.
У тестировщика плохая репутация.

В каких случаях баг может остаться неисправленным?

Слайд 33

Тщательно объясните, как воспроизвести ошибку. Сообщите всю необходимую для этого информацию,

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

Рекомендации по написанию хороших отчётов об ошибках

Слайд 34

Если существует какая-либо информация, которая может помочь быстро обнаружить и исправить

ошибку, – сообщите эту информацию.
Чётко указывайте окружение (ОС, браузер, настройки и т.п.), под которым произошла ошибка.
В одном отчёте описывайте ровно одну проблему. Если вы видите две ошибки – пишите два отчёта.
Если вам хватает знаний, проведите начальный анализ возможных причин возникновения ошибки и опишите его результаты в разделе «Комментарии».
Попытайтесь найти наиболее серьёзные последствия ошибки. Возможно, то, что казалось незначительным вначале, на самом деле может привести к очень серьёзным неприятностям.

Рекомендации по написанию хороших отчётов об ошибках

Слайд 35

Пишите отчёт об ошибке сразу же, как только вы обнаружили ошибку.

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

Рекомендации по написанию хороших отчётов об ошибках

Слайд 36

Хороший отчёт об ошибках помогает:
Сократить количество ошибок, «возвращаемых» разработчиками (отклонённых или

открытых заново).
Ускорить устранение ошибки.
Сократить стоимость исправления ошибки.
Повысить репутацию тестировщика.
Улучшить взаимоотношения между командами тестирования и разработки.

Преимущества хорошего отчёта об ошибках

Слайд 37

JIRA
Redmine
Bugzilla
QC
Баг-трэкинговые системы

Слайд 38

Lesson 06. Поиск и документирование дефектов

Содержание

Тестирование — это не поиск ошибок!Главное правило тестирования – не надо

Тестирование vs. Поиск ошибок

Рассмотрим несколько определений дефекта:«Быстрое тестирование» (Роберт Калбертсон, Крис Браун, Гэри Кобб):

Мы будем использовать простое определение:Дефект – это несоответствие требованиям или функциональным

«Днём рождения» первого компьютерного бага считается 9 сентября 1945 года. В

Задокументировать дефект может кто угодно, обнаруживший некорректное поведение программы:Тестировщики и специалисты

Новый (New). Итак, тестировщик находит дефект и представляет его на рассмотрение в

Иллюстрация жизненного цикла дефекта

Закрытые (closed) баги. Закрытым считается баг в состояниях Проверен (verified) и Отклонён

Баг/Дефект Репорт (Bug Report) - это документ, описывающий ситуацию или последовательность

Отчеты об ошибках пишутся с целью:предоставить информацию о проблеме, ее свойствах

Основные атрибуты:Идентификатор (id)Краткое описание (summary)Подробное описание (description)Шаги воспроизведения (steps to reproduce,

У каждого отчета об ошибке должен быть уникальный идентификатор. Как правило, системы управления

Хорошее краткое описание должно давать ответына три вопроса:Что? Где? При каких

В отличие от краткого описания, которое, как правило, является одним предложением,

Несколько рекомендаций: – Описывайте каждый шаг, пока не столкнётесь с дефектом. – Найдите

Пример: 1. Перейти по ссылке: http://www.site.com/login/ 2. Ввести в поле «Логин» значение «admin». 3.

Это поле показывает, насколько серьёзна найденная ошибка. Обычно, выделяют следующие уровни

Это поле показывает, как быстро необходимо исправить ошибку. Обычно, выделяют такие

Это поле косвенно влияет на важность и срочность устранения ошибки. Если

В это поле можно писать всё то, что вы считаете необходимым

Это поле показывает, воспроизводится ли баг всегда («always») или лишь иногда

Лучший способ указать на баг – приложить к баг-репорту некую наглядную

Пример отчета об ошибке

Пример отчета об ошибке

Как обращаться с найденными багами?

Отчёт, который не даёт достаточной информации «Программа не работает», «Приложение виснет».Отчёт

Формула совершенного баг-репорта состоит из трёх простых пунктов:Что мы сделали (steps required

Программист так и не смог воспроизвести у себя ошибку по той

Отсутствуют необходимые для понимания ошибки скриншоты, логи и т.д.Для описания новой

Тщательно объясните, как воспроизвести ошибку. Сообщите всю необходимую для этого информацию,

Если существует какая-либо информация, которая может помочь быстро обнаружить и исправить

Пишите отчёт об ошибке сразу же, как только вы обнаружили ошибку.

Хороший отчёт об ошибках помогает: Сократить количество ошибок, «возвращаемых» разработчиками (отклонённых или

JIRARedmineBugzillaQCБаг-трэкинговые системы

Рабочий процесс в JIRA

Похожие презентации

Тестирование — это не поиск ошибок!
Главное правило тестирования – не надо

Рассмотрим несколько определений дефекта:
«Быстрое тестирование» (Роберт Калбертсон, Крис Браун, Гэри Кобб):

Мы будем использовать простое определение:
Дефект – это несоответствие требованиям или функциональным

Задокументировать дефект может кто угодно, обнаруживший некорректное поведение программы:
Тестировщики и специалисты

Отчеты об ошибках пишутся с целью:
предоставить информацию о проблеме, ее свойствах

Основные атрибуты:
Идентификатор (id)
Краткое описание (summary)
Подробное описание (description)
Шаги воспроизведения (steps to reproduce,

Хорошее краткое описание должно давать ответы
на три вопроса:
Что?
Где?
При каких

Отчёт, который не даёт достаточной информации «Программа не работает», «Приложение виснет».
Отчёт

Формула совершенного баг-репорта состоит из трёх простых пунктов:
Что мы сделали (steps required

Отсутствуют необходимые для понимания ошибки скриншоты, логи и т.д.
Для описания новой

Хороший отчёт об ошибках помогает:
Сократить количество ошибок, «возвращаемых» разработчиками (отклонённых или

JIRA
Redmine
Bugzilla
QC
Баг-трэкинговые системы