РБК Компании
Главная ALP Group 23 апреля 2024

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

Юлия Орлова размышляет, как минимизировать количество исправлений в готовой версии разрабатываемого продукта
Как бороться с «утечкой дефектов» в IT-продукте
Юлия Орлова
Юлия Орлова
Руководитель практики ALP Group по управлению финансами

С 2010 года работает в ALP Group, с 2018 года является руководителем практики по управленческому и финансовому учету (FRP).

Подробнее про эксперта

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Интересное:

Новости отрасли:

Все новости:

Достижения

I место в рейтинге фирмы «1C»Крупнейшее внедрение «1С» в ФГУП «Почта России», автоматизировано 47 612 рабочих мест.
Внедрение «1С: Консолидация 8»Одно из самых масштабных внедрений «1С: Консолидация 8» в ПАО «Газпромнефть», автоматизация >5к мест

Профиль

Дата регистрации14.10.2010
Уставной капитал100 000,00 ₽
Юридический адрес Г.Москва МУНИЦИПАЛЬНЫЙ ОКРУГ ПРЕСНЕНСКИЙ РАЙОН УЛ 2-Я ЗВЕНИГОРОДСКАЯ 13 СТРОЕНИЕ 42 ЭТАЖ 9, ПОМЕЩ./КОМ, I /18,
ОГРН 1107746840420
ИНН / КПП 7703729939 770301001

Контакты

Адрес 123022, Россия, г. Москва, ул. 2-я Звенигородская, д. 13, корп. 41, 7 этаж
Телефон +78005555151

Социальные сети