Технологии Agile, Scrum и CI/CD становятся общепринятой нормой, и нам уже кажется, что новые релизы всегда можно выпускать постоянно, практически непрерывно. Технически, сейчас действительно есть реальная возможность выкатывать обновления каждый день, а некоторые разработчики готовы релизиться каждый час — для web- и мобильных приложений это совершенно нормально. При такой частоте возникает вопрос: на сколько хорошо должна быть отлажена система автоматизированного тестирования? Цена ошибки в таком релизном цикле невысока, а компания получает возможность переложить финальное тестирование на плечи своих клиентов. Если у кого-то что-то пошло не так, можно моментально выпустить исправление. Но возможен ли такой подход в разработке корпоративной BI-системы? Об этом и поговорим сегодня.
Быстрый выпуск релизов, к которому сегодня стремятся многие, конечно, очень удобен. Как только у вас готова новая фича, как только завершили обновление, можно сразу же выкатывать новинку, и пусть люди пользуются! Он позволяет быстрее реагировать на инциденты, не делить релизы на “платформенные” и “функциональные”. Но при этом при таком подходе протестировать все четко и вручную практически не остается возможностей. При непрерывном конвейере все большую роль играют автотесты, а финальный вердикт о “годности” продукта удается получить только после его изучения конечным пользователем.
В сфере ПО для бизнеса, от работоспособности которого зависят критически важные процессы, такой фокус уже не проходит. Мы должны сразу гарантировать стабильность релиза настолько, насколько это возможно. Да и короткие интервалы между релизами оказываются в принципе невозможны.
Например, мы в Visiology работаем по схеме B2B2B. То есть все обновления наших продуктов приходят через партнеров. Присылать коллегам новенькие пакеты, конечно, можно каждый день. Чисто технически, мы можем делиться обновлениями хоть каждый час, но никто не будет их устанавливать, а тестирование станет просто огромной проблемой.
Чтобы задеплоить очередной релиз Visiology, нам нужно привлечь партнера, провести подготовку, запустить процесс обновления, после этого — проверить, все ли у финальных пользователей в порядке. То есть процесс получается затратный — как с точки зрения привлечения специалистов, так и стоимости. С учетом всего этого заказчики тоже не готовы обновляться слишком часто (какое там “раз в час” - тут и раз в неделю мало кто хочет). Мы нашли оптимальный баланс между трудозатратам и скоростью донесения ценности: раз в 2,5 месяца. Большинство заказчиков с этим согласны и регулярно обновляются.
Но даже такой релизный цикл могут “потянуть” не все. Часть наших пользователей работает с BI в закрытом контуре, без подключения к интернету, и для них установка новой версии является отдельным квестом — нужно принести дистрибутив на проверенном накопителе, запустить локальную установку, проверить все до мелочей — ведь онлайн-мониторинга нет и в помине.
А те компании, которые используют только одобренные ФСТЭК решения, обновляются только с выходом очередного релиза с сертификатом. А такие релизы выходят раз в год. И тут совершенно недопустимо наличие каких-либо серьезных недочетов.
Стоит сказать, что все изменения в нашей системе инициируют ее пользователи. У нас достаточно много инсталляций в разных сферах, и мы никогда не затачиваем функционал под определенный проект. Поэтому протестировать решение на данных и инфраструктуре целевого заказчика часто нереально. Чувствуете, переложить тестирование на клиента не получается? А вот и нет, получается! Только немного иным способом.
Дело в том, что развитие системы происходит в соответствии с запросами различных функциональных пользователей со стороны заказчиков. И в продуктив идут именно те запросы, которые повторяются чаще всего. А вместе с этими запросами мы получаем как раз те сценарии, на которых мы будем тестировать новые релизы.
Три круга приемочного тестирования
Процесс тестирования продукта должно быть многогранным. На мой взгляд, подход к тестированию хорошо отражает фундаментальная V-диаграмма из системно-инженерного подхода. Ее суть заключается в том, что на каждом этапе надо проверять, в том ли направлении мы движемся.
Идея заключается в том, что написание кода для очередной фичи — это лишь один из этапов жизненного цикла (собственно, он находится в нижней части V-диаграммы). Ему предшествует большой объем работ по системному проектированию и дизайну, и на каждом этапе присутствует независимое тестирование, чтобы как можно раньше понять “а то ли мы сделали(-ем), что на самом деле нужно?”
Чтобы воплотить эту концепцию на практике, мы несколько раз проводим приемочное тестирование. Оно отличается от обычных тестов, которые в основном направлены на вылавливание багов. Цель приемочного тестирования — проверить, насколько новый функционал (и его конкретная реализация) закрывает реальные потребности наших клиентов — особенно функциональных заказчиков, от которых и исходил запрос на новые возможности.
Приемочное тестирование — раз
В нашем жизненном цикле продукта сначала происходит бизнес-анализ, а потом — проектирование и системный анализ. И тут приходит время для первой стадии приемочного тестирования. Да, оно проводится еще до начала разработки. Самой прикладной системы еще нет, но мы проверяем правильность проведения системного анализа. Насколько то, что мы собираемся разрабатывать, действительно удовлетворяет запросам пользователей?
Эта практика оправдала себя за последние годы, потому что исправления на этом этапе имеют минимальную стоимость. Ведь чем позже мы поймем, что какие-то изначальные пожелания не учтены, тем дороже будет вносить изменения.
В нашем бэклоге каждая фича сопровождается списком пользователей и четким описанием, зачем она каждому из них, какие цели они хотят достигнуть. На базе этих данных аналитики могут оценить еще на стадии выбора архитектуры, диаграмм и скетчей интерфейсов, удовлетворяем ли мы запросы клиентов. И если нет — отправить на доработку саму концепцию фичи. Чаще всего на этом этапе в разработке принимают участие те самые заказчики, которые его просили — и тут мы уже начинаем тестировать новые фичи на заказчиках.
Приемочное тестирование — два
Когда мы уверены, что спроектировали “то, что нужно”, начинается этап реализации. По готовности функций происходит системное тестирование, чтобы оценить работоспособность всех элементов и новшеств. А уже после него — приемочное тестирование на реальных данных в реальном окружении. Уже готово и работает ПО, а наш штатный аналитик-тестировщик проверяет, как достигаются цели пользователей, для которых фича разрабатывалась.
Снова в ход идут собранные в бэклог данные, и если что-то не работает…или работает не так, как хотелось бы, фича уходит на доработку.
Приемочное тестирование — три
Но для масштабных изменений этого бывает недостаточно. Поэтому, когда нам кажется, что мы сделали все верно и новый функционал соответствует ожиданиям, мы уже массово приглашаем к приемочному тестированию тех самых пользователей, которые просили новый функционал. Тут инициативу берут клиенты, которые готовы устанавливать бета-версии релизов, готовы работать с ними в тестовой среде, а в отдельных случаях — даже в продуктиве (такое бывает, когда кому-то фича прямо ну очень нужна. Например, у нас так было с функциональностью регламентированной отчетности на основе шаблонов Excel).
В результате на третьем этапе мы действительно проводим финальное тестирование “на заказчике”. Но с его полного согласия и для пользы дела. Если заказчик дает “добро”, то фича уходит в следующий релиз. Если возникают дополнительные пожелания, критика или серьезные замечания, то цикл повторяется с самого начала. И когда мы убедились в том, что фича действительно выполняет те функции, ради которых ее разработка затевалась изначально, она входит в официальный релиз и становится доступна большому количеству клиентов.
Так что парадигма остается неизменной: тестирование “на клиенте” работает и в B2B-разработке. Просто его реализация отличается от B2C-разработки с частыми релизами.