Если бы мне задали такой вопрос, то я не смог бы на него правильно ответить. Ведь начинал я с ручного тестирования, а сейчас мы департаментом раскатываем на весь банк гигантский «дашборд», который привязан буквально ко всем данным компании, и позволяет оценить качество работы любой команды. Меня зовут Иван Боклач, я руководитель направления развития экспертизы QA в Центре Координации и Повышении эффективности разработки в Альфа-Банк. Я занимаюсь развитием новых технологий, метриками, стандартизацией и автоматизацией процессов.

Всё это пишу не для хвастовства, отнюдь, а чтобы показать, куда вас может привести дорожка QA. И, главное, что на этой дорожке вам нужно «крафтить», чтобы получить примерно те же результаты. 

Как-то так получилось, что вся моя карьера похожа на игру: попадаешь на уровень, прокачиваешься, побеждаешь «босса», получаешь +50 к опыту и новый меч, чтобы перейти на новый «уровень». Поэтому пойдем по неким «уровням». Начать придётся с нулевого. Но рассказывать всю биографию не буду, не беспокойтесь, постараюсь только по делу. 

Уровень 0 — ручной

В моей трудовой книжке всего 2 IT-компании: Аплана и Альфа. С первой начался мой путь, куда я пришел на ручное тестирование без опыта на проект Сбербанк.Онлайн. Поработал там достаточно, чтобы «вкатиться» в профессию.

В Альфа-Банк я пришел в июне 2017 года на позицию рядового тестировщика в одну из продуктовых команд, которая занималась частью интернет-банка юридических лиц, это веб-часть (не мобилки). Наша команда занималась модулем тарифов для юрлиц, а я тестировал эти тарифы. Они складываются из месячной оплаты, в которую включены переводы в адрес физлиц, разные лимиты переводов, вывода денег без комиссии. При том всё это регламентируется со стороны ЦБ, потому что «обналичка».

Например, у некого ООО «Вектор» есть тариф «Стандарт», в который включено 10 платежей в адрес физлица и можно выводить 150 000 рублей в месяц. Все лимиты отображаются в интернет-банке. Если юрлицо выйдет за границу, то за вывод 1000 рублей сверх лимита будет комиссия. Тарифы постепенно перетекают в функциональность других частей банка, например, рублевых платежей, ведь все эти переводы и платежи имеют накопительный эффект.

Тестировали всё вручную. В тестовой среде, мы, грубо говоря, опустошали лимиты и проверяли реакцию системы. Например, заходили в приложение «Рублевые платежи», вводили сумму в графе платеж, и чекали, всплывает ли бар «Ваш лимит закончен и перевод будет облагаться комиссией в 1.5 %» или нет. 

Совет №1. Если занимаетесь ручным тестированием — быстрее переходите на автоматизацию или в команду/компанию, где вам помогут это сделать. 

В Аплане мне помогли «войтивайти», но если бы я оставался там до сих пор, то, субъективно, рост был бы очень медленный, потому что с ручного тестирования я бы долго не слезал. Поэтому эта глава и идёт под нулевым уровнем. 

Автоматизация «ум в порядок приводит» и позволяет расти, как бы банально это не звучало. 

Например, в Альфа-Банк меня брали «с запасом» — на собеседовании сразу предупредили, что QA не занимаются чисто ручным тестированием, а, в первую очередь, автоматизацией. В этом помогал фреймворк Akita, который позволяет заходить легко в автоматизацию: берёшь готовые параметризированные шаги, составляешь автотесты, если что-то не хватает — дописываешь тест. 

Позднее я включился в команду, которая развивала фреймворк, писал непосредственно общие шаги в нём для всех пользователей. Когда создатель фреймворка Аня Чернышова ушла в другую компанию, я стал заниматься поддержкой инструмента.

С этого я начинал, грубо говоря. Потом пошел другой уровень программирования и автоматизации.

Уровень 2 — автоматизированный: Pay Control

Это один из самых сложных проектов с точки зрения технической составляющей. 

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

У юрлиц в этом плане сплошное легаси. У них, если это не ИП, есть бухгалтеры, директор и другая масса народа, принимающего разные решения. У одного гендира может быть несколько компаний, в каждой свой бухгалтер (или один общий). Часто именно гендиректор — конечный бенефициар для подписания той или иной платежки. Поэтому юрлицо привязано к ПК, чтобы открыть интернет-банк и подписать ту или иную бумагу. 

— Прошлый век какой-то — почему, я как гендиректор, не могу отправить платёжки через телефон? 

Можно, но есть риски. 

• Например, злоумышленник может перехватить СМС у оператора и перевести деньги в другое ООО, а потом вывести (так называемое клонирование СМС). Для юрлиц это имеет место быть, потому что обычно там большие деньги крутятся. 

• Если СМС не перехватили, то оно просто может «потеряться» и тогда страдает центр поддержки клиентов. Поскольку банк напрямую не контролирует операторов, то когда смс не пришло 2-3 раза, то злость срывают на операторах банка. 

• Да и СМС платные, и если посмотреть глобально на весь банк, то у отдела по работе с юрлицами львиная доля бюджета уходит на СМС.

Но чтобы юрлица могли подтверждать платежки, запустили Pay Control (PC) — программный комплекс для подписи платежек юрлицами с телефона.

Как это работает? Например, в течение дня гендиректор ждёт, когда ему придут определенные платежки в приложении Альфа Бизнес Мобайл на телефоне. Бухгалтер составляет платежные поручения, проверяет со своей стороны и подписывает. 

Гендиректору поступает оповещение на мобильный телефон о том, что ему необходимо подписать несколько платежных поручений. Он/она открывает мобильное приложение, через PayControl происходит считывание пальца или лица, которые считаются как электронная подпись или СМС-код. После этого происходит отправка платежей, как если бы гендиректор зашел в интернет-банк с компьютера и подписал ЭЦП.

На словах кажется достаточно простым. Но только кажется — задача-то нетиповая.

• PayControl — это стороннее решение от стороннего вендора.

• Это было решение, у которого ещё не было аналогов, поэтому подсмотреть  чей-то опыт не получалось.

• Фишка PayControl в том, что она работала именно в связке веб-интерфейса и мобильного интерфейса.

Нам, как тестировщикам, и нужно было проверить как работает связка. 

Обычно тестирование в нашем понимании (банке) делится на веб-тестирование и мобильное тестирование. Здесь задача состояла из двух частей и получалось полноценное End-2-End тестирование сразу двух платформ: одну часть тестирования делали на вебе, а другую на телефоне.

Мы заводили определенное количество клиентов, чтобы проверить как это взаимодействие происходит:

• создаётся платежка;

• подписывается с одной стороны;

• приходит положительный ответ;

• появляется пуш на мобильном устройстве;

• подпись лицом или пальцем (в зависимости от устройства);

• успешная или неуспешная процедура.

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

Какую-то часть, вроде создания платежа или отправки, можно было автоматизировать. Что-то не было необходимости автоматизировать, например, ту часть, которая была привязана к клиенту АБМ (Альфа Бизнес Мобайл), где:

• мы заходили в телефон;

• видели, что появился пуш;

• подписывали;

• и после этого платеж переходил в статус отправлен, что можно было проверить по логам в вебе.

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

Плюс присутствовало шифрование. Но гарантом шифрования при подписании платежных поручений выступает приложение — это его основная функция. Поэтому шифрование (и всё остальное на стороне PayControl) мы не тестировали.

Совет №2. Переходите в продуктовые команды.

Неочевидный совет на первый взгляд. Но без продуктовых команд такие связки вряд ли получится нормально протестировать.

У нас нет такого, что кто-то разрабатывает, а потом отдаёт в отдел тестирования. У нас продуктовая команда и мы работаем по скраму, стартуем все одновременно. На момент груминга приходят мысли, какие проверки нужно делать, какие обработчики писать и как их проверять. Обработчики есть как со стороны миддла, так и со стороны фронта.

Со стороны фронта, когда мы что-то перехватываем, вводим данные, они отправляются с помощью миддла на бэк, откуда возвращается значение в базу данных, и меняется статус платежа. Я как тестировщик проверял эту связку. 

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

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

Ну а дальше тестировщик уже начинает описывать то, как он будет тестировать. Это могут быть отдельные тестовые сценарии, набор тест-кейсов на уровень мидловой части, на фронтовую часть, интеграционные тесты на связку фронта и миддла. Например, когда я приложил палец, то зашифрованный токен с помощью API ушёл в БД, она ответила ОК, и у нас страница успеха, либо ответил НЕ ОК, либо неправильный токен. Вот такие кейсы мы готовили и проверяли.

К концу спринта, когда написан код, написана документация, у нас готовы и автотесты.

А когда нет подобных проектов, то у вас всё равно каждую неделю новая задача. Вроде бы над одним проектом работаете уже полгода, и задачи вроде бы похожи — пишешь автотесты, но функциональность то разная: сегодня платежи, завтра тарифы, послезавтра приложение, через неделю веб-версия.

Появляются новые вызовы, плюс разработка продуктовая: в связке с разработчиками, аналитиками, дизайнером можно получить новые знания не только в рамках развития компетенции, но и стать Т-shape специалистом. Например,  поработав над задачами аналитика, той же документацией, лучше понимаешь как работает голова аналитика, понимаешь как им удобнее составить тот или иной тестовый сценарий.

Про разработку я уже не говорю — это всегда плюс: мы пишем на том же языке, что и наши разработчики, что помогает нам друг друга лучше понимать. Например, пишешь код для какого-то автоматизированного теста, в коде 50 строк. Ставишь в пулл реквест своего мидлового разработчика, он говорит: все хорошо, но можно сделать короче через вот эту функцию, накидывает где почитать теорию и посмотреть практику. Через день-два 50 строк сокращаешь до 5. За счет этого ты прогрессируешь, прогрессируют твои тесты, тебе интересно.

Уровень 3 — организационный: Багатон

Багатон — это один из самых сложных проектов с точки зрения руководителя.

Наверно, здесь совет будет такой:

Совет №3. Если есть возможность сделать что-то нестандартное — делайте.

Объясню.

Организовать мероприятие вида «хакатон», «митап», «миниконфа» — это глобальная менеджерская работа. Даже если вы уже менеджер — гарантирую, это будет вам вызовом. Например, в тот момент у меня был менеджерский опыт организации 35-40 человек, которые меня слушают. При этом, как руководитель, я отвечаю за большое количество тестировщиков в дирекции ЦБ ЮЛ, за их развитие, за денежные мотивации, за карьеры, за код, за тесты и за качество. Примерно через полгода вхождения в новую должность ко всему привыкаешь. 

А вот Багатон — это история на 1,5 месяца, когда:

• возникло на порядок больше задач;

• возникло на порядок больше новых задач;

• возникло на порядок больше новых задач, которые приходилось решать с большим количеством людей, которые непосредственно мне не подчинялись.

Теперь немного подробностей. 

Багатон — это как хакатон, но вместо MVP какого-то приложения, ваш результат — это фиксированные баги. Багатон проходил в рабочее время, фиксились баги, которые должны быть закрыты в рабочее время, но ещё за это можно было получить дополнительные деньги (400 000 за первое место). Выглядит подозрительно, но так и есть — в рабочее время делаешь свою работу и получаешь за это премию.

Так вот — для меня, как руководителя, в организации мероприятия было сложно сконцентрироваться и решить поставленную задачу в правильном русле на все 100%, чтобы ничего не упустить. А упустить было из чего. 

• Надо убедить бизнес, что нам нужно провести новое и непонятное мероприятие, которое в России проводили-то 1-2 раза, выделить под это дело бюджет, выделить бюджет на денежные поощрения. И всё это в рабочее время.

• Надо убедить маркетинг согласиться мне помочь, выстроить с ними взаимодействие, найти подрядчика и платформу для проведения мероприятия, не считая брони помещений в офисе, организации «пиццаколы» и пр.

• Надо убедить несколько сотен человек, что им нужно собраться в команды, выбрать капитанов и подготовиться к некому Багатону. Поскольку у нас в дирекции было 2 платформы — веб и АБМ (мобилки), команд было около 50, по 4-6 человек. Здесь было попроще, отчасти, аргумент «Вы будете делать свою обычную работу и ещё за это дополнительные деньги получите» всех убедил.

• Надо проанализировать все баги, воспроизвести, подтянуть новые свежие данные (логи, скрины), вытянуть информацию из суппорта, промаркировать, поставить каждому багу оценку. На это обновление данных ушло около 2-х недель.

• Надо проверить и подготовить платформу, пробрендировать, создать ролевую модель, залить баги, протестировать как организатор, как участник, как член жюри по заранее подготовленным чека-листам (и чек-листы тоже надо было подготовить).

• И еще с десяток задач без категории, вроде того, надо прописать инструкции для участников, разослать приглашения и т.д. и т.п.

В итоге всё получилось, но было сложно. 1,5 месяца Багатона можно сравнить с 15 месяцами обычной работы менеджером.

Итоги кратко.

У нас было 2 продукта (НИБ и АБМ), 22 члена жюри, 2 приза по 400 000 рублей, 40 команд, 243 участника, 95 задач, из них 81 взяли в работу, 57 из 81 успешно решили и 53 из 57 успешно исправлены. За это время было 130 пулреквестов.

Уровень 4 — глобальный: «доска почёта»

Этот проект сложный и технически, и организационно.

Навыки, полученные на Багатоне, я использовал в разработке общего показателя качества, на который будут завязаны не только тестировщики, но и все, начиная с дизайнера и заканчивая продактом. Это некий дашборд в инструменте для бизнес-анализа, на котором можно посмотреть что с качеством у его команды и в целом. Потому что мы сейчас всё пытаемся автоматизировать, чтобы ручного труда было минимум. 

Каждое подразделение так или иначе собирает какие-то метрики эффективности, качества, разработки и прочее. Сейчас мы это хотим стандартизировать, унифицировать, и добавить в общий единый процесс производственного цикла разработки, где будут чётко прописаны пайпланы, привязаны всякие оценки качества, вроде «Выполнил пункт 1-2-3, можешь дальше идти по процессу CI и CD».

Плюс для CI у нас есть собственная разработка — это платформа, куда всё это автоматически загружается: 

• таску в Jira создал;

• а она автоматически создала таску на раскатку;

• подтянула все артефакты;

• посмотрела как прошли все тесты при мердже — если они больше 90% то ОК, если меньше, то не дает двигаться дальше;

• а если мы говорим про разработку и юнит тесты, то там только 100% покрытие юнит тестами;

• при этом есть внутренний банковский коэффициент, который показывает, сколько времени может жить тот или иной баг, в зависимости от критичности.

Вот из таких кусочков Лего мы собираем «дом». Если «дом» получился, то мы его запускаем в бой. Если не получился, то система смотрит что не работает: тесты или образ не собрался. 

Также мы пытаемся автоматизировать онбординг, с учетом ситуации на рынке, когда хорошие разработчики и тестировщики уже где-то заняты, но при этом много джунов. Но джунов мы стараемся выращивать сами, поэтому у нас запускаются Кампусы и школы, где мы учим всех, а дальше отбираем и обучаем специализированным знаниям.

Вот такую штуку мы разработали, потом продали конечным пользователям. И те навыки, которые я получил раньше, помогли мне общаться с директорами или с более высокими должностями. Например, мы используем очень сложные формулы для высчитывания коэффициентов:

• Есть коэффициент багов, плато по дефектам: в течение квартала смотрим, сколько было багов в начале, сколько в конце, как работает с багами команда, был ли прирост или убывание. 

• Есть глобальный коэффициент доступности системы. Например, если с Альфа Мобайл, приложением для физических лиц, проблемы, то приложение становится недоступным. Здесь сложный подсчет: на какой количество людей аффектит, сколько денег недополучает банк, и пр.

• Из всех коэффициентов складывается общий коэффициент и он аффектит на все системы, на все подразделения, на всех людей, завязан на премию.

Послесловие

Оглядываясь назад, я вижу, что у меня не было застоя в работе. Не было такого что я 3 года сидел на одной должности, а потом хоп — «Давай тебя повысим». Против такого я не против, но интереснее, когда подворачиваются проекты. А они подворачивались: либо я участвовал в каких-то интересных событиях, которые позволяли мне двигаться вверх по карьерной лестнице, либо события в Альфе мотивировали меня развиваться.

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

Хочу поделиться некоторыми советами, которые по моему мнению, помогут и вам стать многосторонним специалистом в своем деле:

• Не бойтесь задавать вопросы, даже если будет казаться, что они «тупые»

• Выделяйте 20% своего рабочего времени на изучение чего-то нового, подключайтесь к новым инициативам/проектам/группам по интересам

• Делайте упор на автоматизацию. Она вам поможет как при написании хороших тестов, так и в менеджменте

• Изучайте и предлагайте нестандартные решения, даже если на первый взгляд они безумные:)

Рекомендуем почитать [подборка от редактора]

• Арт-терапия и вялотекущая миграция с монолита

• У нас была стратегия и мы её придерживались: как подружить бизнес и DevRel, сохранив ментальное здоровье

• Как мы играли в тесты на Groovy и проиграли

• Подборка книг по QA без Романа Савина

• Ещё одна подборка книг по QA

• Как мы ведём документацию рядом с кодом

• Как мы ведём требования к ПО: формализация

• Почему мы ошибаемся при первоначальной оценке фич?

Также подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.