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