Если бы мне задали такой вопрос, то я не смог бы на него правильно ответить. Ведь начинал я с ручного тестирования, а сейчас мы департаментом раскатываем на весь банк гигантский «дашборд», который привязан буквально ко всем данным компании, и позволяет оценить качество работы любой команды. Меня зовут Иван Боклач, я руководитель направления развития экспертизы QA в Центре Координации и Повышении эффективности разработки в Альфа-Банк. Я занимаюсь развитием новых технологий, метриками, стандартизацией и автоматизацией процессов. Всё это пишу не для хвастовства, отнюдь, а чтобы показать, куда вас может привести дорожка QA. И, главное, что на этой дорожке вам нужно «крафтить», чтобы получить примерно те же результаты.  Как-то так получилось, что вся моя карьера похожа на игру: попадаешь на уровень, прокачиваешься, побеждаешь «босса», получаешь +50 к опыту и новый меч, чтобы перейти на новый «уровень». Поэтому пойдем по неким «уровням». Начать придётся с нулевого. Но рассказывать всю биографию не буду, не беспокойтесь, постараюсь только по делу.  В моей трудовой книжке всего 2 IT-компании: Аплана и Альфа. С первой начался мой путь, куда я пришел на ручное тестирование без опыта на проект Сбербанк.Онлайн. Поработал там достаточно, чтобы «вкатиться» в профессию. Раньше я работал не в IT, хотя в дипломе написано «Прикладная информатика в психологии». Это когда проводишь много интервью, опытов, экспериментов, опросов, собираешь данные и, чтобы их визуализировать, используешь программирование. В Альфа-Банк я пришел в июне 2017 года на позицию рядового тестировщика в одну из продуктовых команд, которая занималась частью интернет-банка юридических лиц, это веб-часть (не мобилки). Наша команда занималась модулем тарифов для юрлиц, а я тестировал эти тарифы. Они складываются из месячной оплаты, в которую включены переводы в адрес физлиц, разные лимиты переводов, вывода денег без комиссии. При том всё это регламентируется со стороны ЦБ, потому что «обналичка». Например, у некого ООО «Вектор» есть тариф «Стандарт», в который включено 10 платежей в адрес физлица и можно выводить 150 000 рублей в месяц. Все лимиты отображаются в интернет-банке. Если юрлицо выйдет за границу, то за вывод 1000 рублей сверх лимита будет комиссия. Тарифы постепенно перетекают в функциональность других частей банка, например, рублевых платежей, ведь все эти переводы и платежи имеют накопительный эффект. Тестировали всё вручную. В тестовой среде, мы, грубо говоря, опустошали лимиты и проверяли реакцию системы. Например, заходили в приложение «Рублевые платежи», вводили сумму в графе платеж, и чекали, всплывает ли бар «Ваш лимит закончен и перевод будет облагаться комиссией в 1.5 %» или нет.  Совет №1. Если занимаетесь ручным тестированием — быстрее переходите на автоматизацию или в команду/компанию, где вам помогут это сделать.  В Аплане мне помогли «войтивайти», но если бы я оставался там до сих пор, то, субъективно, рост был бы очень медленный, потому что с ручного тестирования я бы долго не слезал. Поэтому эта глава и идёт под нулевым уровнем.  Автоматизация «ум в порядок приводит» и позволяет расти, как бы банально это не звучало.  Например, в Альфа-Банк меня брали «с запасом» — на собеседовании сразу предупредили, что QA не занимаются чисто ручным тестированием, а, в первую очередь, автоматизацией. В этом помогал фреймворк Akita, который позволяет заходить легко в автоматизацию: берёшь готовые параметризированные шаги, составляешь автотесты, если что-то не хватает — дописываешь тест.  Позднее я включился в команду, которая развивала фреймворк, писал непосредственно общие шаги в нём для всех пользователей. Когда создатель фреймворка Аня Чернышова ушла в другую компанию, я стал заниматься поддержкой инструмента. С этого я начинал, грубо говоря. Потом пошел другой уровень программирования и автоматизации. Это один из самых сложных проектов с точки зрения технической составляющей.  Мне, как рядовому пользователю (физлицу) сделать перевод или покупку через телефон просто. Не нужно ничего заверять, никуда бегать — приходит смс/пуш, вбиваю код — оплачено. Или вообще лицом можно оплатить новые кроссовки без всяких пушей. У юрлиц в этом плане сплошное легаси. У них, если это не ИП, есть бухгалтеры, директор и другая масса народа, принимающего разные решения. У одного гендира может быть несколько компаний, в каждой свой бухгалтер (или один общий). Часто именно гендиректор — конечный бенефициар для подписания той или иной платежки. Поэтому юрлицо привязано к ПК, чтобы открыть интернет-банк и подписать ту или иную бумагу.  — Прошлый век какой-то — почему, я как гендиректор, не могу отправить платёжки через телефон?  Можно, но есть риски.  Например, злоумышленник может перехватить СМС у оператора и перевести деньги в другое ООО, а потом вывести (так называемое клонирование СМС). Для юрлиц это имеет место быть, потому что обычно там большие деньги крутятся.  Если СМС не перехватили, то оно просто может «потеряться» и тогда страдает центр поддержки клиентов. Поскольку банк напрямую не контролирует операторов, то когда смс не пришло 2-3 раза, то злость срывают на операторах банка.  Да и СМС платные, и если посмотреть глобально на весь банк, то у отдела по работе с юрлицами львиная доля бюджета уходит на СМС. Но чтобы юрлица могли подтверждать платежки, запустили Pay Control (PC) — программный комплекс для подписи платежек юрлицами с телефона. Как это работает? Например, в течение дня гендиректор ждёт, когда ему придут определенные платежки в приложении Альфа Бизнес Мобайл на телефоне. Бухгалтер составляет платежные поручения, проверяет со своей стороны и подписывает.  Гендиректору поступает оповещение на мобильный телефон о том, что ему необходимо подписать несколько платежных поручений. Он/она открывает мобильное приложение, через PayControl происходит считывание пальца или лица, которые считаются как электронная подпись или СМС-код. После этого происходит отправка платежей, как если бы гендиректор зашел в интернет-банк с компьютера и подписал ЭЦП. На словах кажется достаточно простым. Но только кажется — задача-то нетиповая. PayControl — это стороннее решение от стороннего вендора. Это было решение, у которого ещё не было аналогов, поэтому подсмотреть  чей-то опыт не получалось. Фишка PayControl в том, что она работала именно в связке веб-интерфейса и мобильного интерфейса. Нам, как тестировщикам, и нужно было проверить как работает связка.  Обычно тестирование в нашем понимании (банке) делится на веб-тестирование и мобильное тестирование. Здесь задача состояла из двух частей и получалось полноценное End-2-End тестирование сразу двух платформ: одну часть тестирования делали на вебе, а другую на телефоне. Мы заводили определенное количество клиентов, чтобы проверить как это взаимодействие происходит: создаётся платежка; подписывается с одной стороны; приходит положительный ответ; появляется пуш на мобильном устройстве; подпись лицом или пальцем (в зависимости от устройства); успешная или неуспешная процедура. Вот эту всю штуку мы тестировали. Связка была достаточно сложная, потому что не должно быть задержек по времени.  Какую-то часть, вроде создания платежа или отправки, можно было автоматизировать. Что-то не было необходимости автоматизировать, например, ту часть, которая была привязана к клиенту АБМ (Альфа Бизнес Мобайл), где: мы заходили в телефон; видели, что появился пуш; подписывали; и после этого платеж переходил в статус отправлен, что можно было проверить по логам в вебе. Поскольку эта технология нигде не использовалась, то связка тестирования не полностью бесшовная: была прослойка в виде тестировщика, который занимался как автоматизированной частью веба, так и ручной, со стороны мобильных устройств. Притом одно в другое переходило постоянно и нужно было поддерживать связь правильно. Плюс присутствовало шифрование. Но гарантом шифрования при подписании платежных поручений выступает приложение — это его основная функция. Поэтому шифрование (и всё остальное на стороне PayControl) мы не тестировали. Совет №2. Переходите в продуктовые команды. Неочевидный совет на первый взгляд. Но без продуктовых команд такие связки вряд ли получится нормально протестировать. У нас нет такого, что кто-то разрабатывает, а потом отдаёт в отдел тестирования. У нас продуктовая команда и мы работаем по скраму, стартуем все одновременно. На момент груминга приходят мысли, какие проверки нужно делать, какие обработчики писать и как их проверять. Обработчики есть как со стороны миддла, так и со стороны фронта. Со стороны фронта, когда мы что-то перехватываем, вводим данные, они отправляются с помощью миддла на бэк, откуда возвращается значение в базу данных, и меняется статус платежа. Я как тестировщик проверял эту связку.  Это стандартный процесс, у нас пишется код на миддле, код на фронт, и это всё проверяется. Мы можем отдельно проверять как работает миддловая часть, которая отправляет запросы, и что эти запросы ей возвращаются, и соответствуют ли действительности. Эти проверки проговариваются с аналитиком, потому что он более детально погружен в специфику, дополнительно обговариваются проверки с разработчиками, чтобы они со своей стороны могли проверить какие-то специфические сценарии на уровне юнит-тестов.  Ну а дальше тестировщик уже начинает описывать то, как он будет тестировать. Это могут быть отдельные тестовые сценарии, набор тест-кейсов на уровень мидловой части, на фронтовую часть, интеграционные тесты на связку фронта и миддла. Например, когда я приложил палец, то зашифрованный токен с помощью API ушёл в БД, она ответила ОК, и у нас страница успеха, либо ответил НЕ ОК, либо неправильный токен. Вот такие кейсы мы готовили и проверяли. К концу спринта, когда написан код, написана документация, у нас готовы и автотесты. А когда нет подобных проектов, то у вас всё равно каждую неделю новая задача. Вроде бы над одним проектом работаете уже полгода, и задачи вроде бы похожи — пишешь автотесты, но функциональность то разная: сегодня платежи, завтра тарифы, послезавтра приложение, через неделю веб-версия. Появляются новые вызовы, плюс разработка продуктовая: в связке с разработчиками, аналитиками, дизайнером можно получить новые знания не только в рамках развития компетенции, но и стать Т-shape специалистом. Например,  поработав над задачами аналитика, той же документацией, лучше понимаешь как работает голова аналитика, понимаешь как им удобнее составить тот или иной тестовый сценарий. Про разработку я уже не говорю — это всегда плюс: мы пишем на том же языке, что и наши разработчики, что помогает нам друг друга лучше понимать. Например, пишешь код для какого-то автоматизированного теста, в коде 50 строк. Ставишь в пулл реквест своего мидлового разработчика, он говорит: все хорошо, но можно сделать короче через вот эту функцию, накидывает где почитать теорию и посмотреть практику. Через день-два 50 строк сокращаешь до 5. За счет этого ты прогрессируешь, прогрессируют твои тесты, тебе интересно. Багатон — это один из самых сложных проектов с точки зрения руководителя. Наверно, здесь совет будет такой: Совет №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 пулреквестов.  Этот проект сложный и технически, и организационно. Навыки, полученные на Багатоне, я использовал в разработке общего показателя качества, на который будут завязаны не только тестировщики, но и все, начиная с дизайнера и заканчивая продактом. Это некий дашборд в инструменте для бизнес-анализа, на котором можно посмотреть что с качеством у его команды и в целом. Потому что мы сейчас всё пытаемся автоматизировать, чтобы ручного труда было минимум.  Каждое подразделение так или иначе собирает какие-то метрики эффективности, качества, разработки и прочее. Сейчас мы это хотим стандартизировать, унифицировать, и добавить в общий единый процесс производственного цикла разработки, где будут чётко прописаны пайпланы, привязаны всякие оценки качества, вроде «Выполнил пункт 1-2-3, можешь дальше идти по процессу CI и CD». Плюс для CI у нас есть собственная разработка — это платформа, куда всё это автоматически загружается:  таску в Jira создал; а она автоматически создала таску на раскатку; подтянула все артефакты; посмотрела как прошли все тесты при мердже — если они больше 90% то ОК, если меньше, то не дает двигаться дальше; а если мы говорим про разработку и юнит тесты, то там только 100% покрытие юнит тестами; при этом есть внутренний банковский коэффициент, который показывает, сколько времени может жить тот или иной баг, в зависимости от критичности. Вот из таких кусочков Лего мы собираем «дом». Если «дом» получился, то мы его запускаем в бой. Если не получился, то система смотрит что не работает: тесты или образ не собрался.  Также мы пытаемся автоматизировать онбординг, с учетом ситуации на рынке, когда хорошие разработчики и тестировщики уже где-то заняты, но при этом много джунов. Но джунов мы стараемся выращивать сами, поэтому у нас запускаются Кампусы и школы, где мы учим всех, а дальше отбираем и обучаем специализированным знаниям. Вот такую штуку мы разработали, потом продали конечным пользователям. И те навыки, которые я получил раньше, помогли мне общаться с директорами или с более высокими должностями. Например, мы используем очень сложные формулы для высчитывания коэффициентов: Есть коэффициент багов, плато по дефектам: в течение квартала смотрим, сколько было багов в начале, сколько в конце, как работает с багами команда, был ли прирост или убывание.  Есть глобальный коэффициент доступности системы. Например, если с Альфа Мобайл, приложением для физических лиц, проблемы, то приложение становится недоступным. Здесь сложный подсчет: на какой количество людей аффектит, сколько денег недополучает банк, и пр. Из всех коэффициентов складывается общий коэффициент и он аффектит на все системы, на все подразделения, на всех людей, завязан на премию. Оглядываясь назад, я вижу, что у меня не было застоя в работе. Не было такого что я 3 года сидел на одной должности, а потом хоп — «Давай тебя повысим». Против такого я не против, но интереснее, когда подворачиваются проекты. А они подворачивались: либо я участвовал в каких-то интересных событиях, которые позволяли мне двигаться вверх по карьерной лестнице, либо события в Альфе мотивировали меня развиваться. Карьерный трек у каждого сотрудника свой. Кто-то любит техническую сторону, а кто-то менеджерскую. В моем карьерном треке эргономично сплелись обе, и я рад, что смог реализоваться в обеих. Хочу поделиться некоторыми советами, которые по моему мнению, помогут и вам стать многосторонним специалистом в своем деле: Не бойтесь задавать вопросы, даже если будет казаться, что они «тупые» Выделяйте 20% своего рабочего времени на изучение чего-то нового, подключайтесь к новым инициативам/проектам/группам по интересам Делайте упор на автоматизацию. Она вам поможет как при написании хороших тестов, так и в менеджменте Изучайте и предлагайте нестандартные решения, даже если на первый взгляд они безумные:) Рекомендуем почитать [подборка от редактора] «У меня из пет-проектов только животные дома»: новый выпуска «Из бэклога» #6 Арт-терапия и вялотекущая миграция с монолита У нас была стратегия и мы её придерживались: как подружить бизнес и DevRel, сохранив ментальное здоровье Как мы играли в тесты на Groovy и проиграли Подборка книг по QA без Романа Савина Ещё одна подборка книг по QA Как мы ведём документацию рядом с кодом Как мы ведём требования к ПО: формализация Почему мы ошибаемся при первоначальной оценке фич? Также подписывайтесь на Телеграм-канал Alfa Digital — там мы постим новости, опросы, видео с митапов, краткие выжимки из статей, иногда шутим.