Привет! На связи Антон Тарасов, руководитель группы тестирования мобильного приложения Тинькофф. В течение последних десяти лет я был инженером и руководителем в направлениях QA, Scrum-Master, Delivery Manager и Project Manager. 

Постараюсь ответить на вопрос: должен ли QA уметь писать код? Расскажу о том, кто такие Full Stack QA в нашей компании, как мы их нанимаем, обучаем и растим. Я не буду говорить о том, как мы переизобрели задачи или понимание того, кто такой QA в современном энтерпрайзе. Или о том, как мы совершили некую революцию в индустрии. Я лишь расскажу, какие проблемы мы встречаем и как их стараемся решить. 

Добро пожаловать под кат!

QA должен совмещать в себе разные качества

Исторически сложилось, что на проектах тестирование разделяется на ручное и автоматизированное. 

«Ручник» занимается тем, что:

• проводит тестирование на «кончиках пальцев»;

• пишет и поддерживает тестовые артефакты;

• выступает как тест-дизайнер, если есть направление Test Automation;

• заводит дефекты;

• помогает в построении процессов разработки, если в компании применяется подход QA.

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

Автоматизатор занимается тем, что:

• пишет автотесты;

• работает с фреймворком.

Когда на проекте есть автотесты, их нужно поддерживать. Если QA не может сделать этого сам, растет нагрузка и на разработчиков, и на автоматизаторов и ухудшается time-to-market.

Плюсы разделения тестирования — прозрачность процесса и четкое распределение ролей. Этот подход работает в моделях разработки ПО, близких к водопаду.

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

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

Если объединить все сказанное выше, в современных продуктовых командах нужен QA-инженер, который сможет совмещать в себе качества различных направлений, но при этом строить процессы так, чтобы все успевать и не выгорать.

Как внедрить Full Stack QA 

Шаг 1 — определить задачи Full Stack QA. Общие цели тестирования в крупных проектах давно должны быть высечены где-то на скале:

• уменьшение времени на регрессионное тестирование и Lead Time;

• постоянная разработка и оптимизация тестовых фреймворков;

• улучшение качества приложения и самих процессов разработки ПО.

Из общих целей мы сформировали задачи Full Stack QA:

• работа в команде для обеспечения качества и улучшения пользовательского кайфа — путь QA;

• создание тестовых артефактов и работа с ними — путь тестирования;

• автоматизация тестов по пирамиде тестирования — путь автоматизации.

Я рассказываю об общем векторе развития QA в компании, в направлениях Backend/Web/Mobile будут свои особенности и тонкости. Например, для направления Backend нужны знания и скиллы по основам нагрузочного тестирования.

Постановка задач — дело важное и полезное, но это лишь начало. Дело за «малым» — это все внедрить.

Шаг 2 — внедрить Full Stack QA в компании. В начале внедрения у нас было много специалистов по ручному тестированию без опыта программирования, не говоря уже об автоматизации.

Внедрение изменений разделилось на три четкие зоны:

1. Работа с текущими сотрудниками.

2. Наем новых.

3. Изменение образовательных программ в учебном центре.

Мы доработали матрицу компетенций профессии QA, чтобы понять, как соотнести специалистов внутри компании между собой:

Задачи — выполнение рабочих активностей в рамках проекта или продукта.

Работа в команде — то, как QA влияет на процессы своей команды.

Харды — техническое развитие как инженера с учетом профиля (Backend/Web/Mobile).

Чтобы прокачиваться по необходимым и полезным скиллам, наши специалисты могут:

• учиться на корпоративном портале: существуют готовые записи и вебинары, полноценные внутренние курсы с ручной проверкой ДЗ кураторами;

• учиться на внешних ресурсах, когда руководитель согласует курс и компания его оплачивает;

• участвовать во внутренних воркшопах от держателей профессий или команд разработки;

• быть ментором или наставником от соответствующего направления.

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

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

В QA-направлении есть три обязательных собеседования: экспертная область — Web/Mobile/Backend, теория тестирования и секция лайв-кодинга. Для последней нам не важен язык программирования — например, за последние пару месяцев кандидаты решали задачи на Java, Kotlin, Swift, Go, Python, C#.

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

Шаг 4 — обновить образовательные курсы. Одно из важнейших направлений для компании — приток молодой и свежей крови начинающих инженеров. Кроме работы с вузами по программе стажировок у нас есть свой учебный подготовительный центр — Финтех Школа, где мы растим будущее пополнение.

Отбор на курсы по направлению QA включает решение задач по программированию. Программирование — часть любого курса, например Java для бэкенда, Kotlin/Swift для мобайла. С самого начала мы закладываем ребятам фокус на техническое развитие, чтобы адаптация в наших командах проходила как можно проще. Для тех, кто успешно пройдет курс, есть свой четко прописанный путь выхода в инженеры.

Как прошло внедрение в команде

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

Для нас автоматизация играет ключевую роль. Мы используем нативные фреймворки автоматизации мобильных приложений на языках Kotlin и Swift. Все цифры будут касаться именно их.

У нас более 50 продуктовых команд, среди которых собирали статистику — опросили больше 70 человек из команды QA.

Команда — главная образующая ячейка любого ИТ-продукта. Большая часть опрошенных выбрала обучение в команде:

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

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

Вот такие данные получились по командам мобильного приложения:

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

Какие выводы

 За последние несколько лет я заметил несколько трендов в области QA:

• растет уклон в автоматизацию — как для сохранения времени, так и для экономии бюджетов проекта;

• нужно понимать концепции CI/CD с погружением в некоторые инфраструктурные задачи на базовом уровне.

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

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