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