В эпоху вселенского внедрения agile-методологий и Devops уже никто не сомневается в том, что регрессия должна быть автоматизирована. Особенно, если в компании идет речь о Continuous Delivery. Все кинулись хантить разработчиков автотестов, от чего рынок становится перегретым.

В этой статье я расскажу о том, что на самом деле разработчик автотестов — не такая уж и важная роль в команде. Они не нужны, особенно если вы внедряете у себя scrum. И все эти agile-ы и devops-ы можно внедрять и без этих людей. Так что если кто-нибудь вам скажет, что у них в команде все тестируют руками — потому что у них по каким-либо причинам нет разработчика автотестов — не верьте им. Они тестируют руками, потому что по-другому им лень. Или не умеют.

Проблема отдельной команды разработчиков автотестов

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

Есть некий:

• отдел/команда разработки;
• отдел/команда тестирования;
• отдел/команда аналитиков;

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

И для управления этими функциональными колодцами, как правило, нужен Руководитель проектов. При этом наш процесс тестирования выглядел следующим образом:

1. Команде тестировщиков на вход поступал некий артефакт от команды разработки. Ребята проводили функциональное тестирование. Запускали при этом автоматическую регрессию, если она была разработана для этого продукта. И большую часть кейсов тестировали вручную.
2. Затем этот артефакт деплоился на прод. Туда, куда уже ходят клиенты.
3. И только после этого заводились задачи в jira для команды автотестеров (здесь и далее я так буду называть разработчиков автотестов).
4. Реализация поставленных задач происходила с задержкой от 1 до 4х итераций.

И как правило, автоматизация тестирования достигалась за счет совместного труда тестировщика и разработчика автотестов. Где один/одни придумывает тест-кейсы и тестирует приложение руками, а вторые – эти самые тест-кейсы автоматизирует. И их взаимодействие координируют РП и еще армия менеджеров. Всякие там Test manager и Test lead-ы.

Я не буду рассказывать, “что не так с функциональными колодцами”. С ними все не так. Хотя бы потому, что каждый отдел производит «артефакты-загадки», являющиеся частью будущей фичи/продукта. А тимлидам и PM-ам всегда нужно держать руку на пульсе в этом процессе. Передавать артефакт-загадку другому отделу, следить, чтобы отделы коммуницировали друг с другом и т.д.

Поэтому отдельно останавливаться на этом не будем.

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

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

Несмотря на то, что наш процесс тестирования изменился и стал выглядеть следующим образом:

1. Тестировщику в команде приходит артефакт, являющийся маленькой частью user story.
2. Он осуществляет приемочное тестирование и запускает автоматическую регрессию.
3. Если регрессия не полностью автоматизирована, то часть регрессии тестирует вручную.
4. Затем артефакт деплоится на прод. А тестировщик передает задачу автотестерам на автоматизацию.

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

Давайте подытожим, какие вопросы у нас остались открытыми при наличии отдельной команды автотестеров.

Проблемы выделенной команды автотестеров

1. Отсутствует быстрая ценность от автотестов. Как правило, они разрабатывались с задержкой в 1 и более спринт. Потому что была очередь на эти самые автотесты. И ценность от них команда получала только в виде автоматизированной регрессии. И очень часто бывало что к тому моменту, когда автоматизируют фичу — команда ее уже переделает. И автотесты быстро становятся неактуальными.
2. Cтоимость продукта вырастала. Это следствие 1го пункта. За счет того, что ручное тестирование уменьшалось со значительной задержкой, команде приходилось тратить деньги на автоматизацию тестирования с надежной на их отложенную ценность. Не говоря уже о том, что наличие прокси-менеджмента увеличивало петлю обратной связи, а это тоже увеличивало стоимость продукта.
3. Отсутствовала прозрачность в процессе тестирования. Никто в командах не знал, чем автотестеры занимаются. Не понимал их загруженность и по какому принципу они распределяли приоритеты.
4. Автотестеры — "купленные" люди (аутсорс). А в этом случае SM или PO считали, что это «приходящие» люди. И они не должны быть частью команды. Да и сами ребята не особо то и стремились становиться частью команды, ведь где гарантия, что их работодатель "не перекинет" их в очередной раз на другой проект?
5. Бизнес не понимал, почему он должен платить в надежде на долгосрочный эффект.

И теперь внимание — что делать РП/SM, у которого PO не заложил деньги на автоматизацию? Или продукт уже месяца 3 разрабатывается, а разработчика автотестов под их продукт все никак найти не могут? Или в команде автотестеров нехватка людей, кто-то ушел в отпуск/заболел? Забыть про автоматизацию и да здравствует ручная регрессия по 2 недели? Или ждать, когда появится нужное количество людей? И при этом нести финансовые потери от несвоевременного запуска продукта, или же наоборот, от того, что продукт выпустили в «забагованном» состоянии?

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

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

Как тестировщики сотрудничают с автотестерами

• Тестировщики являются заказчиками для разработчиков автотестов.
• Команда автотестеров — сервисная команда для продуктовых команд. И у такой команды есть свой тимлид, который проксирует запросы от тестировщиков автотестерам. В худшем случае, у тестировщиков тоже есть свой тимлид, который проксирует запросы тестировщиков тимлиду разработчиков автотестов. И на деле у нас получается сломанный телефон, длинная петля обратной связи. И почти нулевая эффективность. Обычно при такой оргструктуре люди выступают на конференциях с темами про то, что автоматизация тестирования это долго и дорого, и что тестировать только «руками» не стыдно.
• И даже если с коммуникацией не все так плохо, можно поймать другие проблемы в стиле: разработчик(и) в конкретный момент времени заняты другими проектами и не могут здесь и сейчас ответить на запросы тестировщика.
• Тестировщики не доверяют автотестам. И повторяют автоматизированные сьюиты — вручную.

Как разработчики "сотрудничают" с автотестерами

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

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

• Дублирование инструментов/фреймворков автоматизации из-за отсутствия коммуникации с разработчиками.
• Часто решаются одни и те же проблемы разными инструментами. Например, для тестирования необходимо вытаскивать логи из Elasticsearch. У разработчиков уже, к примеру, есть своя написанная библиотека для этой задачи, но вместо того, чтобы переиспользовать и развивать существующий инструмент, автотестеры как правило пишут свое, либо найдут новый инструмент для этого.
• Автотестеры используют инструменты, которые по каким-то причинам разработчики могут потом отказаться поддерживать или развивать. Например, у нас разработчики использовали maven в качестве сборщика проектов. И когда встала задача интеграции автоматизации тестирования в процесс разработки — пришлось отказаться от старого фреймворка совсем. Так как перевести его на gradle оказалось сложнее, чем написать новый. А использовать maven разработчики не могли, так как вся инфраструктура и окружение у нас уже были “заточены” под gradle.

Как менеджмент "сотрудничает" с автотестерами

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

• Что мы получаем от автоматизации тестирования?
• Сколько она стоит продукту?
• Учитывая стоимость, достаточно ли мы выигрываем от автоматизации тестирования?
• Что плохого может произойти, если будет приостановлено финансирование автоматизации?
• Какова стоимость технической поддержки написанных автотестов?

В итоге, вот основные фейлы автоматизации тестирования, когда ее делают выделенные автотестеры:

1. Непрозрачность количества автоматизированного тестового покрытия
2. Разрабатываем то, что не используется при тестировании продукта. Например, написали или автоматизировали тест-кейсы, которые не включили в запуск регрессионного сьюита. Соответственно, такие автотесты не приносят ценности.
3. Не анализируем результаты тестирования: разработали --> запустили --> не проанализировали результаты. А потом спустя время команда обнаруживает "развалившиеся" автотесты из-за того, что тестовые данные сильно устарели. Это в лучше случае.
4. Нестабильные тест-кейсы: постоянно тратим много денег на стабилизацию тест-кейсов. Это проблема отсутствия погружения в контекст приложения, которое пытаемся автоматически тестировать.

Поиск решения проблемы

Попытка #1: На команду выделен 1 тестировщик и 1 автотестер

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

1. Теперь, когда артефакт приходил на тестирование, тестировщик делал приемку.
2. Затем тесты на этот артефакт сразу же автоматизируются.
3. Таким образом вся наша регрессия — автоматизирована.
4. И артефакт деплоится на прод с уже реализованными автотестами.

Казалось бы, все идеально. Но спустя пару спринтов обнаружилось следующее:

• Продукт/проект не генерировал соответствующую нагрузку на автотестера. Это несмотря на большое количество встреч, которые присутствовали у команды. И на которые в среднем в недельном спринте тратилось около 10 часов.
• При этом автотестер отказывается заниматься функциональным тестированием, если попытаться оставить его одного в команде.
• Но и тестировщик не настолько компетентен, чтобы писать автотесты самостоятельно.
• Когда же предложили писать сервисы для приложения разработчику автотестов — он отказался, так как его навыков не хватало. И как ни странно, не все автотестеры заинтересованы в развитии себя как разработчика.

Попытка #2: Разработчик автотестов является частью 2-3 команд

Тогда я подумала, что если автотестер занят примерно на 50 %, то, может, попытаться "шарить" его на 2 команды? И вот что у нас получилось:

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

И при этом отказаться от этих встреч он также не мог, так как терял контекст разрабатываемого приложения, и автоматизация становилась менее эффективной.

Попытка #3 или Успешная попытка: Научить тестировщиков писать автотесты

Тогда пришла в голову гипотеза, что если мы обучим тестировщиков самостоятельно разрабатывать автотесты — то пофиксим все наши боли. Итак, с чем мы начали?

1. Для начала мы выстроили правильную пирамиду тестирования. Согласно ей, наша тестовая стратегия заключалась в том, чтобы тесты были на разных слоях приложения. И между каждыми слоями должны быть интеграционные тесты. И руками тестироваться должны только приемочные тесты. При этом сразу после приемки — они автоматизируются. То есть в следующую итерацию тестировщик снова тестирует ТОЛЬКО изменение.
   
2. “Размазали” процесс автоматизации тестирования по команде. Так как тесты были разные, то и разрабатывали их разные члены команды. Тесты на api разрабатывались разработчиком api. Фронт-разработчик покрывал свои UI-компоненты тестами. Тестировщик должен быть запроектировать тестовую модель и реализовать интеграционные тесты, которые исполнялись со стороны браузера (selenium тесты).
3. Использовали простые инструменты для автоматизации тестирования. Мы решили не усложнять себе жизнь и выбрали наиболее простую обертку над selenium-ом. На текущий момент — это selenide, если ваши автотесты пишутся на java.
4. Создали инструмент для написания автотестов непрограммистами. Об этом бибиотеке (Akita BDD) уже была написана статья в нашем блоге https://habrahabr.ru/company/alfa/blog/350238/. И благодаря тому, что мы используем BDD, смогли вовлечь аналитиков в написание автотестов. Кстати, библиотека в open source: https://github.com/alfa-laboratory/akita и https://github.com/alfa-laboratory/akita-testing-template
5. Научили тестировщиков чуть-чуть программировать. Среднее время обучения занимало от 2 недель до 2 месяцев.

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

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

Быстро решается проблема устаревших автотестов. Когда продукт быстро развивается, наличие доп. человека отвечающего за автоматизацию генерит для него много бессмысленной работы. Потому что пока он сегодня автоматизирует по прототипам какой-то новый набор тест-кейсов, дизайнер с PO могут принимать решение о том, что логика полностью будет другая. И получается, что на следующий день ему снова надо переделывать свои тесты. Только находясь всегда внутри команды, можно “держать руку на пульсе” и понимать, какие тесты имеет смысл автоматизировать уже сейчас, а с какими имеет смысл повременить.

При этом само ядро библиотеки поддерживается самими тестировщиками. Только более заинтересованными в этом. Которым стало интересно писать код и они контрибьютят akita-bdd. Как правило все новые фишки и шаги появляются из других команд, которые что-то попробовали внутри себя и решили поделиться, делая пулл-реквест в библиотеку. Все общение происходит в коммьюнити внутри банковского слака, где ребята и выясняют потребность в том или ином шаге, и после это шарят его.

А не пострадает ли качество тестов

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

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

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

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

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

И все инновации, как правило, происходили именно в контексте команды. И наличие их разнообразного опыта в миксе способствовало лучшему пониманию и лучшим решениям.

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

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

Рассмотрим на конкретном примере: когда наш фронт-разработчик начал пробовать писать автотесты, и познал боль написания xpath-запросов до различных ui-компонент на странице — то предложил в момент верстки страницы создавать уникальные css class name для удобного поиска элемента на странице. Таким образом мы смогли стабилизировать тесты и ускорить их написание за счет упрощения поиска этих элементов. А у фронт-разработчика просто появилось новое правило в работе — которое не осложняло его рабочий процесс ни на йоту

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

Выводы

• Наличие выделенной команды автотестеров — это не agile.
• Наличие выделенных разработчиков автотестов — это дорого для продукта/команды
• Поиск/хантинг таких людей дорог и долог. И это тормозит развитие продукта
• Разработка автотестов значительно отстает от разработки продукта. В итоге мы получаем не максимальное велью от автоматизации тестирования.

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

• Тестировщик тоже инженер. И покуда команда к нему не начнет относиться как к инженеру, у того не возникнет мотивации развиваться или учиться программировать.
• Команда тоже отвечает за качество. Не тестировщик, на которого в случае чего повесят всю ответственность за качество продукта. А вся команда. Включая заказчика (PO).
• Автотесты тоже часть продукта. Покуда вы будете думать, что автотесты — это продукт для другого продукта, так и будут закрываться спринты без написанных автотестов. А автотесты будут вашим техдолгом, который как правило не закрывается. Важно понимать, что автотесты — это то, что гарантирует качество вашего продукта.

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

p.s. Если вам интересен мой опыт, то приглашаю в свой блог (http://travieso.me). Там опубликованы все мои выступления, статьи, лекции и заметки.

Автор: Travieso

Источник