Как бороться с «утечкой дефектов» в IT-продукте

Любое программное обеспечение на крупных проектах по автоматизации проходит через многоитерационный процесс тестирования (нагрузочного, интеграционного, функционального, регрессионного и других), возвращения на доработку, повторного тестирования и новых доработок. Но несмотря на это, в любом выпускаемом ИТ-продукте впоследствии выявляются те или иные технические ошибки. За примером далеко ходить не нужно: посмотрите, как часто в магазине мобильных приложений появляются обновления программ с пометкой «Версия Х.Y — исправления ошибок, мелкие улучшения и многое другое».

В QA-тестировании даже есть специальная метрика — утечка дефектов (defect leakage) — показатель, используемый для измерения процента ошибок, которые не были обнаружены на всех этапах разработки и тестирования и попали в продуктив (реальную, продуктивную, а не тестовую среду).

Общепринятого «стандарта» по количеству технических ошибок не существует, но на форумах разработчиков встречается такая цифра: 5% от общего числа всех пользовательских обращений (доработки, дефекты, консультации и прочее).

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

С ИТ-продуктами мы видим примерно ту же историю. Некоторые специфические кейсы использования просто не могут заранее прийти в голову разработчикам и тестировщикам. Это, например, проблемы с задвоением строк в документах, «затиранием» данных при копировании, активностью определенных кнопок в различных ситуациях, зависанием в работе системы и т. п. Ни пользовательское, ни сценарное тестирование не выявит такие ошибки в 100% объеме.

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

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

Как мы предвосхищаем эту проблему при работе над проектами:

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

Еще один довольно распространенный тип кейсов — когда итоговая поставка в продуктиве не соответствует методологии (требованиям) на входе. Почему так происходит? Даже несмотря на то, что частное техническое задание согласуется, порой выявить несостыковку невозможно из-за сложных условий и нюансов реализации, а также многоэтапного процесса согласований.

Количество подобных кейсов можно свести к нулю, если:

• по всем сложным задачам описывать в частном техническом задании тестовые примеры и результаты, которые должны быть получены в том или ином случае;
• рисовать картинки и схемы, демонстрирующие описанные примеры;
• проводить предварительные демонстрации решения до выпуска релиза.Следующий вид технических багов на продуктиве — ошибки интеграции данных между системами после выпуска релизов. Это кейсы из разряда трудно выявляемых при тестировании — в основном они зависят от конкретных данных, которые выгружаются или загружаются в систему, от порядка действий, выполняемых для регистрации объектов к выгрузке, и т. п. Каждый раз выделять ресурсы нескольких команд на межинтеграционное комплексное тестирование — не самое оптимальное решение.

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

Среди других классических ошибок на продуктиве можно назвать:

• ошибки в ролевой модели;
• падения с некорректными загружаемыми данными или некорректными историческими данными;
• проблемы с неполным охватом тестирования (когда протестированы не все возможные кейсы) или с частичным охватом бизнес-процесса при тестировании.

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

Подводя итоги, можно сказать, что порядка двух третей технических ошибок на продуктиве можно избежать, если в компании-интеграторе грамотно выстроена работа еще на этапе согласования технического задания. Оставшаяся треть ошибок — «неизбежное зло» ИТ-разработки.