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

1. ДОКУМЕНТИРОВАНИЕ
ДЕФЕКТОВ

2. ОТЧЕТ ОБ ОШИБКЕ (BUG REPORT)
Это документ (именно документ), в котором
предоставляется информация о некорректной
работе или о недостатках объекта
тестирования.
1
дефект
1
отчет

3. КАКУЮ КОНКРЕТНО ИНФОРМАЦИЮ СОДЕРЖИТ
ДАННЫЙ ОТЧЕТ?
 Отчет должен содержать сведения о конфигурации
приложения, о тестовом окружении, а также детали,
которые помогут разработчикам максимально
быстро разобраться с данной проблемой.
 Следует описать последовательность действий,
приведших систему в текущее состояние, с
указанием ожидаемого результата.

4. Хорошо
составленный
отчет об ошибке
показатель
профессионализма
тестировщика.

5. Грамотный отчет
упрощает
работу
разработчиков
по устранению
ошибки
экономит
время
команды

6. КАК ВЫ БУДИТЕ ОПИСЫВАТЬ ДЕФЕКТ?
Дорогой разработчик!
Нашей команде очень понравился твой
проект, особенно форма регистрации.
Но нам кажется, что в ней не хватает
кнопки «Зарегистрироваться».
После добавления этой замечательной
кнопки пользователи по всему миру смогут
создавать почтовые ящики.
Пожалуйста, добавь кнопку на форму.
С уважением,
тестировщик Иванов И.И.

7. Баг репорт -
это
технический
документ
язык описания
проблемы
должен быть
техническим.

8. Какие поля нужны для
описания дефекта?

9. ИДЕНТИФИКАТОР (ID)
Уникальный идентификатор, номер
дефекта.
Например,
Аббревиатура проекта + порядковый номер
WSVELC0001
или WS_VELC_0001

10. КОРОТКОЕ ОПИСАНИЕ (SUMMARY)
В одном предложение необходимо
уместить смысл всего баг репорта,
а именно: коротко и ясно,
используя правильную
терминологию указать что и где не
работает.
Длина заголовка не превышает
140 символов.

11. ЗАГОЛОВОК ОТЧЕТА О ДЕФЕКТЕ ДОЛЖЕН
ОТВЕЧАТЬ НА ТРИ ВОПРОСА
• В каком месте интерфейса или
архитектуры программного продукта
находится проблема. Начинайте
предложение с существительного, а не
предлога.
Где?
• Что происходит или не происходит
согласно спецификации или вашему
представлению о нормальной работе
программного продукта.
Что?
• В какой момент работы программного
продукта, по наступлению какого
события или при каких условиях
проблема проявляется.
Когда?
иили при
каких
условиях

12. ПРИМЕР 1
 Приложение “TextWork” зависает, при
попытке сохранения текстового файла
размером больше 50Мб.
Приложение
“TextWork”
зависает,
при попытке
сохранения
текстового файла
размером больше
50Мб.
• Где? • Что? • Когда?

13. ПРИМЕР 2
 В приложении есть форма «Добавить товар» с
кнопкой «Сохранить». При нажатии этой кнопки
данные, вводимые в поля формы, должны
сохраниться в БД. Однако этого не происходит.
Данные на
форме
"Добавить
товар"
не
сохраняются
после
нажатия
кнопки
"Сохранить”
• Где? • Что? • Когда?

14. Данные на
форме
"Добавить
товар"
не
сохраняются
после
нажатия
кнопки
"Сохранить”
• Где? • Что? • Когда?
Summary: Данные на форме "Добавить товар"
не сохраняются после нажатия кнопки
"Сохранить".

15. PROJECT (ПРОЕКТ)
Официальное название
тестируемого проекта.

16. Дата создания (Created Date) – дата
создания отчета.
Дата обновления (Update Date) –
дата обновления (изменение,
закрытие).

17. ТЕКУЩИЙ СТАТУС (STATUS)
Open
In
Progress
Resolved Closed Reopened

18. КОМПОНЕНТ (Ы) (COMPONENT)
Название части или функции
тестируемого проекта, к
которой относится дефект.

19. ПРИОРИТЕТ (PRIORITY)
Свойство, указывающее на
очередность устранения дефекта.
Чем выше приоритет, тем быстрее
нужно приступить к реализации
задачи.

20. БАЗОВЫЙ НАБОР ПРИОРИТЕТОВ:
• критическая ошибка для проекта.
Дефект должен быть исправлен в
самые кратчайшие сроки.
High
(Высокий)
• ошибка не является критичной,
но обязательно должна быть
исправлена до релиза. Не
требует срочного решения.
Medium
(средний)
• незначительная ошибка,
исправить при наличии
свободных ресурсов.
Low
(незначительный)

21. ПОРЯДОК ИСПРАВЛЕНИЯ ОШИБОК ПО
ПРИОРИТЕТАМ:
High Medium Low

22. СЕРЬЕЗНОСТЬ (SEVERITY)
Влияние дефекта на работоспособность
приложения.
Набор степеней строгости дефектов завит от
выбранного процесса разработки и
договоренностей между участниками проекта.

23. • Дефект полностью блокирует работу
приложения.
Блокирующий
(Blocker)
• Неправильно работающая функция,
сбой, потеря данных, тяжелая утечка
памяти.
Критический
(Critical)
• Дефект нарушает нормальную
работу одной или нескольких
функций приложения.
Значительный
(Major)
• Незначительная ошибка, не
нарушающая логику тестируемой
части приложения.
Незначительный
(Minor)
• Несущественная ошибка, не
оказывающая никакого влияния на
общее качество продукта.
Тривиальная
(Trivial)

24. РЕЗОЛЮЦИЯ (RESOLUTION)
Unresolved
Fixed
Incomplete
Cannot
Reproduce
Duplicate Won‘t Fix

25. ВЕРСИЯ ПРИЛОЖЕНИЯ, ДЛЯ КОТОРОЙ ДЕФЕКТ
АКТУАЛЕН (AFFECTS VERSION)
Версия проекта, в которой найден
дефект, а также версии, на которых дефект
воспроизводится.

26. ВЕРСИЯ ПРИЛОЖЕНИЯ, ДЛЯ КОТОРОЙ
ДЕФЕКТ БЫЛ ЗАКРЫТ (FIX VERSION)
Версия приложения, в которой
дефект был закрыт.

27. АВТОР (REPORTER)
Имя создателя отчета о дефекте.
Создателем отчета не обязательно
должен быть специалистом по
тестированию, им может быть любой
участник проекта или даже
пользователи.

28. НА КОГО НАЗНАЧЕН ОТЧЕТ (ASSIGNEE)
Имя сотрудника, назначенного на
решение проблемы.

29. МЕТКИ (LABELS)
Метки используются для
систематизации информации.
В дальнейшем метки служат для сбора
метрик, поиска дефектов и т.п.

30. КАТЕГОРИЯ ДЕФЕКТА (CATEGORY)
• дефекты, относящийся к функциям
объекта тестирования. Functional
• грамматические ошибки в тестовых
элементах приложения. Text
• дефекты графического интерфейса
пользователя. Design
Documentation • ошибки в требованиях, спецификации.
• проблемы с производительностью
приложения. Performance
• проблемы, связанные не с самим
приложением, а с библиотеками,
серверами, сторонними инструментами,
Technical

31. ОКРУЖЕНИЕ (ENVIRONMENT)
Окружение, на котором найден дефект:
операционная система, браузер, версия
браузера, сервер и т.п.
Если дефект воспроизводится на всех
окружениях, то ставится соответствующий
комментарий.

32. ОПИСАНИЕ / ШАГИ ВОСПРОИЗВЕДЕНИЯ
(DESCRIPTION)
Информация, требуемая для
воспроизведения ситуации, приведшей
к ошибке.
В данном разделе необходимо описать
шаги, по которым можно легко
воспроизвести ситуацию, приведшую к
ошибке.

33. РЕКОМЕНДАЦИИ
Описывайте каждый шаг, пока не столкнётесь с
дефектом.
Найдите точный путь, чтобы воспроизвести дефект.
Попытайтесь найти кратчайший путь.
Повторите все описанные шаги несколько раз и
убедитесь, что всё верно.
Описывайте каждое действие, которой вы делаете, в
отдельном шаге.

34. ПРИМЕР:
1. Перейти по ссылке:
http://www.site.com/login/
2. Ввести в поле «Логин» значение
«admin».
3. Ввести в поле «Пароль» значение
«admpwd».
4. Кликнуть по кнопке «Войти».

35. RESULT (ФАКТИЧЕСКИЙ РЕЗУЛЬТАТ)
Результат, полученный после прохождения
шагов к воспроизведению
Пример:
 На экране появляется сообщение об ошибке.
Вход в систему не возможен.

36. EXPECTED RESULT (ОЖИДАЕМЫЙ РЕЗУЛЬТАТ)
Ожидаемый правильный результат.
Пример:
1. Пользователь входит в систему.
2. В правом верхнем углу отражается имя
пользователя.

37. ПРИЛОЖЕНИЯ (ATTACHMENTS)
Любая информация, которая может
помочь прояснить причину ошибки или
указать на способ решения проблемы:
 скриншот,
 видео,
 любой другой документ.