Как создать пирамиду из мороженки, если надежды нет

Для организации разработки и тестирования сегодня принято выстраивать пирамиду тестов, это считается мейнстримом. Существуют десятки, если не сотни, вариаций пирамиды, опубликовано много докладов и статей о том, как она должна выглядеть. И почти все эти материалы помогут ответить на вопрос «Как мне построить пирамиду тестирования в новом проекте?».

Но что делать, если вы приходите в проект, в котором исторически применялся подход «мороженки» тестирования, когда основную часть проверок закрывали ручным тестированием? При этом компания проходит трансформацию, и от вас ждут, что вы приведёте процессы в соответствие современным практикам и ускорите их?

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

Пирамида тестирования

Для начала кратко расскажу, что такое пирамида тестирования и для чего она нужна. Теории я коснусь только вскользь, потому что на эту тему написано достаточно материалов.

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

Ключевые утверждения, которые справедливы для пирамиды.

• Наибольший объем тестов должен быть сконцентрирован на нижних уровнях.

• Чем выше поднимаемся по пирамиде, тем дороже и медленнее будут тесты.

• Тяжелых Е2Е-тестов должно быть минимальное количество.

• В построении пирамиды должны участвовать и разработчики, и тестировщики.

 Пример пирамиды, которую мы хотим у себя видеть:

Исходные данные

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

 Летом 2021 года у нас было:

• огромный монолит, которому уже больше 10 лет. Активно распиливается на микросервисы;

• микросервисы для новой функциональности и выпиленные части монолита;

• 5 ручных тестировщиков, которые работали в четырех смежных проектах;

• 30 разработчиков;

• отсутствие автоматизации тестирования;

• почти полное отсутствие юнит-тестов для монолита и микросервисов;

• нехватка ресурсов.

 То есть, ситуация выглядела так:

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

Первые шаги к светлому будущему

Первые шаги по превращению мороженки в пирамиду были такими.

• Сосредоточиться на найме дополнительных тестировщиков в команду.

• Начать выстраивать автоматизацию.

• Договориться с разработчиками по развитию юнит-тестирования.

С наймом тестировщиков больших проблем не было, а вот над двумя другими пунктами пришлось поломать голову.

Юнит-тестирование для начинающих

С юнит-тестами ситуация обстояла так.

• Для монолита тесты отсутствовали.

• Для новых сервисов тесты писали, но мало. При этом у разработчиков не было общего подхода к написанию тестов и выработанных стандартов тестов.

• Не было возможности автоматически измерять покрытие юнит-тестами.

• На написание юнит-тестов нужны были дополнительные ресурсы разработки.

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

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

Основной проблемой стал вопрос, где найти ресурсы на написание тестов. Нельзя же просто так увеличить время разработки на 20–30 %, бизнес не пойдет на это. К решению  мы подошли с точки зрения общего количества ресурсов, которое требуется на вывод проекта в эксплуатацию. Отсутствие юнит-тестов приводит к тому, что большинство багов мы пропускаем на стадии разработки. Эти баги в дальнейшем съедают ресурсы тестировщиков, девопсов, поддержки, бизнеса и пользователей. Поэтому, если мы будем тратить ресурсы на написание тестов, то на более поздних этапах мы их будем экономить. Идею поддержали, в том числе, разработчики, поэтому мы продвинулись в этой истории.

Также мы запустили серию митапов по юнит-тестам, чтобы выровнять навыки всех разработчиков по подходу написания тестов. И к концу 2022 года планируем добиться покрытия нового кода юнит-тестами на 80%.

Автоматизация

Проблемы

Основные проблемные зоны в выстраивании автоматизации были такими.

• Нужна была команда автоматизаторов, желательно с лидом.

• Отсутствовал план работ. Существующие тестировщики занимались срочными задачами, им было не до тестовой документации.

• Первое время все попытки автоматизации не приносили и видимого результата.

Найм

Я начал с поиска лида по автоматизации. Стэк был выбран близкий к разработке: Java. Удалось за несколько месяцев найти лида (привет, Саша :)). Вместе с ним определились, что первое время автоматизаторы, которых наймем, будут работать в одной платформенной команде, чтобы они находились на одной волне: вырабатывали общие практики, проверяли код друг друга и были знакомы со всеми частями приложения.

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

Уровни пирамиды

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

Для начала стали собирать smoke-набор со всех команд, который в дальнейшем объединили в общий smoke нашего любимого монолита. Поскольку это монолит, то уровень интеграционных и API тестов для нас ограничен, поэтому мы преимущественно написали UI-автотесты. Там, где это возможно, для функциональности микросервисов наибольшую часть smoke покрыли API-тестами, а оставшаяся часть пошла на UI-тесты.

Теперь поясню, что я имею в виду под интеграционными тестами. Это тесты, которые проверяют конкретную интеграцию сервиса с одной внешней зависимостью (в крайнем случае, с несколькими). Все остальные зависимости мокаются. Из-за глубокой связанности кода внутри монолита и микросервисов (правильней будет назвать их микромонолитами) уровень интеграционных тестов в пирамиде нам дается сложнее всего. Здесь нам начинают помогать разработчики, которые вместе с юнит-тестами первое время будут брать на себя и интеграционные тесты. В дальнейшем команда тестирования также будет подключаться к написанию интеграционных тестов.

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

Где мы находимся сейчас и дальнейшие планы 

Текущую ситуацию можно изобразить так:

Юнит-тесты

Мы включили quality gate в нашем CI для всех наших сервисов. Активно начали покрывать новый код юнит-тестами. До конца первого квартала 2022 планируем довести покрытие нового кода юнит-тестами до 25 %. А к концу года, как говорил выше, планируем довести до 80 %. Также мы уже провели первый внутренний митап по модульному тестированию, который понравился аудитории.

Автотесты

У нас уже автоматизирован smoke половины команд, который преимущественно состоит из API- и UI-тестов. Критичную новую функциональность также автоматизируем. К концу первого квартала у нас будет автоматизирован smoke всех команд, и мы начнем подступаться к почти неподъемному регрессу!

Впереди у нас еще много работы по выстраиванию пирамиды. Нужно начать автоматизировать менее критичную функциональность, расширить покрытие регрессионными тестами, довести покрытие юнит-тестами до планируемых значений. Но мы уже сейчас начинаем извлекать пользу из всех этих активностей: сокращаем наш TTM (time to market) без потери в качестве.

Lessons learned

Когда ты смотришь на все эти привлекательные картинки разных пирамид тестирования, то кажется, что вот оно — мы нашли то, что нам нужно. Выглядит всё логично, складно. Ты закатываешь рукава и говоришь себе: «Давайте сделаем это!» А потом ты сталкиваешься с суровой реальностью. Например, юнит-тесты, это, конечно, круто, но кто их будет писать для legacy-монолита, в котором полмиллиона строк кода? А как быть с API-тестами? Можно всё покрыть UI-тестами, но тогда у нас мороженка превратится в автоматизированную мороженку, что имеет право на жизнь, но совершенно не то, что нам хотелось бы получить после изучения best practices. Тебя мало кто поддерживает, часто людям просто не до тебя. А твой опыт постройки пирамиды с нуля лишь отчасти поможет в перестраивании мороженки.

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

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

Послесловие

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

У каждой компании, проекта и команды будут свои уникальные проблемы при попытке выстраивания пирамиды тестирования. Главное, чтобы в ней были люди, которые не готовы мириться с текущим положением дел. Начать этот путь можно даже в одиночку. Если ваше дело правое, то у вас быстро появятся сторонники. Всем благ!