Утечка дефектов: как бороться с техническими ошибками продуктива
Руководитель практики ALP Group по управлению финансами Юлия Орлова рассказывает, как минимизировать количество исправлений в готовой версии ИТ-продукта.
Любое программное обеспечение на крупных проектах по автоматизации проходит через многоитерационный процесс тестирования (нагрузочного, интеграционного, функционального, регрессионного и других), возвращения на доработку, повторного тестирования и новых доработок. Но несмотря на это, в любом выпускаемом ИТ-продукте впоследствии выявляются те или иные технические ошибки. За примером далеко ходить не нужно: посмотрите, как часто в магазине мобильных приложений прилетают обновления программ с пометкой «Версия Х.Y — исправления ошибок, мелкие улучшения и многое другое».
В QA-тестировании даже есть специальная метрика — утечка дефектов (defect leakage) — показатель, используемый для измерения процента ошибок, которые не были обнаружены на всех этапах разработки и тестирования и попали в продуктивную среду.
Общепринятого «стандарта» по количеству технических ошибок на просторах интернета я не нашла, но встречала на форумах такую цифру: 5% от общего числа всех пользовательских обращений (доработки, дефекты, консультации и прочее).
Первый и самый распространенный тип «дефектов» (около трети всех ошибок) — это недочеты, которые возможно выявить только в условиях реальной эксплуатации системы пользователями. Они возникают при определенном порядке выполнения действий или при определенном сочетании настроек, данных в продуктиве. Приведу бытовой пример: все мы знаем о забавных предупреждениях в инструкциях к тем или иным товарам (не сушить кошек в микроволновках, не гладить одежду на себе, не натягивать шапочку для душа на две головы одновременно и т. д.). Такого рода предупреждения появляются после судебных исков от покупателей, которые попытались использовать предмет не так, как было задумано его создателями.
С ИТ-продуктами мы видим примерно ту же историю. Некоторые специфические кейсы использования просто не могут заранее прийти в голову разработчикам и тестировщикам. Это, например, проблемы с задвоениями строк в документах, «затиранием» данных при копировании, активностью определенных кнопок в различных ситуациях, зависанием в работе системы и т. п. Ни пользовательское, ни сценарное тестирование не выявит такие ошибки в 100% объеме.
Поскольку предугадать такие кейсы невозможно, придется смириться с тем, что они будут с нами всегда.
Второй по частоте вид ошибок — это когда спустя миллион лет выясняется, что давно реализованный функционал работает не так, как теперь надо. В большинстве случаев им никто пару лет и не пользовался, и узнать, почему он когда-то давно был принят в релизе — просто нереально, и к тому же трудно доказуемо.
Как мы предвосхищаем эту проблему при работе над проектами:
- Добиваемся уверенности в том, что выполняемая доработка будет востребована пользователями после того, как окажется на продуктиве (работа больше для функционального архитектора).
- Добиваемся уверенности в том, что доработка будет протестирована и принята в релизе тем, кто понимает, как данный функционал должен использоваться.
Еще один довольно распространенный тип кейсов — когда итоговая поставка в продуктиве не соответствует методологии (требованиям) на входе. Почему так происходит? Даже несмотря на то, что частное техническое задание согласуется, порой выявить несостыковку невозможно из-за сложных условий и нюансов реализации, а также многоэтапного процесса согласований.
Количество подобных кейсов можно свести к нулю, если:
- по всем сложным задачам описывать в частном техническом задании тестовые примеры и результаты, которые должны быть получены в том или ином случае;
- рисовать картинки и схемы, демонстрирующие описанные примеры;
- проводить предварительные демонстрации решения до выпуска релиза.
Идем дальше. Следующий вид технических багов на продуктиве — ошибки интеграции данных между системами после выпуска релизов. Это кейсы из разряда трудно выявляемых при тестировании — в основном они зависят от конкретных данных, которые выгружаются или загружаются в систему, от порядка действий, выполняемых для регистрации объектов к выгрузке, и т. п. Каждый раз заряжать несколько команд на межинтеграционное комплексное тестирование — такое себе решение.
Какая здесь может быть рекомендация от нас? Сосредоточиться на описании кейсов тестирования и выявлять проблемы до выпуска продуктивного релиза, а не после.
Среди других классических ошибок на продуктиве можно назвать:
- ошибки в ролевой модели;
- падения с некорректными загружаемыми данными или некорректными историческими данными;
- проблемы с неполным охватом тестирования (когда протестированы не все возможные кейсы) или с частичным охватом бизнес-процесса при тестировании.
Всех этих проблем также можно избежать — тут больше фронт работ для руководителя проекта при согласовании технического задания и методики испытаний, а также при тестировании релизов со стороны заказчика.
Подводя итоги, можно сказать, что порядка ⅔ технических ошибок на продуктиве можно избежать, если в компании-интеграторе грамотно выстроена работа еще на этапе согласования ТЗ. Оставшаяся треть ошибок — «неизбежное зло» ИТ-разработки :)