Привет, это Эрик Бурыгин, я техлид курса «Автоматизатор тестирования на Java» в Яндекс.Практикуме и лид в Яндексе. Каждый ручной тестировщик считает, что автоматизация — это круто и её непременно нужно втащить в проект. Что может быть лучше, чем полное покрытие автотестами продукта, когда тесты гоняются 24/7 и отлавливают баги? Вот прочитал я эти строки, и захотелось ещё раз всё заавтоматизировать!



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

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

Поймите, что автоматизировать в первую очередь

Для начала нужно чётко определиться с тем, что автоматизировать в первую очередь!

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

Давайте разберём все подводные камни такого пути на примере нашего проекта и пройдём путь ошибок и побед с самого начала.

«По просьбе выживших имена персонажей были изменены. Из уважения к погибшим всё показано так, как было на самом деле».

Итак, мы делаем приложение по продаже кастомных байков Custom Bike для платформ iOS и Android. Полный регресс приложения — это 2500+ кейсов на платформу и примерно несколько недель человеко-часов. Для написания тест-кейсов мы используем Testpalm от Яндекса. Релизимся часто. Но как бы мы не стремились ускорить процесс выкладки, регрессы оставались узким местом. Тестировщики утопали в них, теряя всякую мотивацию. Конечно, можно было нарастить команду, но это путь вникуда, так как новые фичи выкатываются каждый релиз и регресс становится всё необъятнее.

Вот мы и решили втащить в проект автоматизацию и, как вы наверное догадались, начали с регресса, а именно — с регресса Android-приложения. Благо культура автоматизации тестирования в команде была на высоком уровне — на тот момент мы очень преуспели в автоматизации веба и API. Но как всегда, без ложки дёгтя не обошлось — наша экспертиза в автоматизации мобилок была близка к нулю, а изучать новое было проблематично, ибо задач и так хватало. Как сейчас помню фразу: «Чтобы автоматизировать Android, нужно становиться Android-разработчиком».

Однако нашлись энтузиасты, которые готовы были пробовать. Мы начали поднимать проект на Expresso, прикрутили Robot Pattern — и в путь! Мы занимались автоматизацией всё свободное время, так как рабочее было занято текущими задачами. Автоматизировали ночами дома, в барах, ресторанах и на пикниках. Так за месяц мы преодолели барьер в 30%, а через полгода вышли на 70% регресса. Круто — скажете вы. Да, круто. Однако нужно понимать, что больше ничем мы в своё свободное время не занимались, а со временем каждый процент регресса давался всё сложнее. Кейсы создавались постоянно, появлялись моменты, к которым просто так не подойти, к тому же нужно было качать инфраструктуру. Тесты начинали флакать, мы упирались в лимит ресурсов и технологий… Путь был неплох, но скажу честно — не у всех есть такой запал и временной ресурс.

Профит был, но мы всё равно не могли релизиться так часто, как хотели, а именно — выпускать релизы на каждой платформе раз в неделю. Начали думать и решили внедрить практику «смелых, до первой сломанной судьбы» — в каждом релизе пробегать не весь регресс, а проверять только места, где были изменения. Так у нас появились кастомные смоуки. В них входили дефолтные и критичные кейсы для приложения, а также кейсы на новые фичи и всё, что гипотетически могло быть затронуто. Этот подход хорош, но требует определённой экспертизы, потому что нужно обладать глубоким пониманием приложения и платформы и, конечно, уверенностью, что не выстрелит где-нибудь в неожиданном месте.

Кастомные смоуки дали хороший результат и сократили прохождение предрелизных кейсов до двух человеко-дней. Вы спросите: а как же 70% автоматизации? Дело в том, что смоук постоянно менялся, и не всегда тест-кейсы попадали в то, что уже было автоматизировано. К тому же автоматизация iOS находилась в зачаточном состоянии. При этом автотесты давали нехилую защиту от ошибок — перейдя на новый подход, некоторые из проверок мы стали делать очень редко.

Как понять, что автоматизировать

Мы не остановились на достигнутом и стали думать дальше: как быть ещё более эффективными, ускорить процесс и не потерять в качестве. После анализа смоуков и регрессов за несколько месяцев поняли, что некоторые кейсы повторяются чаще, а некоторые встречаются по одному разу. Один раз собрать статистику и всё посчитать используя, например, Excel — не проблема. Но делать это каждый раз и поддерживать актуальность достаточно трудозатратно. Мы решили автоматизировать сбор статистики.

Testpalm позволяет без проблем выгрузить весь пул кейсов, что у нас есть.
Это можно сделать с помощью Python и библиотеки Requests. Пример:

requests.get('http://testpalm.ru/testcases/custombike')

Список кейсов получен, но нам нужна статистика, а пока мало что можно посчитать. Чтобы посчитать статистику, нужны маркеры. Testpalm отлично с этим справляется — там есть теги, поэтому мы начали при каждом сборе смоука добавлять тег-версию релиза: Android_4.11, Android_4.12, Android_4.13 и т. д. Это позволило нехитрым способом сосчитать, сколько раз каждый кейс был задействован в смоуках из выгруженного джейсона. Пример:

count = (" ".join(item.get("attributes").get(attribute_version))).lower().count(platform)

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

print(item["link"] + " " + item["name"] + " {}".format(item["count"]))

Пример получившегося списка:

https://testpalm.ru/testcase/custombike-994 Диплинки facebook 8
https://testpalm.ru/testcase/custombike-1534 Реклама в листинге 8
https://testpalm.ru/testcase/custombike-266 Карточка мото 7
https://testpalm.ru/testcase/custombike-607 Геосаджест 7
https://testpalm.ru/testcase/custombike-1286 Опция турбо 7
https://testpalm.ru/testcase/custombike-1564 Опция продвижение  7
https://testpalm.ru/testcase/custombike-1922 Опция поднятие 7
https://testpalm.ru/testcase/custombike-567 Реклама в карточке мото 6
https://testpalm.ru/testcase/custombike-663 Пожаловаться в карточке мото 6
https://testpalm.ru/testcase/custombike-924 Диплинки на выдачу 5
https://testpalm.ru/testcase/custombike-946 Смена региона 5

Теперь точно понятно! Но чтобы всё было по красоте, осталось обернуть полученные данные в табличку. Для хранения документации мы используем вики, и всё, что нужно было сделать — добавить вики-разметку в выводимый результат. Пример кода:

print("#|")
print("|| Ссылка на пальму  | Название кейса| Количество проходов ||")
for item in cases_list:
   print("|| " + item["link"] + " | " + item["name"] + " | {}".format(item["count"]) + " ||")
print("|#")

Так мы получили красивую легкочитаемую табличку.


В вёрстке таблица будет выглядеть так:
Теперь понятно, с чего начинать автоматизацию, и актуальная статистика всегда будет под рукой. Круто! Но по мере автоматизации мы столкнулись с тем, что в статистику попадают кейсы, которые уже автоматизированы, или те, которые, наоборот, по какой-то причине нет смысла автоматизировать. Решение проблемы было простым — мы добавили ещё два тега:

• automation — для кейсов, которые уже автоматизированы,
• without_automation — для кейсов, которые мы не хотим автоматизировать.

Их мы исключили из статистики. Пример кода:

# Проверяем, есть ли автотесты для данного кейса
if attributes_automation in item['attributes']:
   # Проверяем, есть ли автотесты для данной платформы
   if platform in " ".join(item['attributes'][attributes_automation]).lower(): continue


# Проверяем, есть ли ключ "without_automation" для данного кейса
if attributes_without_automation in item['attributes']:
   # Проверяем, есть ли ключ "without_automation" для данной платформы
   if platform in " ".join(item['attributes'][attributes_without_automation]).lower(): continue

Теперь табличка стала чище, и в ней остались только те кейсы, на которые нужно обратить внимание и завести задачи на автоматизацию. Для удобства добавили ещё один столбец — «Задача на автоматизацию». Пример кода:

print("#|")
print("|| Ссылка на пальму  | Название кейса | Количество проходов  | Задача на автоматизацию ||")
for item in cases_list:
   print("|| " + item["link"] + " | " + item["name"] + " | {}".format(item["count"]) + " |" + " ||")
print("|#")

Пример таблички в вёрстке:
Так как у нас помимо приложения Custom Bike есть и другие проекты, каждый из которых поддерживает iOS и Android, нужно было сделать скрипт формирования статистики более гибким. Мы ещё немного доработали код, и теперь при запуске скрипта можно передавать в него проект и платформу, получая статистику для нужного приложения. Пример запуска скрипта:

python3 get_statistics.py custombike android

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

python3 get_statistics.py custombike android -m=6

Пример таблички:
Вот теперь всё стало по красоте!

Заключение

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

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

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