Это свободный перевод отличной статьи об отношении к ошибкам How to Actually Reduce Software Defects

Любой консультант в IT отрасли постоянно слышит вопрос: как можно уменьшить количество ошибок? Такое уменьшение является предметом профессиональной гордости для разработчиков и одной из важнейших метрик для менеджеров. Наше программы несут в себе тысячи ошибок, и мы бы очень хотели, чтобы это число приблизилось хотя бы к сотням. Такое отношение к багам схоже с тем, как президент США пытается довести уровень безработицы до 2%. Проблема в том, что такое отношение к багам, тоже является частью проблемы.

Правильное отношение к ошибкам

Президент США поставил целью уменьшить безработицу, но не убрать ее совсем. Почему? Потому что для страны не с плановой экономикой невозможно убрать безработицу вообще: люди увольняются и им нужно время, чтобы найти новую работу. Безработица неизбежна.

Менеджеры в компаниях относятся к ошибкам в таком же ключе: мы не можем убрать ошибки вообще, но мы можем уменьшить их количество. И именно такое отношение является важной частью проблемы.

Когда я рассказываю это, ко мне всегда относятся со скептицизмом. Но затем я объясняю клиентам, что они должны стараться сделать так, чтобы ошибок не было вообще. Другими словами нужно ставить цель, не уменьшить количество ошибок на 20% или даже 50%, а исключить ошибки вообще.

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

Когда команда начинает принимать это, такое отношение становится краеугольным камнем для уменьшения количества ошибок.

Что не поможет

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

Во-первых, очень важно понимать, что НЕ является причиной ошибок, то что "разработчики не достаточно стараются или даже мало работают". Другими словами, разработчики обычно не сидят за столом думая: "Я бы мог исправить свой все ошибки в этом коде, но мне сейчас лениво, да и вообще, мне хочется домой". Именно поэтому увещевания разработчиков работать больше или внимательнее не работает.

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

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

Понимание поверхностных решений

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

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

Ещё одна концепция это “bug bash”. Она заключается в том, что вначале команда реализует все фичи, а затем берет перерыв для того, чтобы исправить все ошибки, которе проявились. Хотя такой подход помогает в краткосрочной перспективе, в долгосрочной он ничего не даёт.

И наконец стандарты кодирования и бэклог ошибок. К сожалению менеджеров подход в виде "вот тебе список со всеми ошибками, которые кто-либо когда то сделал, и теперь больше никогда и не совершай", тоже не работает

Смена игры

Так что же нужно сделать чтобы фундаментально изменить подход к ошибкам? Ответы на этот вопрос очень философские.

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

Неотъемлимой частью является обратная связь при регрессионном тестировании. Заметьте, я не говорю про покрытие кода тестами. Ваш код должен быть покрыт дымовыми и другими типами тестов, для того чтобы разработчик мог получить обратную связь от них, а не от пользователей.

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

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