В сфере разработки программного обеспечения часто обсуждают баги: откуда они берутся, как их избежать, как с ними справляться и т. д. Но что на самом деле представляет собой баг?
Можно встретить проекты, в которых содержится более ста багов. Каждый из них хорошо задокументирован и отслежен, но код всё равно работает. Однако существует и противоположная ситуация, когда баг приводит к остановке работы целого класса устройств, не позволяя им общаться с сервером. Как такое возможно, что в обоих этих случаях используется один и тот же термин “баг”?
Насколько эти случаи действительно похожи? Если сказать, что у задней двери находится рептилия, это может означать как игуану, загорающую на солнце, так и велоцираптора, пытающегося открыть дверь. Но является ли эта информация действительно полезной?
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.
Таксономически эти существа могут быть похожи, но это не даёт нам понимания, как правильно действовать в ответ. Инженерия программного обеспечения связана с действиями, направленными на создание продуктов. Определения, которые используются, должны способствовать достижению этой цели.
В таком контексте о рептилиях обычно не говорят. Биология предлагает более точную и детализированную классификацию. В связи с этим возникает идея: для правильного управления багами необходима более точная их классификация.
Ниже предлагается разделение багов на три категории с указанием подходов к их устранению.
1. Катастрофы (Catastrophe)
Катастрофы — это самые простые баги, о которых можно говорить и идентифицировать. Они определяются так: «Баг, который не позволяет выпустить следующую версию программного обеспечения». Если такой баг обнаруживается в рабочей версии, это обычно требует специального релиза для его исправления.
Но это по-прежнему широкая категория. То, попадет ли в нее какой-то конктерный баг, сильно зависит от того, над какой именно системой вы работаете.
Это может быть уязвимость в безопасности, нарушение работы ключевой функции, кнопки, которые наполовину выходят за пределы экрана на новом iPhone, или проблема с интерфейсом, которая доводит ваших клиентов до психоза.
Катастрофы требуют незамедлительного устранения. Когда на исправление этой проблемы требуется всего несколько часов, а релиз продукта без этого невозможен, нет смысла тянуть: нужно исправить проблему, пока она свежа в памяти.
В случае, когда время на исправление неизвестно, необходимо приступить к работе немедленно. Если ошибка требует исправления до релиза, но невозможно точно сказать, сколько времени это займёт, становится трудно планировать выпуск следующей версии. Без ясного понимания сроков устранения ошибки невозможно сделать точную оценку готовности программного обеспечения. В такой ситуации проект как будто парализован. Пока не устранена критическая ошибка, работа над новыми функциями невозможна — сначала нужно вернуть проект в рабочее состояние.
2. Трещины (Quibble)
Трещины можно определить как «небольшие несовершенства в программном обеспечении, с которыми можно выпустить продукт». Например, кнопка в веб-интерфейсе может быть слегка смещена на самом маленьком поддерживаемом экране. Или можно ввести отрицательное число в поле, где должна быть валидация значений (исходим из того, что это не несет особой опасности). Также, может быть, число отображается с двумя знаками после запятой, хотя второй знак всегда ноль. Или анимация срабатывает с задержкой в редких и необычных случаях.
Трещины вредят общему виду и восприятию вашего продукта. Если их слишком много, они могут даже помешать релизу вашего ПО. Пользователи не доверяют программам, которые «кажутся» сломанными. Однако такие баги могут помешать релизу только в совокупности.
Важно стараться минимизировать количество трещин. Если их легко исправить, стоит сделать это, когда вы будете работать в этой области кода по другим причинам. Если в вашей компании запрещено работать над исправлением без создания отдельной ветки, нарушайте это правило, пока вас не остановят. Вероятнее всего, этого не случится.
Если в вашей компании есть команда QA, то ваш список задач, вероятно, переполнен трещинами. QA-команды часто считают, что их работа — находить баги. Но их задача такая же, как и у всех в команде — продать продукт.
Тестировщики, находя трещины, не создают реальной проблемы. О них полезно знать, чтобы устранять по мере возможности. Проблема возникает, когда соотношение между полезной и бесполезной информацией ухудшается. Когда тестировщик вносит в систему отслеживания множество трещин и несколько критических багов, со временем обе категории проблем начинают игнорироваться. Трещины должны быть выделены отдельно от критических багов, иначе они могут сильно затормозить разработку.
3. Грибок (Fungus)
При переходе к третьей категории может возникнуть мысль, что это переосмысление технического долга (Technical debt). Да, между техническим долгом и грибком есть много общего. Однако цель здесь — создать новую таксономию багов, поэтому некоторая повторяемость неизбежна. Также термин “технический долг” не хочется использовать потому, что он слишком загружен смыслом и многосложен. Термины “Quibble” (трещина) и “Fungus” (грибок) должны быть короче “Catastrophe” (катастрофа).
Грибок — это любой дефект в коде, который со временем будет становиться всё хуже. Вероятно, вы слышали фразу: «Чем дольше мы ждём, тем труднее и дороже будет исправить». Возможно, вы даже сами так говорили. Важно отметить, что грибок никогда не может быть катастрофой. Грибок может быть или не быть трещиной. В результате мы получаем следующую схему:
Грибок не может быть катастрофой, так как катастрофы нужно устранять немедленно, не давая им развиваться. Трещины, конечно, могут стать грибком, потому что их проще исправить сейчас, чем потом. В некоторых случаях грибок может вообще не указывать на видимые дефекты в коде.
Если какой-то модуль кода трудно изменить, и вы ожидаете, что его придётся менять в будущих итерациях вашего программного обеспечения, — это грибок. Один из наихудших видов грибка — нарушение архитектуры.
Нарушения архитектуры возникают, когда можно реализовать функцию неправильно за десять минут, но правильно — за неделю. Если слишком часто выбирать короткий путь, можно ожидать появления множества странных случаев и пересечений, которые сделают определённые области вашего кода неработоспособными. Нарушения архитектуры — одна из причин, почему компании со временем увязают в проблемах. В общем, грибок должен иметь более высокий приоритет, чем трещины.
Если трещины не настолько многочисленны, чтобы препятствовать выпуску, то экономически выгоднее решать растущие проблемы, чем статичные. Как и трещинам, можно позволить небольшому количеству грибка остаться в вашем коде. Если это помогает соблюдать сроки, срыв которых скажется на продажах, это может быть оправдано в краткосрочной перспективе. Но грибок всегда рискован, даже если вы думаете, что ваше ПО скоро выйдет из эксплуатации. Этот мир полон кода, который люди считали отправленным на пенсию еще двадцать лет назад.
Заключение
В результате проведённой переклассификации термин «баг» был разделён на три более полезные категории. Вопрос, заданный в заголовке статьи, – “Что такое баг?” – это не то, о чём стоит говорить. Вот краткое описание новых категорий, которые заслуживают внимания:
- Катастрофы — это проблемы, которые мешают выпуску программного обеспечения. Их необходимо устранять незамедлительно.
- Грибок — это дефекты, которые со временем усугубляются. Грибок следует устранять как можно скорее, поскольку он представляет средне- и долгосрочный риск для кода.
- Трещины — это небольшие несовершенства, которые влияют на качество программного обеспечения. Их количество следует минимизировать и устранять по мере возможности. Если команда выделяет отдельный спринт или цикл разработки для работы с трещинами, это может указывать на слишком пассивное отношение к их устранению.
Перевод статьи «What is a “Bug” Anyways?».