Если задуматься, для каких российских компаний тестирование может быть особенно хардкорной задачей, в голову сразу приходят Сбербанк-Технологии. Во-первых, там гигантские масштабы, во-вторых, большая ответственность (финансовые операции — это вам не фотошеринг с геолокацией), в-третьих, взят курс на максимально быстрый релизный цикл: то есть тестировать нужно очень много, очень качественно и при этом очень быстро.
Каково живётся с такими почти взаимоисключающими установками? По следам конференции Гейзенбаг, где компания была спонсором, мы задали несколько вопросов Антону Романову из её Департамента качества — заместителю начальника отдела тестирования корпоративно-кредитных систем.
— До Сбербанк-Технологий вы работали в компании «Аплана», где тоже занимались тестированием систем Сбербанка, но со стороны внешнего подрядчика. А как вообще в Сбертехе делят задачи по тестированию между самой компанией и подрядчиками?
— Исторически подрядчики сначала привлекались в основном для регрессионного тестирования. И я работал в «Аплане» как раз тогда, когда на подряд передавалось преимущественно регрессионное тестирование, а Сбертех контролировал. А сейчас по мере увеличения объема работ, подрядчики привлекаются в том числе и для тестирования новых проектов.
— Всем очевидно, что Сбербанк-Технологии — большая компания, а можете ли с помощью каких-либо чисел дать представление, насколько именно большая в отношении тестирования?
— В Департаменте качества работает около 1 500 человек, это 38 отделов.Получается около пяти управлений, которые делятся по функциональным компетенциям: Управление нагрузочного тестирования, Управление тестирования автоматизированных банковских систем, Управление тестирования фронтальных систем, Управление администрирования. И в каждом управлении где-то по пять отделов.
— Когда так много отделов, становится интересно: насколько это всё унифицировано? У вас в тестировании внедрены строгие единые стандарты, которым подчиняется каждый, или у отделов есть высокая степень автономии?
— Я бы сказал, у нас золотая середина. Например, отдел организации тестирования задает некие направляющие практики. Для них определены критерии, которые выполняются или не выполняются при определенных условиях (тестирование на ранних этапах, согласование своих тестов с аналитиками и т.д.). То есть команды работают по общему набору правил, но в зависимости от особенностей системы и процесса разработки команда самостоятельно определяет, какие практики применимы и как они будут реализованы.
Естественно, процессы прозрачны и открыты: с активной обратной связью, согласованием и пониманием рабочих процессов.
— А может ли команда использовать какие-то новаторские практики, ещё не ставшие мейнстримом, или в вашем случае всегда требуются проверенные временем?
— Конечно, нам нужна надёжность, но это не означает, что нельзя работать с чем-то новым. Например, mind maps (ментальные карты) до недавнего времени считались новаторской практикой. Мы их используем, но в качестве дополнительного инструмента. А использование только mind maps взамен любой другой тестовой документации, конечно, не допускается. Таким образом, используя что-то новое, мы просчитываем и нивелируем риски, часто проводим подобные тестирования в пилотном режиме. И только если мы видим эффективность и результат, такие решения практикуются и тиражируются.
— Правильно ли понимаем со стороны, что высокая ответственность финансовых операций сказывается на подходе к тестированию?
— Там, где дело касается денег, есть огромная ответственность — и безусловно, это сказывается на наших подходах к тестированию. Процесс достаточно строгий, с несколькими этапами согласования — передача от разработки на тестирование, от системного тестирования на интеграционное тестирование, от интеграционного тестирования на приемку. То есть всё несколько раз перепроверяется, есть строгие критерии передачи такого дистрибутива, обязательно контролируется выполнение регрессионного тестирования и качество тестирования новой функциональности.
— А ещё, вероятно, в вашем случае нагрузочное тестирование особенно важно?
— Да, это так. Для примера: в Сбербанке порядка 150 различных систем, взаимодействующих между собой. На наш отдел приходится одна большая система, в которую за один операционный день поступает примерно по 500 платежных документов в секунду. Соответственно, объем на один территориальный банк составляет порядка четырех миллионов документов в день. Это и платежи клиентам, и налоговые и коммунальные платежи — масса всего.
Таким образом, нагрузочное тестирование несёт очень важную роль, потому что для Сбербанка критично время обработки этих документов — они не должны скапливаться в очередях и тормозить банковские операции. Мы уделяем большое внимание тому, как система ведет себя после наката очередных обновлений — очень важно, чтобы уровень сервиса не проседал. Поэтому в нагрузочном тестировании мы стараемся создавать среду, которая максимально соответствует промышленной.
— При этом у вас гигантские объёмы уже написанного кода, что должно усложнять регрессионное тестирование, и в то же время стоит цель максимально ускорить релизы. Что помогает справиться с таким вызовом?
— Помогают старые добрые практики — тестирование, основанное на рисках.
Система, которую мы тестируем, перешла к нам по наследству: её изначально разрабатывала сторонняя компания. Документация осталась где-то на уровне семилетней давности, а новые изменения были разрозненно задокументированы в разных местах. То есть первая задача — понять, что, где и как работает.
А следующий момент — объёмы. В этой системе порядка 15 000 операций, в нее стекаются все платежи — и бухгалтерская отчётность, и проводки, и вообще всё. У наших релизов сжатые сроки (порядка двух недель на всё), поэтому важно определить, что проверять в первую и вторую очередь, и в каком объеме. Определяя приоритеты, мы привлекаем коллеги из разработки, сопровождения и Сбербанка — ведем с заинтересованными лицами всесторонний диалог.
Очень важно автоматизировать процессы и таким образом сэкономить время. Но всё равно остаются проверки, которые можно сделать только вручную, и здесь мы применяем Lead-Time метрику (имеется в виду время от начала до завершения регресса) — время, которое требуется на выполнение регрессионного тестирования. Мы используем данные о времени выполнения тестов, которые хранятся у нас в инструменте, и на основе этого оцениваем, сколько времени нам потребуется на выполнение регресса, сравниваем это же время с расчётом через дату, просто дата окончания — дата завершения (два метода расчета — через фактические даты завершения и начала и через объем тестов и среднее время выполнения; пока что “факт” превышает расчетное значение). Пока у нас есть различия и мы думаем, как сократить время на выполнение отдельных тестов.
— Про компанию масштаба Сбертеха кажется, что в такой должно быть много разработанных внутри инструментов — вы в вашей работе с такими сталкиваетесь?
— Смотря о чём именно говорить: собственной JIRA у нас нет, но разрабатывается много утилит под отдельные нужды тестирования. Например, создание специальных сообщений в определённом формате, генераторы тестовых данных, очень распространены SQL-скрипты.
— Ранее Сбертех сообщал, что в Департаменте качества внедряют DevOps — а что это означает на практике для вашего отдела?
— С приходом девопса появляются такие практики, как Continuous Integration и Continuous Deployment. В отделе, где я работаю, их пока нет, потому что наша система относится к классу legacy, которая будет заменяться новой платформой (ее разрабатывают уже как веб-приложение). Но коллеги из других отделов уже работают в DevOps, что реально экономит время и ускоряет весь процесс. Потому что все собирается автоматически, накатывается и запускается ночью, а тебе остается только утром посмотреть результаты.
— Про Сбертех известно, что он активно нанимает разработчиков — а в тестировании тоже постоянно привлекаете новых людей?
— Сейчас активно разрабатывается новая ИТ платформа Сбербанка, которая будет совмещать в себе большое количество систем, существующие сейчас по отдельности. Это будет единая платформа, состоящая из большого количества модулей, которые будут выполнять отдельные функции. Но параллельно мы обрабатываем заявки по существующим системам. Поэтому конечно нам нужны люди для выполнения этой реально масштабной задачи.
Вы сертифицированный тестировщик вплоть до уровня ISTQB Full Advanced — а насколько сказываются в Сбертехе и полученные знания, и сам факт получения сертификата?
— В моей работе эти знания очень полезны. Часто бывают какие-то задачи из серии «проектируется какой-то бизнес-процесс, нужно оценить каким-то образом количество тестов, чтобы примерно спланировать работы, примерно понимать, какой будет объем регресса». Вот здесь нужны методы тест-дизайна, которые рассматриваются в ISTQB. Они помогают, имея даже не очень подробную документацию и основываясь на предположениях о существующих рисках и о критериях качества, определить возможный объем — может быть, не в терминах тестов, но в терминах проверок.
Также стратегия, основанная на рисках, очень применима к нашей регрессионной модели. Как оценить риски, как их приоритезировать, кого к этому привлечь — это всё очень полезно и не раз помогало мне в работе. Ну и в целом, как мне кажется, получаемые при подготовке к сертификации знания определяют дальнейший подход к работе. В голове постепенно укладывается установка, что нельзя протестировать всё: нужно исходить из рисков, расставлять приоритеты и обеспечивать максимальное качество при имеющихся ресурсах. С таким подходом к решению задач получается совершенно другой результат.
