Какой же путь проходит баг и какую роль в его жизненном цикле играет тестировщик? Давайте разбираться.

Ошибка, дефект, но чаще всего баг. Именно так называется то, что находят тестировщики в процессе работы.

Определение бага

Bug в переводе означает “жук, насекомое”. Первая ошибка, которая была задокументирована, возникла как раз из-за жука. В середине 40-х годов 20 века ученых Гарвардского университета вызвали для того, чтобы определить причину сбоя в работе вычислительной машины Mark II. Покопавшись в этой громадной куче приборов, соединенных проводами, они обнаружили бабочку, застрявшую между контактами электромеханического реле. Стало ясно, что именно она и явилась причиной сбоя. Одна из сотрудниц университета, Грейс Хоппер, так и сформулировала результат исследований: «неполадку вызвал баг». Извлеченное насекомое было вклеено скотчем в технический дневник, с соответствующей сопроводительной надписью. Ее, как говорят, до сих пор можно увидеть в этом журнале, хранящемся в университетском научном музее.

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

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

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

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

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

Давайте вкратце разберем каждый этап жизненного цикла

1. Новый (New) — Тестировщик находит баг, локализует и вносит его в специальную систему, где хранятся баг-репорты. С этого момента баг начинает официально существовать.
   Далее его статус меняется на Отказ (Rejected) или на Назначен (Assigned).
2. Отказ (Rejected) — пишется комментарий программиста или менеджера о причине reject-a(отклонения). Это может быть некачественное описание дефекта, такой дефект уже существует (дубликат), невозможность воспроизвести дефект. Также это может произойти потому что для заказчика какие-то ошибки перестали быть актуальными. После этого, тестировщик или закрывает дефект (Closed), или дополняет комментарии данного дефекта и переводит дефект заново в состояние Назначен(Assigned).
3. Назначен (Assigned)— дефект просмотрен и открыт (то есть признан для исправления).
4. Решен (Fixed) — дефект исправили и он в этом состоянии требует перепроверки тестировщиком.
5. После проверки ошибки тестировщиком, дефект переводится в состояние Переоткрыт (Re-opened) (если дефект не исправлен или исправлен не полностью) либо в Закрыт (Closed), если ошибка исправлена.

Данную схему можно изобразить в текстовом виде. Вот несколько вариантов прохождения багов (можно просто нарисовать на листочке на собеседовании):
1. Новый (new) —> Отклонен (rejected) —> Закрыт (closed)
2. Новый (new) —> Назначен (аssigned) —> Решен (fixed) —> Закрыт (closed)
3. Новый (new) —> Назначен (аssigned) —> Решен (fixed) —> Закрыт (closed) —> Переоткрыт (re-opend)

Жизненный цикл бага с точки зрения команды

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

Сначала тестировщик находит баг. Далее заносит его в систему учета ошибок. После этого программист начинает изучать отчет о дефекте. Именно на этом этапе он решает баг это или нет.

Давайте посмотрим сначала сценарий, в котором разработчик принял баг. Перед ним сразу встает задача пофиксить его, то есть исправить и залить (отдать заново на проверку). Как только разработчик все сделал, баг снова отправляется к тестировщику, который производит тестирование исправлений, а также проверяет смежные участки (регрессионное тестирование).

Если баг больше не воспроизводится, то тестировщик закрывает баг.
Если баг снова воспроизводится, то мы возвращаем его программисту. И снова проходим все шаги, начиная с 3-го шага (рассмотрения проблемы программистом).

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

***

Именно так выглядят основные этапы жизненного цикла бага. Иногда могут добавляться дополнительные этапы, это вызвано особенностями процессов тестирования внутри фирмы. Неизменным всегда останется то, что баг создается и закрывается (прекращает существование) по различным причинам.