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

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

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

Введение

Браун, Гэри Кобб): «Программная ошибка – ни что иное,

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

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

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

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

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

1945 года. В Гарвардском университете, где работал этот компьютер,

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

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

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

и специалисты по маркетингу
Представители заказчика
Конечные пользователи

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

на рассмотрение в систему управления дефектами. С этого момента

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

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

(verified) и Отклонён (declined) Дублирован (duplicated).
Открытые (open) баги. Открытыми являются

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

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

ситуацию или последовательность действий приведшую к некорректной работе объекта

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

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

проблеме, ее свойствах и последствиях;
приоритизировать проблему по важности и

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

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

(steps to reproduce, STR)
Важность (severity)
Срочность (priority)
Атрибуты отчета об ошибке

information)
Воспроизводимость (reproducible)
Приложения (attachments)
Атрибуты отчета об ошибке

правило, системы управления ошибками (bug tracking systems) позволяют формировать

идентификатор в виде некоторого шаблона, например: Аббревиатура проекта + дата + порядковый номер WSVELC20080625001 Или WS_VELC_20080625_001

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

Где?
При каких условиях?
Например:
«Отсутствует логотип на странице приветствия, если

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

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

является одним предложением, здесь можно и нужно давать подробную

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

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

с дефектом. – Найдите точный путь, чтобы воспроизвести дефект. – Попытайтесь

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

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

«Логин» значение «admin». 3. Ввести в поле «Пароль» значение «admpwd». 4.

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

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

выделяют следующие уровни важности: 
Критическая (critical). Это самые страшные ошибки,

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

Важность (severity)

Обычно, выделяют такие значения срочности:
Наивысшая (ASAP, as soon as possible).

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

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

устранения ошибки. Если некое действие можно выполнить в обход

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

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

вы считаете необходимым отметить, но что не подходит для

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

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

или лишь иногда («sometimes»). Баги, воспроизводящиеся всегда, гораздо проще

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

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

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

(«аттачи») (attachments)

работает», «Приложение виснет».
Отчёт об ошибках в той части функциональности,

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

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

сделали (steps required to reproduce the problem)
Что мы получили

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

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

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

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

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

т.д.
Для описания новой ошибки, похожей на старую, тестировщик сделал

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

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

для этого информацию, а также свои размышления о возможных

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

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

обнаружить и исправить ошибку, – сообщите эту информацию.
Чётко указывайте

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

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

вы обнаружили ошибку. Откладывание записи «на потом» приводит к

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

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

разработчиками (отклонённых или открытых заново).
Ускорить устранение ошибки.
Сократить стоимость исправления

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

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