QA в стартапе: как наладить процессы в команде тестирования?

Рассказывает Кирилл Малышев, QA Team Lead Master Dеlivery.
Я пришел в Master Delivery в феврале 2021 года и стал вторым in-house тестировщиком в компании. До этого тестированием занимались ребята на аутсорсе. С самого начала мы столкнулись с рядом сложностей: у нас не было продуктовой документации по проекту, тест-кейсы описывались просто наименованием, код заливался на одно окружение рабочими и нерабочими ветками. Не всегда было понятно, что конкретно оказалось в том или ином билде, поэтому частенько катили кучу багов. В общем, работы было много.

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

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

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

К команде QA присоединились 4 стажера, и мы начали готовиться к большому техническому апгрейду платформы. Стажеры в первое время занимались только регрессным тестированием по описанным кейсам в TestIt, сами писали тест-кейсы и изучали наш продукт в целом. В Master Delivery на тот момент было 3 продуктовых команды, каждой нужны были по 2 полноценных тестировщика, мы работали с 300% загрузкой и параллельно обучали стажеров, чтобы они как можно быстрее взяли на себя часть реальных задач. Сначала многим идея со стажерами казалась глупой, т.к. мы тратим драгоценное время на людей, которые не могут в ближайшее время дать значимый для компании результат. Но сейчас все максимально довольны ребятами, они уже большие и самостоятельные специалисты, чему я несказанно рад!

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

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

Потом с помощью наших DevOps создали командные dev-стенды. Мы перестали сливать все в одно окружение и убрали очередь на предпрод окружение. Следующей задачей была автоматизация. В команде уже был автоматизатор, он построил костяк автотестов. Сейчас покрывать регресс могут все, кто доросли по уровню знаний, это здорово экономит нам время. Мы прокачиваем навыки автоматизации у всего отдела сразу, проводим лекции 2 раза в неделю и выполняем домашние задания. По нашим планам довольно скоро каждый QA-специалист будет писать автотесты наравне с ручным приемочным тестированием, а регресс сведется к минимуму.

Процесс тестирования в Master Delivery сегодня выглядит так:

У каждой продуктовой команды есть свое окружение, на нем проводятся все тесты. Если в процессе есть миграции данных в базах, задачи сложных конфигураций – проверяем на pre-проде с обезличенными данными каждую конкретную задачу. Наши QA хорошо знают продукт, что на что влияет и как взаимодействует, поэтому необходимость регрессного тестирования QA определяют в зависимости от логики задачи. Если вносим большие изменения, можем протестировать и весь функционал.

В Master Delivery сейчас 5 продуктовых команд, поэтому релизы планируем и внутри своих команд, и между всеми командами. У нас бывают смежные задачи, мы всегда в курсе, у кого что происходит. Перед релизом заполняем epic-задачу с описанием всех процессов и задействованных сервисов, расписываем для каждого специалиста, кто что и когда делает в процессе релиза. Все релизы проводим рано утром, чтобы максимально оперативно реагировать на все вопросы и провести смоук тест. После вывода в продакшен, если все ОК, собираем и обрабатываем заявки из саппорта.

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

Ретро у нас проходит на нескольких уровнях:

Отдельно хочу сказать о стажерах, это наш золотой запас.
К нам приходят ребята сразу после обучения или даже во время. Сначала всего боятся: делать, пробовать, ошибаться, спрашивать. У каждого стажера есть ментор. Нам важно, чтобы все влились в комфортную рабочую атмосферу и знали, что команда поддержит. Тестирование — это коллективная работа, здесь нужно много общаться, уметь слушать и договариваться, помогать друг другу.

Основная сложность нашего проекта в том, что Master Delivery — это стартап, а значит, мы делаем вообще всё, причем сегодня — одно, завтра — другое. Мы в постоянном поиске лучших решений для нашего продукта, пробуем много нового и разного. В этом сложность, но в этом и драйв: некогда скучать на однообразных тестах, пригождается всё из того, что ты знаешь, умеешь или хотя бы где-то слышал. Всё быстро внедряется, релизы катим один за другим. Это большой кайф — видеть, как круто всё работает и как наш продукт реально помогает курьерам.