Баг – это нарушение в работе программы, вызванное ошибкой в программном коде или дизайне продукта. Задача тестировщика – найти баги, сообщить о них разработчику и проследить исправление ошибки. Чтобы сделать этот процесс эффективнее, нужно знать устоявшуюся классификацию багов и их жизненный цикл.
Классификацию дефекта и его полное описание тестировщики заносят в Баг-репорт. Читайте нашу статью о тестовой документации, чтобы узнать, зачем нужны Баг-репорты и как мы их составляем.
Для каждого бага устанавливается уровень серьёзности (severity) и приоритетности (priority). Серьёзность бага определяет, насколько сильно он влияет на работоспособность системы. А приоритетность — как быстро нужно исправить дефект.
Классификация багов по серьёзности:
| 1 | Блокирующий (Blocker) | Ни один элемент системы не работает: никто не может ей пользоваться. Продукт не выполняет свою задачу. Пример: сайт не открывается или выдаёт ошибку про любом действии. |
| 2 | Критический (Critical) | Дефект, выбивающий из строя часть ключевого функционала системы. Пользоваться программой можно, но высока вероятность сбоя. Пример: В интернет-магазине не работает функция оплаты картой. Заказ можно оформить, но для оплаты приходится связываться с менеджерами. |
| 3 | Высокий (Major) | Система работает, но не так, как должна. Пользоваться можно, элементы активны, но выполняют не то, что задумано. Пример: При нажатии на кнопку “Оставить почту и получить скидку”, пользователю автоматически назначается скидка даже если он не оставил контакты. |
| 4 | Низкий (Minor) | С системой всё в порядке, но работать с ней неудобно. Сюда же относятся большинство дизайнерских недочётов. Пример: Неправильно масштабируется рекламный баннер при уменьшении окна. |
| 5 | Незначительный (Trivial) | Баг, который не влияет на работу программы. Пример: опечатки в тексте или лишняя фотография в карточках товаров. |
Классификация багов по приоритетности исправления:
- Высокий приоритет (High).
Дефект требует оперативного устранения. Традиционно в эту категорию попадают блокирующие, критические и высокие по степени влияния баги. - Средний приоритет (Medium).
Ошибка не критичная, но она мешает работе системы и должна быть исправлена. - Низкий приоритет (Low).
Это незначительные баги, которые не мешают пользователю работать с сайтом. Их исправляют в последнюю очередь
Жизненный цикл бага:
| 1 | “Новый” | Дефект программы замечен тестировщиком, внесён и описан в баг-репорте. |
| 2 | “Открыт” | Руководитель команды оценил дефект и признал, что он требует исправления. Баг передаётся разработчику. |
| 3 | “Отклонён” | Руководитель команды оценил дефект и признал, что он не требует исправления. Например, эта ошибка уже была внесена в систему и её взяли в работу. |
| 4 | “Отложен” | Руководитель команды оценил дефект и признал, что сейчас он не требует правок. Например, у бага низкая приоритетность на этом этапе разработки. |
| 5 | “Исправлен” | Разработчик внёс правки и переводит баг в этот статус, если считает, что дефект устранён. |
| 6 | “Повторно открыт” | Тестировщик проверил баг и заметил, что исправлены не все дефекты и/или появились новые. Баг снова возвращается на доработку. |
| 7 | “Закрыт” | В систему внесены все правки, проведены окончательные проверки, и всё работает как надо. В этом случае баг признаётся закрытым. |
Кстати, иногда у бага могут не совпадать уровень приоритетности и серьезности. Например, замечена опечатка на главной странице Google.com. Приоритет исправления такого бага будет высокий – потому что его заметит много людей и пострадает репутация компании. А сёрьезность бага – незначительная, потому что это всего лишь опечатка, не влияющая на работу сайта.
Поиск, описание и проверка исправлений в багах – занятие для самых внимательных и скрупулезных специалистов. Именно такие тестировщики работают в нашей команде. Хотите выпустить по-настоящему эффективный и удобный продукт? Напишите нам на почту hello@qualitica.ru. Найдём все дефекты и поможем быстро от них избавиться 😉
