Откуда берутся баги
Чем сложнее разрабатываемое программное обеспечение, тем больше вероятность, что в нем будут ошибки и дефекты, или «баги», как их называют на своем жаргоне программисты и тестировщики. На всем этапе разработки программы от документирования до вывода в эксплуатацию с ним работает большое число людей. Плохая коммуникация между участниками проекта, сложная архитектура программы, отсутствие подробных требований или их частая смена – все это неизбежно приводит к появлению новых ошибок.
Поэтому до того как выпустить ПО на рынок, оно проходит контроль качества разработки. На этой стадии команда тестирования проверяет разрабатываемую программу на соответствие требованиям, фиксирует ситуации неправильного поведения программы (регистрация багов) и контролирует качество их устранения. Также параллельно тестировщики предлагают варианты оптимизации ПО и повышения эффективности его работы.
История болезни
Весь процесс от выявления бага до его «закрытия» отражается в багтрекинговой системе – своеобразной истории болезни бага. В ней ведется вся статистика, учет и контроль найденных в приложении багов. Также в этой системе хранится детальная история багов всего проекта с возможностью отслеживания процесса устранения этих ошибок.
Любой участник проекта, будь то разработчик, менеджер или тестировщик, имеет доступ к бактрекинговой системе и может «регистрировать» дефекты. Список допускаемых к системе людей зависит от политики внутри проекта, но обычно вносить ошибки - непосредственная обязанность тестировщика.
Как только баг замечен, в багтрекинговой системе указывают обязательные атрибуты дефекта (анамнез выявленного заболевания): короткое описание бага, степень серьезности, шаги воспроизведения, результат воспроизведения, ожидаемый результат и др.
Жизненный цикл дефекта начинается именно с момента его регистрации в багтрекинговой системе, после чего участники проекта могут приступать к работе с ним.
Жизнь бага
А теперь давайте рассмотрим наиболее распространенный порядок активностей, которые происходят с багом за время его «жизни»:
1. Определение важности: чем выше приоритет бага, тем быстрее он должен быть исправлен. Выставлением в баге атрибута важности занимается менеджер.
2. Назначение ответственного за исправление дефекта – это также обязанность менеджера проекта. На разных этапах ответственными за исправление могут назначаться разные участники проекта.
3. Исправление бага, которым занимается ответственный разработчик.
4. Проверка исправления – на этом этапе назначенный тестировщик проверяет работу предыдущего ответственного разработчика, исправлявшего баг. Если дефект исправлен корректно, тестировщик «закрывает» баг и работы с этим дефектом приостанавливаются («история болезни» отправляется в архив). Если баг не исправлен, он «переоткрывается» и передается обратно разработчику.
5. Отправка на повторное исправление происходит в тех случаях, когда разработчик не произвел полного и корректного исправления, либо если дефект был исправлен, но через некоторое время снова начал воспроизводится.
С жизнедеятельностью бага, вроде бы, все понятно: после выявления и регистрации в системе менеджер устанавливает его важность и ответственного за его исправление человека. После исправления баг либо закрывается, либо отправляется на повторное исправление. И так до бесконечности, пока дефект не будет исправлен.
Именем резолюции!
Любой этап работы с дефектом обозначается атрибутом «Статус». После того, как работу с багом закончил один из участников проекта, он меняет статус дефекта и «перенаправляет» дефект на того, кто должен продолжить работу. При выставлении некоторых статусов необходимо указывать значение атрибута «Резолюция» – результат работы и принятое решение: исправлено, не будет исправлено, не хватает информации для работы и др. Набор применяемых резолюций зависит от используемой багтрекинговой системы. Kроме того, системы багтрекинга позволяют настраивать список доступных резолюций для конкретного проекта. Самые распространенные резолюции:
«Исправлен» – резолюция означает, что баг устранен и тестировщик должен проверить, после правок разработчика, что ошибка устранена и баг не воспроизводится.
«Не будет исправлен» – дефект перестал воспроизводиться, или принято решение, что исправление дефекта нецелесообразно.
«Дубликат» – в системе уже зарегистрирован аналогичный баг, поэтому этот дефект избыточен и работы по его исправлению будут проводиться на основании ранее заведенного бага.
«Требуется переформулировать» – разработчик не может исправить дефект по описанию: баг описан не достаточно полно или неясно и требует дополнительного описания.
«Не воспроизводится» – разработчик выполнил все шаги воспроизведения, описанные в баге, но ошибка не воспроизвелась. Поэтому автор бага должен повторно воспроизвести ошибку и добавить в описание бага подробности его воспроизведения.
«Исправлен косвенно» – исправление другого бага стало решением и для данного бага. Тогда тестировщик должен убедиться, что дефект больше не воспроизводится.
«Не дефект» – заведенный баг не признан ошибкой (например, за ошибку принято внедренное нововведение, о котором автор бага не знает). В таком случае автор бага должен разобраться действительно ли описанное в баге поведение системы является ошибкой, либо же это правильное поведение системы, и баг заведен ошибочно.
Как видно, в течение жизни дефект может поменять кучу статусов, резолюций, попечителей, и вариант, при котором жизненный цикл состоит лишь из двух стадий – «Заведен» и «Исправлен» - считается идеальным и встречается не так часто. Обычно тестировщикам приходится «поковыряться» в дефекте, перемещаясь от одного статуса к другому. На схеме ниже показан унифицированный жизненный цикл бага со всевозможными поворотами:
В этом случае «история болезни» отправляется в архив, и «больного» выписывают.
