Как стать автором
Обновить

РСХБ на рейде: собираем профессиональную гильдию тестировщиков

Время на прочтение 12 мин
Количество просмотров 22K
Привет! Я Марина Каприз, замруководителя «блока качества», как мы сокращённо называем блок обеспечения и контроля качества выпуска изменений в «РСХБ-Интех». Наш блок похож на гильдию из классической MMO: мы встречаем и решаем проблемы, вполне знакомые профессиональным игрокам в World of Warcraft и EVE Online. Поэтому моя история будет напоминать серию постов на игровом форуме.

Осмотр на месте, или Имею приглашение — готова разбираться

Марина Каприз

Марина Каприз. Короткостриженая пепельная блондинка в рыцарских доспехах
Звезда

Новичок

Сообщений:
1

02-Янв-18 21:53

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

Блок обеспечения и контроля качества выпуска изменений ПО мы создали в 2018 году — тогда проблемы с качеством используемого ПО стали заметны для РСХБ и пользователей. Я пришла, чтобы создать гильдию специалистов, готовых работать вдолгую, а не только под один конкретный проект.
Каждый проект начинается с желания его сделать
С самого начала я знала, что мы будем расширяться, и видела перед собой большую цель: все IT-подсистемы «РСХБ-Интех» должны тестироваться в рамках единой инфраструктуры.

Работает — не трогай. А если не работает?

Марина Каприз

Марина Каприз. Короткостриженая пепельная блондинка в рыцарских доспехах
Звезда

Новичок

Стаж:
1 месяц
Сообщений:
41

04-Фев-18 20:42

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

До нас тестированием занимались люди других профессий: разработчики и аналитики, сторонние подрядчики, не особо связанные друг с другом. Конечно, это было не очень эффективно.
Даже самые простые взаимодействия нужно уметь организовать
Был такой случай: сотрудник подрядчика отказался работать в выходные, чтобы компенсировать отставание. Подрядчик замену предоставить не смог, и сроки были сорваны. Так же бывает, когда группы для данжа собираются из случайных игроков прямо в локации квеста — в любой момент посторонний игрок может выйти. В реальности он хотя бы не будет подводить группу специально.

Взаимодействие тоже надо настраивать

Марина Каприз

Марина Каприз. Короткостриженая пепельная блондинка в рыцарских доспехах
Звезда Звезда

Любопытный

Стаж:
3 месяца
Сообщений:
135

22-Апр-18 19:46

Цепочка «исходные материалы → обработанные материалы → экипировка → игрок» не работает. Точки спавна материалов не заклаймены, крафтеры вынуждены ловить редкие ресурсы на общем рынке. Задача: взять производственные цепочки под наш контроль.

В 2018 году банковские системы — бэк-офис, фронт-офис, подсистемы принятия, рассмотрения и одобрения кредита — были формально связаны и документы между системами ходили. То есть, например, клиент приходит, оформляет заявку в одной системе, а в другой эта заявка проверяется на соответствие всем параметрам. Потом данные о клиенте уходят в третью систему, та возвращает ответ, и только после этого в четвёртой системе деньги поступают на счёт и клиент может их забрать. В принципе, каждая из частей была работоспособна и проходила тестирование — но по отдельности, силами либо самих разработчиков/аналитиков, либо сторонних подрядчиков, — и было глубокое убеждение, что тестирования на заглушках достаточно. В итоге мы получали ошибки интеграции. Это неизбежно, когда разрозненные подразделения дорабатывают только собственную часть ПО, не представляя себе общий бизнес-процесс.
Даже когда на первый взгляд всё работает — до интеграции ещё далеко
Гильдия ММО — не просто группа людей, а чёткие взаимные связи выполняемых ими действий: каждый игрок занимается тем, что ему нравится, но из этих решений суммируется общеполезный результат. В игре это можно объяснить на словах — нам же пришлось запускать первый функционально-интеграционный стенд, подбирать и назначать интеграционных менеджеров на каждый созданный отдел, прописывать стандартные схемы взаимодействия между отделами. До нас этой организации не было: банк иногда запускал новые IT-решения, и разработчики пытались сами найти себе персонал для их тестирования — как будто друзей из реала приглашали в игру.

Фундамент заложен, теперь можно подумать и о развитии

Марина Каприз

Марина Каприз. Короткостриженая пепельная блондинка в рыцарских доспехах
Звезда Звезда Звезда

Опытный

Стаж:
1 год 3 месяца
Сообщений:
681

4-Апр-19 19:11

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

Сначала внедрили общие стандарты управления задачами тестирования — раньше даже Jira пользовались не все, хотя для больших проектов Jira или аналогичная система необходима больше, чем программы голосовой связи в игре. Это стало нашей первой задачей. После уже можно было двигаться дальше.
Например, на первых порах наши системы обновлялись независимо друг от друга, по мере готовности, раз в квартал или раз в полгода, и это не нравилось заказчикам — люди не понимали, когда включится тот или иной заказанный функционал. То есть задача от заказчика получена, вписана в план, её уже начали реализовывать — но не всегда понятно, в какой именно системе это происходит, удастся ли запустить нужный функционал сразу после обновления или неочевидные интеграционные связи потребуют дополнительно доработать смежную систему. Естественно, это надо было исправить, и мы создали такую схему: начинаем с компонентного тестирования на мокапах, потом интеграция — на интеграционном стенде одновременно запускаются смежные системы. Если всё работает, переходим к приёмке. Когда заказчик принимает функционал, делаем прогон регрессионного тестирования, чтобы не сломалось ничего из старых версий.
Поиск и распределение новичков — одна из важнейших задач
Я решила, что разумно сделать цикл выпуска предсказуемым, завершающимся в определённое число месяца, кроме случаев, когда на это число выпадает сдача квартальной и годовой отчётности, а также зарплатные дни. Конечно, в каждый цикл входят приёмка и регрессионное тестирование. Им отведено отдельное время. Так цикл стал ежемесячным, совершенно предсказуемым — как и в любой хорошей гильдии, где заранее прописано, в какой день и время мы встречаемся, чтобы пойти в рейд. По внутренней отчётности — её тоже пришлось стандартизировать — видно, насколько готова следующая система. Бизнес тоже доволен: теперь он знает, когда и чего ожидать. Со временем открыли и второй интеграционный стенд, когда убедились, что первый работает как часы. Теперь один релиз тестируется, второй готовится.
Автотестирование мы пишем на Java — до нас никто не задумывался, что тестирование можно автоматизировать. Новичок, владеющий этим языком, сразу станет полезен команде, долго ждать боя не придётся — Java может быть самым первым языком начинающего программиста. Но, конечно, одним Java не обходимся, иначе гильдия была бы слишком ограниченной. Для тестирования веб-приложений у нас Selenium, для десктопных приложений — Windows Application Driver, а для мобильных — Appium. Библиотеки разные, по потребностям, но в основном TestNG и Junit4. В Test IT мы написали собственную модель регрессионного тестирования, и каждая следующая система, которую подключаем к автотестам, обрабатывается по проверенному стандарту. В этой же системе сделаны интеграционные тест-кейсы, которые можно и нужно переиспользовать при регрессии. Это сильно сокращает время предрелизного тестирования: например, для одной из фронтальных систем оно составляло две недели, затем уменьшилось до десяти дней и, наконец, до восьми. Есть собственная «мобильная ферма» с разными вариантами Android и iOS, чтобы приложения работали на всём зоопарке пользовательских устройств.

О доверии и интересе

Марина Каприз

Марина Каприз. Короткостриженая пепельная блондинка в рыцарских доспехах
Звезда Звезда Звезда

Опытный

Стаж:
1 год 11 месяцев
Сообщений:
986

22-Дек-19 20:37

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

В каждой гильдии важно взаимопонимание и доверие — не просто «делай так, потому что я так сказал», а «почему так лучше?». Думаю, многие встречали гайды, написанные целиком на сленге: довольно сложно убедиться, что советы в них действительно дельные. Подобное впечатление может вызывать скрипт автотестирования, если он изначально не предназначен для того, чтобы его читали люди. С такой проблемой мы столкнулись, когда начали внедрять автотесты — это был уже следующий уровень после контура регрессионного тестирования.
Люди не доверяли автотестам: допустим, программа говорит, что всё работает как следует, но откуда мы знаем, что это действительно так? Точно ли автотест проверил определённый пограничный случай, не было ли ошибки в самой программе? Как вообще неспециалист может убедиться, что автотест делает именно то, что требуется? Проблема не только техническая, но и социальная. Чтобы с этим справиться, мы ушли от Excel и теперь строим модели в Test IT с фреймворком Cucumber на языке Gherkin. Он человекопонятен, на нём писать сценарии автотестирования, даже довольно жёстко упорядоченные, может непрофильный специалист — например, бизнес-аналитик. А ещё легко проверить, что происходит под капотом. Это одновременно упрощает и дисциплинирует.
В блоке качества даже есть собственный фреймворк, чтобы через интерфейс пользователя показывать тестировщикам, работающим вручную, как проходят автотесты бэк-офиса, и не заставлять их осваивать API. Отдельный центр компетенций выделен под автоматизированное регрессионное тестирование — настолько оно для нас важно. Обучаем регрессионщиков работать с ним — пользоваться, анализировать, примерять на себя роль заказчика, чтобы определять приоритеты, — как бы предлагаем поиграть другим классом на твинке, чтобы взглянуть на игру новыми глазами.
Конечно, люди могут сомневаться в автоматизированных решениях
Только у нас тестировщики могут познакомиться с тем, как банк работает изнутри, как проходит обслуживание клиентских операций и оформляется отчётность регулятору.
Например, после операции нормализации по кредитным договорам должно было проставиться дополнительное свойство, используемое при составлении отчётности. Здесь в теории отчётность могла исказиться, так что надо было выверить наличие атрибута на каждом договоре. Ручная проверка заняла бы огромное количество времени. Тестировщик написал SQL-запрос — и выявил отсутствие этого важного атрибута на трёх договорах из нескольких сотен.
Или, например, не работала интеграция бэк-офисной системы со сторонней системой — невозможно было найти клиента. Тестировщик воспользовался инструментом диагностики интеграции, проверил работоспособность обработчиков соответствующего запроса и нашёл, что на запрос бэк-офиса не отвечает внешняя система. Так мы быстро устранили блокирующую ошибку.
Для регрессионщиков работа тоже не будет рутинной: мы ожидаем от них гибкости и адаптивности к доработкам ПО — ведь эти же доработки надо будет проверять, анализировать, как они влияют на действующий функционал. Это сильно отличается от функционального тестирования, где надо проверять непосредственно саму доработку. Формирование тест-сценариев тоже достаётся регрессионщикам, и они же — последний рубеж контроля перед релизом ПО.
Есть и интересная исследовательская работа, которая требует по-настоящему вникать в функционал. Здесь вдаваться в детали нельзя, но одна из таких особенно деликатных систем, тестирование которой может быть неочевидным, — антифрод, то есть определение подозрительных транзакций.
Сейчас мы подключаем больше систем — например, с января по декабрь 2019 года количество обеспеченных нами систем выросло в два раза. Их чуть более 60 — считая только ключевые, важные для банка. Сейчас, в 2021 году, больше половины из них мы уже тестируем. Это, конечно, не показатель уровня гильдии, но показатель её влияния и развития, а ещё повод для гордости — мне нравится смотреть, как мы растём.

Проблемы, решения и перспективы

Марина Каприз

Марина Каприз. Короткостриженая пепельная блондинка в рыцарских доспехах
Звезда Звезда Звезда Звезда

Хранитель мудрости

Стаж:
2 года 5 месяцев
Сообщений:
1520

18-Июн-20 19:21

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

В первые годы (а иногда и сейчас) отдел разработки подкидывал внеплановые задачи — мне пришлось создать внутренний калькулятор возможностей и ресурсов: с чем и как мы можем справиться, можно ли спрогнозировать неожиданности, предусмотреть запас прочности на случай, если появится срочная проблема. Так намного спокойнее.
Вот, например, одна из решённых проблем. Каждый центр компетенций проверял одни и те же тестовые сценарии в рамках своих систем. Лишнего времени на тестирование не было, так что страдала вариативность кейсов — то, сколько различных сценариев за отведённое время тестировщики успевают рассмотреть. Мы едва не срывали сроки и пропускали обидные баги. Пришлось создать интеграционно-регрессионную модель: каждый участник от каждого из центров компетенций проверяет свою часть бизнес-процесса, а ответственное лицо фиксирует результаты тестирования. Это как функционально-интеграционное тестирование, которое мы начали строить в 2019 году, только для «регресса».
Даже когда гильдия работает как часы, внешние проблемы всё ещё остаются
Блок обеспечивает тестирование по нескольким специальностям: функционально-интеграционное, регрессионное с применением и развитием автотестов, нагрузочное — и все они необходимы, а обеспечивают их отдельные команды. Сотрудники могут переходить из команды в команду и расширять свои компетенции. Есть и вертикальный рост: инженер → ведущий инженер → главный инженер → руководитель направления. Оценка и интервью проводятся раз в год, рост зарплаты — каждые полгода.

Давайте расти вместе

Марина Каприз

Марина Каприз. Короткостриженая пепельная блондинка в рыцарских доспехах
Звезда Звезда Звезда Звезда Звезда

Легенда

Стаж:
3 года 10 месяцев
Сообщений:
2073

26-Ноя-21 20:38

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

Как там пишутся рекрутинг-посты?

Сейчас мы продолжаем расти и набирать персонал как в офис, так и на удалёнку. Задачи, приходящие от бизнеса, пока что надо приоритизировать и ставить в очередь, но это болезнь роста, а не нечто неизбежное. С одной стороны, сразу было понятно, что мы будем развиваться, с другой — пока мы не совсем отвечаем потребностям банка и приходится посматривать на калькулятор возможностей. Желающим попробовать работу в нашем блоке есть куда расти — бэк-офис и фронт-офис требуют разных компетенций. Отдел автоматизации — одна из важных точек роста. Бо́льшую часть ключевых систем мы уже автоматизировали, но работы ещё много, а в идеале надо максимально уйти от ручного тестирования.
В 2020 году мы подняли нагрузочное тестирование. В том же году перешли на двухнедельный Agile, хотя часть систем ещё остаётся в классической водопадной модели.
На ежегодном интервью, когда пересматривается оклад, компетенции и перспективы сотрудников, мы внимательно слушаем предложения. Смею надеяться, что это у нас организовано даже лучше, чем в MMO: не общее совещание, где все перекрикивают друг друга, а личный разговор о будущем и о желаниях.
Наш гильдхолл ждёт гостей!
Нас интересуют все спецы: сеньоры, мидлы, джуны. Джуны не окажутся брошены на произвол судьбы — первые три месяца каждого сопровождает персональный тренер.
Если вам показалось, что последние абзацы — это завуалированный рекрутинг, то вам не показалось: это он и есть. В конце концов, мы точно не хуже гильдии в WoW, где каждый пост с рассказом о себе заканчивается ссылкой на вступление!
Теги:
Хабы:
+15
Комментарии 14
Комментарии Комментарии 14