После того как команда разработчиков устранила дефект и сообщила о нем, команда тестирования проверяет, действительно ли дефект был устранен.
Локализация дефектов и оформление баг-репортов
Дефект (или неисправность) — это ошибка в компоненте или системе, которая может привести к невыполнению компонентом или системой требуемой функции. Дефект, обнаруженный в процессе реализации, может привести к отказу компонента или системы. Например: данные не могут храниться после заполнения анкеты.
Ошибка — это действие человека, которое может привести к неправильному результату. Например, ввод букв в поле даты (должны приниматься только цифры) и последующее сохранение данных.
Ошибка — компонент или система, которые отклоняются от ожидаемого результата, производительности или функции. E.G: При переходе к следующей странице анкеты данные с предыдущей страницы перезаписываются.
Классификация багов
- Функциональные дефекты — в этом случае приложение функционально работает не так, как задумано. Например:
— не сохраняет данные в профиле — не работает добавление комментариев — не удаляет товары из корзины — не работает поиск.
- Визуальные дефекты — в этом случае приложение выглядит не так, как задумано.
— текст перекрывает границы поля, — элемент управления страницей перекрывается под ним, — изображение не отображается.
- Логические дефекты — в этом случае приложение работает неправильно с точки зрения логики.
— можно ввести дату рождения «из будущего», а также несуществующие даты, такие как 31 февраля, 32 декабря и т.д. — можно оформить заказ без указания адреса доставки — логика поиска работает некорректно.
— орфографические и пунктуационные ошибки; — изображение товара не соответствует карточке товара; — конвертация валюты производится по неправильному курсу (калькулятор рассчитывает правильно, но при программировании отображается неправильный курс).
- Дефекты удобства использования — в этом случае приложение неудобно в использовании.
— отсутствие отображения или сообщения об ошибке при неправильном заполнении полей формы; — сброс всех данных при неправильном заполнении формы входа; — перегруженный интерфейс.
- Дефекты безопасности — в этом случае могут быть затронуты пользовательские данные, есть риск падения системы и т.п.
— возможно получение логина и пароля посредством SQL-инъекции; — неограниченное время жизни сессии после авторизации.
Поэтому мы изучили типы и виды дефектов. Теперь давайте поговорим о том, как их документировать.
Документирование ошибок
Отчет о дефекте — это документ, описывающий ситуацию или последовательность действий, которые привели к неправильной работе объекта испытания, с указанием причин и ожидаемого результата.
Вы можете подумать, что «следующим шагом будет документирование ошибок», но это было бы неправильно.
Вы не можете просто пойти и задокументировать найденную ошибку. Прежде всего, важно определить его.
Например, если ошибка может повлиять на другие части системы, она должна появиться в отчете об ошибке, и это предположение должно быть проверено заранее. Также необходимо очень подробно описать все условия и шаги, чтобы разработчик смог проверить и поверить в эту ошибку. Как же искать ошибки в системе, чтобы разработчикам было ясно, откуда берутся эти ошибки и как их исправить? Вам необходимо следовать плану действий, который мы опишем ниже.
Отчет об ошибке
Когда вы сообщаете об ошибке разработчику, сообщение об ошибке должно содержать следующую информацию.
- Defect_ID — уникальный идентификационный номер для дефекта.
- Описание дефекта — подробное описание дефекта, включая информацию о модуле, в котором обнаружен дефект.
- Версия — версия приложения, в которой обнаружен дефект.
- Шаги — подробные шаги вместе со скриншотами, с помощью которых разработчик может воспроизвести дефекты.
- Дата повышения — дата возникновения дефекта
- Ссылка — где в вас предоставить ссылку на документы, как. требования, дизайн, архитектура или даже скриншоты ошибки, чтобы помочь понять дефект
- Detected By — имя / идентификатор тестера, обнаружившего дефект
- Состояние — состояние дефекта, подробнее об этом позже
- Исправлено — Имя / ID разработчика, который это исправил
- Дата закрытия — дата закрытия дефекта
- Серьезность, которая описывает влияние дефекта на приложение
- Приоритет, связанный с срочностью устранения дефектов. Приоритет серьезности может быть Высокий / Средний / Низкий в зависимости от срочности воздействия, при которой дефект должен быть исправлен соответственно.
Нажмите здесь, если видео недоступно.
Рассмотрим следующее в качестве менеджера тестов
Ваша команда обнаружила ошибку при тестировании проекта Guru99 Banki
Управление ошибками — это систематический процесс выявления и устранения ошибок. Цикл управления дефектами включает следующие этапы: 1) обнаружение дефекта, 2) категоризация дефекта, 3) исправление дефекта разработчиками, 4) проверка аудиторами, 5) закрытие дефекта, 6) отчетность по дефектам в конце проекта.
В этой теме вы узнаете, как внедрить процесс управления ошибками на сайте проекта Guru99 Bank. Для устранения ошибок можно выполнить следующие действия.
Давайте кратко проанализируем каждую фазу жизненного цикла
Что такое процесс управления дефектами?
Повторное открытие (повторное открытие)
Чтобы сделать это более понятным, давайте рассмотрим жизненный цикл ошибки с точки зрения членов команды и их ролей.
Жизненный цикл бага
Сначала контроллер находит дефект. Затем он вводит его в систему сообщений об ошибках. Затем программист начинает изучать сообщение об ошибке. На этом этапе он решает, является ли это ошибкой или нет.
- Новый (New) — Тестировщик находит баг, локализует и вносит его в специальную систему, где хранятся баг-репорты. С этого момента баг начинает официально существовать. Далее его статус меняется на Отказ ( Rejected) или на Назначен (Assigned).
- Отказ ( Rejected) — пишется комментарий программиста или менеджера о причине reject-a(отклонения). Это может быть некачественное описание дефекта, такой дефект уже существует (дубликат), невозможность воспроизвести дефект. Также это может произойти потому что для заказчика какие-то ошибки перестали быть актуальными. После этого, тестировщик или закрывает дефект ( Closed ), или дополняет комментарии данного дефекта и переводит дефект заново в состояние Назначен(Assigned) .
- Назначен (Assigned) — дефект просмотрен и открыт (то есть признан для исправления).
- Решен ( Fixed) — дефект исправили и он в этом состоянии требует перепроверки тестировщиком.
- После проверки ошибки тестировщиком, дефект переводится в состояние Переоткрыт (Re-opened) (если дефект не исправлен или исправлен не полностью) либо в Закрыт (Closed), если ошибка исправлена.
Данную схему можно изобразить в текстовом виде. Вот несколько вариантов прохождения багов (можно просто нарисовать на листочке на собеседовании): 1. Новый (new) —>Отклонен (rejected) —>Закрыт (closed) 2. Новый (new) —>Назначен (а ssigned ) —>Решен (fixed) —>Закрыт (closed) 3. Новый (new) —>Назначен (а ssigned ) —>Решен (fixed) —>Закрыт (closed) —>Рассмотрим сценарий, в котором программист впервые обнаружил ошибку. Ему/ей дается задание исправить его, т.е. ректифицировать и пополнить (повторно представить для анализа). После того как разработчик все сделал, ошибка отправляется обратно контроллеру, который тестирует исправления, а также тестирует смежные области (регрессионные тесты).
Жизненный цикл бага с точки зрения команды
Если ошибка больше не воспроизводится, контроллер закрывает ошибку. Если ошибка воспроизводится повторно, он возвращается программисту. И мы снова проходим все шаги, начиная с шага 3 (проверка проблемы разработчиком).
Теперь другой сценарий — программист не принял ошибку. Если ошибка не принята, разработчик отправляет ее обратно нам. Наша задача — проверить проблему. Если ошибка возвращается из-за неправильного описания, мы переписываем его. Если мы не можем воспроизвести ошибку, мы проверяем все шаги, чтобы узнать, не упустили ли мы что-то в описании. Если программист прав и ошибки нет, мы закрываем ошибку. Однако если ошибка все же есть, мы вносим все необходимые исправления и возвращаемся к шагу 3.
Вот как выглядят основные этапы жизненного цикла ошибки. Иногда могут быть добавлены дополнительные шаги в связи с особенностями процедур тестирования в компании. Что всегда остается неизменным, так это то, что ошибка создается и закрывается (прекращает свое существование) по разным причинам.
