Апр. 07

Как автоматизировать тестирование на проекте, где по 100 релизов в месяц

Автоматизация или ручное тестирование — один из неразрешимых холиваров в среде тестировщиков. Я QA-менеджер в Parimatch Tech и адепт автоматизации. В своей команде стремлюсь к тому, чтобы вообще отказаться от мануального тестирования. В колонке расскажу о том, почему это выгодно, почему многие до сих пор (зря) боятся автотестов, и об опыте внедрения такого подхода в стриме «Спорт».

Перед нами как командой разработки стоят серьезные задачи. Требуется высокое качество, чтобы мы работали постоянно и стабильно. Мы должны обеспечивать аптайм в 99,99%. При этом компания работает в сфере высокой конкуренции. На этом рынке побеждают те, кто может постоянно предоставлять пользователям новые фичи, которые стабильно работают.

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

С помощью автоматизированного тестирования мы можем обеспечивать скорость. То есть за 10–15 минут узнавать, что наш сервис как минимум работает так же, как работал раньше. Такой скорости невозможно достичь с помощью ручного тестирования.

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

Иллюстрация Алины Самолюк

Как правильно автоматизировать тесты

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

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

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

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

Что нужно поменять в команде, чтобы внедрить автотесты

Внедрение автоматизации я всегда начинаю с малого. Сначала выбираю небольшой компонент (обычно он либо только начинает писаться, либо недавно появился). Для него делаю MVP, который состоит из нескольких тестов. Он сразу внедряется в CI, и я показываю его команде. Если решение нравится, мы договариваемся, что эти тесты должны быть всегда зелёными и вся новая функциональность в этом сервисе должна автоматизироваться на потоке.

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

Если ты разобрался с продуктом и его спецификой, первые локальные тесты можно получить через пару дней. А иногда в этот же день. Работающий MVP будет спустя 2–3 дня, максимум неделю. Потому меня удивляет, когда говорят, что нужно написать некий «тестовый фреймворк» и это займет месяцы.

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

2. Нужно поменять процесс разработки. Обычно это происходит таким образом. Команда получает задачу, потом ее собирает, оценивает и начинает делать. После окончания результат отдается тестировщикам. После удачного тестирования задача идет на автоматизацию. Там другая команда с опозданием в 1–2 спринта автоматизирует ее. К тому моменту мы уже не знаем, менялась ли эта фича. Соответственно и автотесты могут быть уже нерелевантными.

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

Это не значит, что только тестировщики должны писать тесты. Если мы живем в мире Agile и Scrum, то понимаем, что это задача команды. Поэтому если кто-то из участников обладает нужными навыками и у него есть под это свободное время, то он это делает. Поэтому у нас разработчики тоже подключаются к написанию тестов.

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

Но этот план не всегда работает. Однажды я пришёл внедрять автоматизацию в компанию, которая еще не была к этому готова. Мы вроде договорились про смену процессов и подходов, реализовали тесты и внедрили их в пайплайн сервисов. Но всё равно они воспринимались скорее как тесты автоматизаторов, а не тесты команды. Большой поддержки от менеджмента не было, и тесты писались и запускались только на энтузиазме моей команды. А после моего ухода тесты перестали поддерживаться и умерли по ненадобности. Так как все привыкли тестировать руками.

Почему за автотестами будущее

При создании нового продукта даже три перепроверки функционала руками — это уже повод автоматизировать тестирование. А если это стоит на потоке, вложения в автоматизацию окупятся уже от 0,4 до 0,7 ручного прогона. То есть это уже дешевле, чем тестировать руками даже 1 раз.

Мы запускаем тесты на каждый коммит. Поскольку мы живем в микросервисной архитектуре, в течение дня может быть до 400–500 запусков. А такое количество ручных прогонов в день никто не мог бы себе позволить.

Так мы выработали определенные правила работы:

Без тестов мы не можем гарантировать стабильный мастер. Поэтому тесты становятся базовой частью функциональности.
Зеленые тесты — обязательное правило для мержа. Если хотя бы один тест Flaky, это признак того, что что-то не так. Тест не должен быть красным. Либо у нас баг, либо плохой тест, который сразу же нужно менять.

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

Понятно, что если просто взять и сделать фичу, это будет быстрее, чем сразу писать по ней тесты. Но, как показывает практика, потом мы все равно тратим много времени на тесты, переоткрытие багов и регрессии. Делая автотесты сразу, мы решаем проблему наперед.

К тому же, когда это стоит на потоке, написание нового теста отнимает все меньше времени.

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

Конечно же, есть исключения. Если это какой-то прототип, который мы, скорее всего, не будем развивать, то нет смысла делать тесты. С другой же стороны, если одну и ту же функциональность будут перепроверять больше чем 2–3 раза, то даже тогда это лучше сразу же автоматизировать.

Что делать с Manual-тестировщиками

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

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

Поэтому мы движемся к парадигме, когда у нас не будет специально выделенных Manual- или Automation-тестировщиков. Останутся только те, кого некоторые называют General-тестировщиками. Я называю их просто QA, которые обладают и навыками тестирования, и техническими навыками, чтобы автоматизировать самостоятельно.

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

Сейчас у нас 25 автоматизаторов и 12 ручных тестировщиков. Плюс уже треть Manual-тестировщиков изучает автоматизацию. Ещё около 7 открытых вакансий на автоматизаторов. Так что пропорцию мы скоро изменим.

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

Но это не значит, что мы собираемся разогнать всех мануальных тестировщиков. Я описываю идеальный флоу, к которому мы дошли во многих командах. Но еще не во всех. У меня сейчас 11 Scrum-команд. В каждой из них мы даем возможность Manual-тестировщикам обучаться и развиваться в сторону автоматизации.

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