5.17M

Category:

programming

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

1.

Занятие 8
Поиск и документирование
дефектов

2.

Введение
Тестирование - это не поиск багов!
Главное правило тестирования –
не надо стараться найти
как можно больше ошибок,
а надо стараться пропустить как можно меньше!
it-courses.by

Тестирование VS Поиск ошибок
Основная задача
Области
тестирования
Тесты (сценарии)
it-courses.by
Поиск ошибок
Тестирование
Завести как можно
больше багов
Пропустить как можно
меньше приоритетных
для пользователя багов
Самые нестабильные =
менее приоритетные
для пользователя
Самые приоритетные
для пользователя,
даже если они стабильны
Нестандартные
Стандартные

4.

Определение дефекта
Программная ошибка – изъян в ПО, который вызывает
несоответствие ожидаемых результатов выполнения
и фактически полученных результатов.
Баг (bug) – это отклонение фактического результата (actual result)
от ожидаемого результата (expected result).
Дефект – поведение программы, затрудняющее (делающее
невозможным) пользователю достигнуть цели или удовлетворить
интересы. Подразумевает возможность исправления. При
невозможности переходит в разряд ограничения технологии.
it-courses.by

5.

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

6.

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

7.

Из истории
it-courses.by

8.

Кто может задокументировать баг?
Тестировщики и специалисты по качеству
Разработчики
Представители службы технической поддержки
Продавцы и специалисты по маркетингу
Представители заказчика
Конечные пользователи
it-courses.by

9.

Статусы бага
Новый (New) или Открыт (Open)
Итак, тестировщик находит дефект и заносит его в систему управления
дефектами. С этого момента баг начинает свою официальную жизнь и о его
существовании знают необходимые люди.
Назначен (assigned)
Далее разработчик рассматривает дефект и назначает его исправление
кому-то из команды разработчиков.
Исправлен (fixed)
Разработчик, которому было назначено исправление дефекта, исправляет
его и сообщает о том, что задание выполнено.
it-courses.by

10.

Статусы бага
Проверен (verified)
Тестировщик, который обнаружил ошибку проверяет на новом билде (в
котором исправление данной ошибки заявлено), исправлен ли дефект на
самом деле. И только в том случае, если ошибка не проявится на новом
билде, тестировщик меняет статус бага на Verified.
Открыт заново (reopened)
Если баг проявляется на новом билде, тестировщик снова открывает этот
дефект. Баг приобретает статус Reopened.
Не могу воспроизвести (can not reproduce)
Если в описании бага нет всей необходимой информации, программист не
сможет его воспроизвести, чтобы починить
it-courses.by

11.

Статусы бага
Не баг (not a bug)
Баг может быть отклонён. Во-первых, потому, что для заказчика какие-то
ошибки - не ошибки. Во-вторых, это может случиться по вине тестировщика
из-за плохого знания продукта, требований (дефекта на самом деле нет).
Не чинить (will not fix)
Формально это баг, но чинить его не будут, не могут или не хотят.
Дублирован (duplicate)
Если уже существует открытый баг, который направлен на выявление той
же самой ошибки.
it-courses.by

12.

Жизненный цикл бага
Reopen
New / Open
Reopen
Assigned
Fixed
Not a bug
Will not fix
Verified
Closed
it-courses.by
Duplicate
Can not reproduce

13.

Открытые и закрытые баги
Закрытые (closed) баги
• Проверен (verified)
• Отклонён (not a bug, will not fix)
• Дублирован (duplicated)
Открытые (open) баги
• Открыт (Opened)
• Назначен (assigned)
• Открыт заново (reopened).
• Исправлен (fixed)
it-courses.by

14.

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

15.

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

16.

Атрибуты баг репорта
1. Идентификатор (id)
2. Краткое описание (summary)
3. Подробное описание (description):
1. Шаги воспроизведения (steps to reproduce, STR)
2. Актуальный результат (Actual Result)
3. Ожидаемый результат (Expected Result)
4. Важность (severity)
5. Срочность (priority)
it-courses.by

17.

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

18.

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

19.

Краткое описание (summary)
Хорошее краткое описание должно давать ответы на три вопроса:
• Что?
• Где?
• При каких условиях?
Например:
Нет логотипа на странице приветствия, если пользователь
администратор
Невозможно открыть файл с именем > 500 символов
Приложение виснет при попытке ввести пустой пароль на странице
авторизации
it-courses.by

20.

Шаги воспроизведение (steps)
Описывайте каждый шаг, пока не столкнётесь с дефектом
Найдите точный путь, чтобы воспроизвести дефект
Попытайтесь найти кратчайший путь
Повторите все шаги несколько раз и убедитесь, что всё верно
Описывайте каждое действие в отдельном шаге
it-courses.by

21.

Шаги воспроизведения. Пример
1. Перейти по ссылке: http://www.site.com/login/
2. Ввести в Логин "admin"
3. Ввести в Пароль "admpwd"
4. Кликнуть Войти
Actual result: В левом верхнем углу вместо логотипа – пустое место
Expected result: В верхнем углу есть логотип
it-courses.by

22.

Важность (Severity)
Блокирующая (blocker)
Критическая (critical)
Это поле показывает
насколько ошибка затрагивает
значимый функционал
приложения.
Высокая (major)
Низкая (minor)
Самая низкая (trivial)
it-courses.by

23.

Важность. Blocker и Critical
Блокирующая (blocker)
Ошибка, полностью блокирующая
тестирование функционала
Критическая (critical)
Крах приложения (crash), повреждения данных
Как вариант, разница между blocker от critical - это наличие workaround
it-courses.by

24.

Важность. Major and Minor
Высокая (major)
Серьёзные ошибки, такие как: потеря данных пользователя,
некорректность обработки запросов и полей.
Низкая (minor)
Ошибки, не мешающие непосредственно работе с приложением. Как
правило, сюда относятся всевозможные косметические дефекты,
опечатки и т.п.
it-courses.by

25.

Важность. Trivial
Самая низкая (trivial)
Ошибки дизайна, орфографические ошибки и другие ошибки,
вызывающие дискомфорт при использовании ПО.
it-courses.by

26.

Срочность (Priority)
Это поле показывает, как быстро необходимо исправить ошибку.
Наивысшая (ASAP, as soon as possible)
Высокая (high)
Обычная (normal)
Низкая (low)
it-courses.by

27.

Срочность. ASAP
Наивысшая (ASAP, as soon as possible).
Ошибки, которые делают невозможным дальнейшую работу
над проектом или передачу
заказчику текущей версии проекта.
it-courses.by

28.

Срочность. High
Высокая (high).
Ошибки, которые нужно исправить в самое ближайшее время.
it-courses.by

29.

Срочность. Normal
Обычная (normal).
Ошибки,
которые
следует исправлять
в порядке
общей очереди
it-courses.by

30.

Срочность. Low
Низкая (low).
Ошибки, которыми будут заниматься в последнюю очередь (когда и если
на них останется время).
it-courses.by

31.

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

32.

Additional info (доп. информация)
В это поле можно писать всё то, что вы считаете необходимым
отметить, то, что не подходит
для размещения в других полях.
Комментарии, мысли,
анализ возможных причин
появления бага
и путей его устранения –
всё это пишется здесь.
it-courses.by

33.

Reproducing (воспроизводимость)
Не всегда баг одназначно воспроизводится. Тогда отмечают сколько
раз из 10 его удалось повторить. (3/10, 9/10…)
Баги, воспроизводящиеся всегда, гораздо проще диагностировать.
Однако, очень важно подчеркнуть,
что баг воспроизводится не каждый раз
при выполнении шагов воспроизведения,
если это так. Иначе можно сразу
получить статус – Не воспроизводим
(can not reproduce).
it-courses.by

34.

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

35.

Пример bug report-а
https://goo.gl/fmPJu7
it-courses.by

36.

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

37.

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

38.

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

39.

Когда баг вряд ли исправят
Нет нужных для понимания ошибки скриншоты, логи и т.д.
Для описания новой ошибки, похожей на старую, тестировщик
сделал «повторное открытие» уже исправленной ошибки.
Тестировщик
не сумел убедить команду
в важности проблемы.
it-courses.by

40.

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

41.

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

42.

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

43.

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

44.

Баг-трекинговые системы
Баг трекер – прикладная программа (браузерная или десктопная) для
учета и контроля ошибок, найденных в разрабатываемых программах,
пожеланий и запросов пользователей, отслеживания прогресса
устранения ошибок и выполнения запросов пользователей
it-courses.by

45.

Какие багтрекеры сейчас
наиболее популярны
JIRA
Redmine
Bontq
YouTrack
Bugzilla
it-courses.by

46.

Jira
Коммерческая система отслеживания ошибок и управления
проектами.
Это инструмент для организации эффективного взаимодействия
участников процесса или проекта
Учет
Процессы
Общение
Аналитика
Типы запросов
Атрибуты
Файлы
Связь и поиск
Уровень доступа
it-courses.by
Этапы процесса
Ответственные
Уведомления
Маршруты
нормативы
Рабочие столы
Комментарии
Лента событий
История
Подписка
Учет трудозатрат
Отчеты по стадиям
Тренды
Анализ активностей
Экспорт данных

47.

Сценарии использования Jira
Task Manager – управление задачами
Software development – управление процессом разработки
Bug Tracker/Help Desk – учет ошибок, управление инцидентами
CRM – взаимодействие с клиентами
Agile – гибкое управление проектами
SCM – управление требованиями
BPM – управление бизнес-процессами
it-courses.by

48.

Принципы работы Jira
Ключевые понятия – проекты/projects и запросы/issues
Запросы группируются по проектам и создаются в них
Запросы получают исполнителей
Запросы могут иметь разные типы и иметь подзадачи
Запросы могут быть объединены в группы или иметь другие связи
Запросы имеют статус, который меняется в процессе их
выполнения
it-courses.by

49.

Проекты в Jira
Проект в Jira – набор запросов
Каждый проект имеет имя, e.g. My WebSite и ключ, e.g. WEB
Проект состоит из компонентов. Это подсекции проекта,
позволяющие группировать запросы по областям, к примеру
отдельные функциональности, пользователи, логический блоки и
т.д.
Созданный запрос относится к одному или нескольким
компонентам, запросу назначается исполнитель
Проект может быть разбит на версии. Каждая новая версия
содержит новый функционал по отношению к предыдущей
it-courses.by

50.

Управление доступом в Jira
Для организации работы в Jira используются группы пользователей и роли.
Группы пользователей – система разрешенного доступа к компонентам и
функциям проекта, e.g. администрирование проекта, добавление
комментариев, удаление запросов и прочее
На основе групп пользователей и их прав доступа формируются роли
Простейшая система разделения ролей
• Администратор
• Руководитель проекта
• Сотрудники, работающие над проектом
• Другие сотрудники, вовлеченные в проект
it-courses.by

51.

Запросы в Jira. Типы
В Jira существует четыре типа типов запросов по умолчанию
Epic – тип запроса для большой
пользовательской истории
История/User story – небольшая часть
функциональности, на которые
разбивается Epic
Задача/Task – задание для выполнения,
на которые разбиваются User story
Ошибка/bug – отчет об ошибке
В зависимости от проекта и необходимостей можно добавлять любые
другие типы запросов вручную
it-courses.by

52.

Запросы в Jira. Уровни
приоритетов
Наивысший приоритет. Блокирует процесс
Высокий уровень. Может блокировать процесс
Средний уровень. Может воздействовать на
процесс
Низкий уровень. Легко обойти
Нижайший уровень. Тривиальная проблема
Уровни приоритетов также можно конфигурировать и добавлять
it-courses.by