или «Как догнать рынок, прыгая по граблям, и построить компетенцию тестирования практически с нуля»

Этой статьёй я бы хотел начать цикл о тестировании и рассказать, как оно построено в ДОМ.РФ и в Банке ДОМ.РФ, и о том, какие грабли можно обойти, если в крупной компании нужно организовать тестирование с нуля.

Для начала разберём, как можно было сократить путь, который в других банках проходили за 5, а иногда и 10 лет, так как IT в крупных компаниях, а если точнее, то производство прикладного ПО в банковском секторе, на мой взгляд, развивается по спирали. Можно 1 виток срезать, главное — понять, как и где.

Виток v.0

Во многих банках ещё лет 15 назад у каждого бизнес-подразделения была своя разработка, собственный «карманный мини IT», который жил по своим процессам и мог никем централизованно не управляться.

Грабли v.0

Такой подход зачастую приводил к дублированию некоторых функций, а иногда и целых систем. Самый частый пример – это отправка SMS. Этот сервис дублировали каждый раз в новой системе просто потому, что соседние подразделения:

1. не коммуницировали достаточно;
2. не были готовы переиспользовать готовые сервисы «соседа»;
3. системы делали разные вендоры, и сервис отправки SMS входил в ТЗ (в оценку, ПК, акты работ и т. п.).

Аналогично и с тестированием: бизнес-подразделения заказывали услуги по тестированию или накапливали собственную компетенцию без централизации практик и знаний. Каждое подразделение заново открывало «велосипед» по тестированию.

Тестированием занимались: разработчики, аналитики, заказчики/бизнес-подразделения, вендор, редко – тестировщики. Тестовая модель (тест-кейсы, тест-планы и результаты тестов) в лучшем случае велась в Word или Excel.

Виток v.1

Следующий виток от 10 до 5 лет назад — централизация IT, выделение функции IT из бизнес-подразделений и появление связующего звена (Бизнес — IT) в виде, например, бизнес-партнёров. Водопадная разработка, создание отделов или центров компетенций по разработке и отдельно по тестированию.

Выделение тестирования в отдельное подразделение повышало качество выпускаемого ПО, но при этом мог неоправданно увеличиться Time2Market (далее — T2M), т. к. каждый отдел отвечал только за свой участок конвейера «от идеи до внедрения».
Тестированием теперь занимались тестировщики, также выделялся процесс приёмочного тестирования или UAT (User Acceptance Testing), что ещё больше удлиняло цепочку передачи релиза.

Тестовая модель переезжает из Word/Excel в системы управления тестированием. Самыми распространёнными были импортные и дорогие Mercury TestDirector (далее — HP QualityCenter/ALM и затем Micro Focus Quality Center/ALM), IBM Jazz, или бесплатный TestLink, который уже тогда выглядел немного «устаревшем» и обрезанным по функционалу.

Изредка могла появляться автоматизация тестирования, но сопровождение/актуализация автотестов чаще всего получалась дорогой и не всегда успевала за стремительным развитием функциональности.

Грабли v.1

Для тестирования на этом витке характерны два ключевых барьера:

1. режим постоянного дефицита времени, т. к. тестирование было «в конце пищевой цепочки», и задачи зачастую уже приходили на тестирование с просрочкой или в последний момент;
2. при планировании релиза оценка и балансировка скоупа релиза шла от объёма разработки, а тестирование могло просто не участвовать и получать скоуп релиза уже готовым.

Добавлялся ещё третий фактор, но он распространялся и на разработку, и на тестирование, а это разные цели:

• цель разработки — как можно скорее (быстрее + дешевле) реализовать требуемую функциональность. Зачастую эта цель подкармливалась и бизнес-заказчиками;
• цель тестирования — не пустить такой релиз в Prod, ну или почти не пустить, т. к. быстрее + дешевле = некачественно (с кучей ошибок, дефектов).

Из-за этого часто между отделами разработки и тестирования возникали «заборы», через которые летали дефекты/релизы/хотфиксы. Это могло провоцировать недопонимание и конфликты, что ещё больше смещало фокус с результата на борьбу между подразделениями, увеличивая T2M.

Виток v.2

Текущий виток, который мы наблюдаем, связан с цифровой трансформацией и массовым внедрением Agile-методологии разработки в крупные компании, включая банки. По сути, это полноценный виток: мы возвращаемся к коллаборации бизнес-подразделений и IT для сокращения T2M. При этом практики и управление IT могут быть как централизованы, так и нет, но между разными бизнес-направлениями, трайбами или командами происходит регулярная синхронизация, есть общие инженерные практики, которые описаны на уровне организации, и эти практики применяются и развиваются командами.

На этом витке производство проходит в самодостаточных командах, которые целиком отвечают за продукт, включая тестирование и качество. Этот подход разрушает «забор» между разработкой и тестированием, требует от команды проводить оценку задачи (фичи, User Story) целиком (аналитика+разработка+тестирование) и позволяет преследовать общую цель — итеративную реализацию качественной функциональности.

Тестовая модель на этом витке хранится в более современных и умеренных по стоимости системах управления тестированием: TestRail, Zephyr+Jira, Test IT. Автоматизация тестирования как централизованное развитие тестирования всё чаще обретает собственные фреймворки на основе open source решений — Selenium и Selenide, Appium, Allure и других. Автотесты активно встраиваются в CI, и за их результатами следит вся команда.

Грабли v.2

Основной, но не единственной сложностью в такой трансформации является риск возврата к Витку V0, если бизнес-подразделения будут воспринимать трансформацию как «передачу» им в управление IT-ресурсов. Такой риск усиливается, если при трансформации команды начинают решать только бизнес-задачи, игнорируя развитие инженерных практик и накапливая техдолг.

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

Виток v.3 ?

Можно спрогнозировать, каким будет следующий виток развития для банков. На мой взгляд, тестирование всё больше и больше будет уходить в автоматизацию, включая тестирование функциональности.

Такой виток потребует 100% автоматизации регресса, а также верного распределения рисков.

Ручное тестирование будет оставаться только как исследовательское тестирование для проверки, что мы сами же не упускаем что-то из виду, создав полноценную автоматизацию тестирования. При этом в смелых компаниях возможно расширение такого тестирования на изолированном участке промышленной эксплуатации для Friends and family или Greenfild.

И тогда, возможно, мы увидим реализацию доставки новых релизов на заданные регионы/зоны/сегменты по нажатию кнопки на мобильном телефоне владельца продукта, как это уже есть у Facebook. Это будет работать для банковских приложений, которые связаны с реальными финансовыми рисками, т. е. я сейчас не говорю про сайт или внутренний портал.

Что же сейчас в ДОМ.РФ с тестированием?

В ДОМ.РФ мы сразу устремились к Витку v2, пропустив Виток v1, и начали создавать полноценные центры компетенции и продуктовые команды, которые включают в себя тестировщиков и инженеров по автоматизации тестирования.

Как это было, а тажке про тепловую карту для внедрения практик тестирования, фреймворк и отечественную систему Test IT — читайте в следующих статьях.

Вместо заключения хочу сказать, что если вы столкнётесь с компанией, где виток развития тестирования находится на уровне Витка v0, то не бойтесь пропустить Виток v1. Не надо агрегировать всю компетенцию по тестированию в одном отделе/управлении/ЦК, не бойтесь сразу накапливать компетенции в командах. Но и не надо бросать команды без «присмотра», без развития компетенции — введите практику комьюнити, обмена опытом и лучшими практиками.