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

Тестирование — это не поиск ошибок! Тестирование — это не поиск ошибок! Главное правило тестирования – не надо стараться найти как можно больше ошибок, надо стараться пропустить как можно меньше!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример: 1. Перейти по ссылке: http://www.site.com/login/ 2. Ввести в поле «Логин» значение «admin». 3. Ввести в поле «Пароль» значение «admpwd». 4. Кликнуть по кнопке «Войти». 5. Баг: в левом верхнем углу вместо логотипа – пустое место. Пример: 1. Перейти по ссылке: http://www.site.com/login/ 2. Ввести в поле «Логин» значение «admin». 3. Ввести в поле «Пароль» значение «admpwd». 4. Кликнуть по кнопке «Войти». 5. Баг: в левом верхнем углу вместо логотипа – пустое место.

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

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

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

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

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

Лучший способ указать на баг – приложить к баг-репорту некую наглядную информацию: скриншоты, видеоролики, логи (журналы событий). Лучший способ указать на баг – приложить к баг-репорту некую наглядную информацию: скриншоты, видеоролики, логи (журналы событий).

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

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

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

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

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

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

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

Хороший отчёт об ошибках помогает:  Хороший отчёт об ошибках помогает:  Сократить количество ошибок, «возвращаемых» разработчиками (отклонённых или открытых заново). Ускорить устранение ошибки. Сократить стоимость исправления ошибки. Повысить репутацию тестировщика. Улучшить взаимоотношения между командами тестирования и разработки.

JIRA JIRA Redmine Bugzilla QC

Fixed — решен. Fixed — решен. Won't Fix — не может быть решен. Duplicate — дублирует. Incomplete — неполностью описан. Cannot Reproduce — не воспроизводим (этот запрос не может быть воспроизведен в это время, или не достаточно информации. Если появляется  информация, можно переоткрыть запрос).