Тестирование ИС Практическая работа №20

Практическая работа №20

Тема: Баг-репорт. Баг-трекер. Практика нахождения багов. Составление отчета.

Баг-репорт (bug report) — это технический документ, который подробно описывает ошибку в работе программы, приложения или другого ПО. Его составляет тестировщик, чтобы разработчикам было понятно, что работает неправильно, насколько дефект критичен и что нужно исправить.

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

Виды багов

• Функциональные. Возникают, когда фактический результат работы не соответствует ожиданиям: не получается опубликовать комментарий на сайте, добавить товар в корзину или открыть страницу.

• Визуальные. Это случаи, когда приложение выглядит иначе, чем задумано: кнопка накладывается на текст, не отображаются картинки или текст выходит за пределы окна.

• Логические. Баг, при котором что-то работает неправильно с точки зрения логики, — например, когда можно указать несуществующую дату (31 февраля) или поставить дату рождения из будущего (2077 год).

• Дефекты UX. Приложение или программа неудобны в использовании: при просмотре ленты новостей пользователя постоянно отбрасывает к началу, слишком близко расположены кнопки и вместо одной нажимается другая.

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

Структура баг-репорта

Баг-репорт включает обязательные и необязательные элементы.

Обязательные поля:

• ID — идентификационный номер баг-репорта, должен быть уникальным. Помогает быстро найти нужный баг-репорт.

• Заголовок — передает суть ошибки; помогает быстро понять, в чем дело.

• Шаги воспроизведения — пошаговая инструкция о том, как воспроизвести ошибку.

• Результаты — описание фактического результата и ожидаемого результата.

• Окружение — операционная система, браузер, устройство (в случае мобильного приложения), версия приложения.

• Приоритет — показывает степень критичность ошибки и срочность ее исправления.

Необязательные поля:

• Предусловие — описывает, как систему нужно подготовить перед тестированием (в случае необходимости).

• Постусловие — указывает, как систему нужно вернуть в прежний вид после тестирования (в случае необходимости).

• Описание — прописывают, если в заголовке передано недостаточно информации об ошибке.

• Дополнительные материалы — прикладываются в случае необходимости и помогают проиллюстрировать ошибку (скриншот, скринкаст).

Заголовок баг-репорта

Задача заголовка — в достаточной мере описать суть проблемы. Грамотно написанный заголовок помогает коллегами сразу понять суть, не тратя время на прочтение всего баг-репорта целиком. Заголовок должен отвечать на три вопроса: «Что? Где? Когда?», при этом не должен быть слишком длинным. Заголовок должен отражать реальный результат.

Примеры удачных заголовков:

• Клик по слову «Регистрация» на странице подписки приводит к ошибке 400.

• При переходе по ссылке «Заказ» на главной странице экрана открывается страница Контакты вместо страницы Мои заказы.

Шаги

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

Результаты

Ожидаемый результат (Expected Result)

Результат, который должен быть при выполнении шагов. В идеале, его можно найти в ТЗ (техническом задании). На практике, ТЗ бывает не всегда и ожидаемый результат определяется либо здравым смыслом, либо по аналогии.

Пример плохого ожидаемого результата: Что-то должно произойти.
Пример хорошего ожидаемого результата: Сообщение отправляется либо система сообщает о невозможности его отправки.

Фактический результат (Actual Result)

Указывается результат, который получил тестировщик при выполнении описанных шагов. Также может отвечать на три вопроса “Что? Где? Когда?”.

Пример плохого фактического результата: Ничего нет.
Пример хорошего фактического результата: Сообщение не отправляется, не появляется ошибка об отправке. После нажатия на кнопку ничего не происходит.

Приоритет и серьезность

Приоритет (priority) отражает степень важности проблемы и срочность выполнения задачи, включает 3 уровня: 

• Р1 Высокий (high) — необходимо исправить в первую очередь, так как с данной ошибкой продукт не выполняет свой бизнес-задачи: например, не работает кнопка заказа в интернет-магазине.

• Р2 Средний (medium) — ошибка менее критичная, пользователь может достигнуть цели, однако ПО работает не так, как от него ожидается. Например, в корзине интернет-магазина не отображается блок сопутствующих товаров.

• Р3 Низкий (low) — не мешает пользователю достигнуть цели, можно починить после критических ошибок. Например, опечатки в тексте.

Серьезность (severity)  — это показатель влияния бага на работу программы, того, может ли она функционировать без исправления или баг ломает всю систему. Выделяют пять уровней серьезности багов:

• S0 Trivial (Тривиальный) — баг не влияет на работу программы, поэтому для его исправления могут не выделить отдельную задачу, а исправить попутно при исправлении других, похожих ошибок. Например, при заполнении анкеты в поле «Дата рождения» по умолчанию отображается не актуальный год, а 1999-й.

• S1 Minor (Незначительный) — баг почти не нарушает логику процессов, поэтому с ним программа может нормально работать. Например, неудобная навигация в интерфейсе.

• S2 Major (Серьезный) — баг создает неудобства в использовании, но еще не нарушает функционал программы.

• S3 Critical (Критический) — баг мешает приложению выполнять основные функции: калькулятор расходов неправильно считает бюджет или в текстовом редакторе невозможно вводить текст.

• S4 Blocker (Блокирующий) — ситуация, когда программа не работает в принципе: сайт выдает «ошибку 404» или не запускается приложение.

Окружение

В этом пункте описывается среда, в которой произошла ошибка. Операционная система и ее версия, браузер и его версия, версия приложения, размер экрана (если необходимо). Если ошибка произошла на мобильном устройстве, также указывается тип устройства и его модель.

Вложения (вспомогательные материалы)

Помогают дополнить информацию о проблеме, визуализируют ошибку. К баг-репорту можно прикрепить:

• Скриншоты и скринкасты

• Логи, дампы

• Переписки

• Документацию

Пример шаблона отчета баг-репорта

Поля варьируются в зависимости от правил конкретной компании, но чаще всего каждый документ содержит следующие пункты:

Пример №2

Жизненный цикл бага

Статус бага в репорте определяется его «жизненным циклом», который состоит из четырех основных стадий:

• Открыт (Open) — тестировщик выявил баг и добавил в репорт.

• В работе (In Progress) — о баге сообщили исполнителю, и он занимается исправлением.

• Исправлен (Ready for check) — исполнитель закончил работу по исправлению бага и передал проект на повторную проверку тестировщику.

• Закрыт (Closed) — баг устранен и больше не воспроизводится.

Кроме основных есть еще несколько статусов:

• Отклонен (Rejected) — исправлению бага помешала ошибка в репорте, например неверный алгоритм в пункте «Шаги к воспроизведению».

• Отсрочен (Deferred) — баг признан неприоритетным и исправление переносится.

• Переоткрыт (Reopened) — баг был отсрочен или отклонен, но теперь исполнитель взял его в работу.

Как правильно писать баг-репорт

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

На что стоит обратить внимание при описании дефекта?

Выявить причину возникновения. Например, если на сайте не получается восстановить пароль, то проблема может быть как в бэкенде, так и во фронтенде. Задача тестировщика — разобраться в ней, так как от этого зависит, кому из разработчиков отдавать баг на исправление.

Провести проверку на разных устройствах. Если проблема есть в десктоп-версии, то она может возникнуть и на мобильных устройствах, поэтому стоит проверить.

Провести проверку в разных версиях ПО. Баг может не воспроизводиться в старой версии ПО, но появится в новой.

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

Ход работы

1. Создайте новый проект на языке C#.

2. Напишите код, который содержит ошибки (например, неправильное условие в операторе if).

3. Запустите программу и убедитесь, что она работает неправильно.

4. Составьте отчет о баге, включающий следующую информацию:

- Описание проблемы

- Шаги, которые привели к возникновению проблемы

- Ожидаемый результат

- Фактический результат

- Версия программного обеспечения

- Окружение (операционная система, аппаратная платформа и т.д.)

5. Отправьте отчет о баге разработчикам программного обеспечения.

6. После исправления бага, проверьте программу еще раз, чтобы убедиться, что проблема была решена.

7. Составьте отчет о том, что баг был исправлен.

8. Отчеты о багах и их исправлениях должны быть включены в документацию проекта.

Пример кода с ошибкой:

// Функция для проверки, является ли число четным

public bool IsEven(int number)

{

if (number % 2 == 0)

{

return true;

}

else

{

return false;

}

}

Пример отчета о баге:

Описание проблемы:

Функция IsEven возвращает неправильный результат для нечетных чисел.

Шаги, которые привели к возникновению проблемы:

1. Вызвать функцию IsEven с нечетным числом (например, 3).

2. Проверить результат.

Ожидаемый результат:

Функция должна возвращать false для нечетных чисел.

Фактический результат:

Функция возвращает true для нечетных чисел.

Версия программного обеспечения:

1.0

Окружение:

Windows 10, x64

Пример отчета о исправлении бага:

Описание исправления:

Исправлена ошибка в функции IsEven, которая приводила к неправильному результату для нечетных чисел.

Шаги, которые были предприняты для исправления проблемы:

1. Изменено условие в операторе if.

2. Проведено тестирование, чтобы убедиться, что функция работает правильно для четных и нечетных чисел.

Ожидаемый результат:

Функция должна возвращать правильный результат для всех чисел.

Фактический результат:

Функция возвращает правильный результат для всех чисел.

Версия программного обеспечения:

1.1

Окружение:

Windows 10, x64

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