Привет! На связи Антон Тарасов, руководитель группы тестирования мобильного приложения Тинькофф. В течение последних десяти лет я был инженером и руководителем в направлениях 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 в компании. В начале внедрения у нас было много специалистов по ручному тестированию без опыта программирования, не говоря уже об автоматизации.
Внедрение изменений разделилось на три четкие зоны:
Работа с текущими сотрудниками.
Наем новых.
Изменение образовательных программ в учебном центре.
Мы доработали матрицу компетенций профессии QA, чтобы понять, как соотнести специалистов внутри компании между собой:
| Junior | Middle | Senior | Lead |
Задачи | Выполнение задач под контролем наставника | Самостоятельная работа | Внедрение улучшений в процессы | Решение задач любого уровня |
Работа в команде | ||||
Харды |
Задачи — выполнение рабочих активностей в рамках проекта или продукта.
Работа в команде — то, как 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-инженеры должны тратить на задачи по автоматизации минимум пять часов в неделю. Правило согласовано с бизнесом и учитывается при планировании. А активности по автоматизации включают не только написание тестов, но и обучение.
Вот такие данные получились по командам мобильного приложения:
Часы в неделю | Процент |
t ⩽ 5 | 68 |
5 < t ⩽ 10 | 24 |
t > 10 | 8 |
В некоторых спринтах инженеры не успевают заниматься техническим развитием и писать автотесты. Поэтому мы со стороны платформы постоянно собираем метрики по автоматизации и стараемся ставить четкие и понятные цели закрытия долга по автоматизации.
Какие выводы
За последние несколько лет я заметил несколько трендов в области QA:
растет уклон в автоматизацию — как для сохранения времени, так и для экономии бюджетов проекта;
нужно понимать концепции CI/CD с погружением в некоторые инфраструктурные задачи на базовом уровне.
Я думаю, в ближайшее время QA-инженер будет все чаще становиться прямым помощником разработчика. Это приведет к раннему написанию тестов и автоматизации почти всех фич сразу на необходимом уровне.
Вывод: основы алгоритмического программирования и понимание базовых структур и функций — необходимый скилл для QA-инженера. А значит, да — QA должен уметь писать код :)