Блог A1QA

О тестировании и качестве ПО

«История болезни» бага: откуда берутся ошибки в ПО и как их «лечат»?

Сколь серьезная компания не выпускала бы новое мобильное приложение, каким бы продуманным оно ни было, и какие бы профессионалы над ним ни работали – пропущенные тестировщиками ошибки могут испортить самый грандиозный IT проект. Как заводятся жуки (с английского слово «bug» переводится как «жук») в программном обеспечении, почему одни из них быстро погибают, а других приходится долго вылавливать, постараемся объяснить в этой статье Александра Панченко, опубликованной в казахстанском журнале Computerworld Kazakhstan.

Откуда берутся баги

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

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

История болезни

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

Любой участник проекта, будь то разработчик, менеджер или тестировщик, имеет доступ к бактрекинговой системе и может «регистрировать» дефекты. Список допускаемых к системе людей зависит от политики внутри проекта, но обычно вносить ошибки — непосредственная обязанность тестировщика.

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

Жизненный цикл дефекта начинается именно с момента его регистрации в багтрекинговой системе, после чего участники проекта могут приступать к работе с ним.

Жизнь бага

А теперь давайте рассмотрим наиболее распространенный порядок активностей, которые происходят с багом за время его «жизни»:

  1. Определение важности: чем выше приоритет бага, тем быстрее он должен быть исправлен. Выставлением в баге атрибута важности занимается менеджер.
  2. Назначение ответственного за исправление дефекта – это также обязанность менеджера проекта. На разных этапах ответственными за исправление могут назначаться разные участники проекта.
  3. Исправление бага, которым занимается ответственный разработчик.
  4. Проверка исправления – на этом этапе назначенный тестировщик проверяет работу предыдущего ответственного разработчика, исправлявшего баг. Если дефект исправлен корректно, тестировщик «закрывает» баг и работы с этим дефектом приостанавливаются («история болезни» отправляется в архив). Если баг не исправлен, он «переоткрывается» и передается обратно разработчику.
  5. Отправка на повторное исправление происходит в тех случаях, когда разработчик не произвел полного и корректного исправления, либо если дефект был исправлен, но через некоторое время снова начал воспроизводится.

С жизнедеятельностью бага, вроде бы, все понятно: после выявления и регистрации в системе менеджер устанавливает его важность и ответственного за его исправление человека. После исправления баг либо закрывается, либо отправляется на повторное исправление. И так до бесконечности, пока дефект не будет исправлен.

Читать далее

Поделиться статьей: