Rivalry2

HTML Diff

2 added 2 removed

Original 2026-01-01

Modified 2026-03-10

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

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

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

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

5 <p>Когда я только пришла, структура организации и процесс сильно напоминал нижеследующую, типичную для многих картину.</p>

6 <p>Есть некий:</p>

7 <ul><li>отдел/команда разработки;</li>

8 <li>отдел/команда тестирования;</li>

9 <li>отдел/команда аналитиков.</li>

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

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

12 <ol><li>Команде тестировщиков на вход поступал некий артефакт от команды разработки. Ребята проводили функциональное тестирование. Запускали при этом автоматическую регрессию, если она была разработана для этого продукта. И большую часть кейсов тестировали вручную.</li>

13 <li>Затем этот артефакт деплоился на прод. Туда, куда уже ходят клиенты.</li>

14 <li>И только после этого заводились задачи в jira для команды автотестеров (здесь и далее я так буду называть разработчиков автотестов).</li>

15 <li>Реализация поставленных задач происходила с задержкой от 1 до 4-х итераций.</li>

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

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

18 <p>Поэтому отдельно останавливаться на этом не будем.</p>

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

20 <ul><li>количества наших автотестеров не хватало для того, чтобы каждую команду обеспечить автоматизацией тестирования;</li>

21 <li>из-за наличия большого тех. долга, ребята не могли его "бросить" и сразу переключиться на то, что нужно было командам прямо сейчас;</li>

22 - <li>также присутствовали некоторые системы, автотесты на которые давно-давно были разработаны и их необходимо было поддерживать. На что экспертизы внутри команд не хватало.</li>

22 + <li>также присутствовали некоторые системы, автотесты на которые давно-давно были разработаны и их необходимо было поддерживать. На что экспертизы внутри ком��нд не хватало.</li>

23 </ul><p>Наш процесс тестирования изменился и стал выглядеть следующим образом:</p>

24 <ol><li>Тестировщику в команде приходит артефакт, являющийся маленькой частью user story.</li>

25 <li>Он осуществляет приемочное тестирование и запускает автоматическую регрессию.</li>

26 <li>Если регрессия не полностью автоматизирована, то часть регрессии тестирует вручную.</li>

27 <li>Затем артефакт деплоится на прод. А тестировщик передает задачу автотестерам на автоматизацию.</li>

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

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

30 <h2>Проблемы выделенной команды автотестеров</h2>

31 <ol><li>Отсутствует быстрая ценность от автотестов. Как правило, они разрабатывались с задержкой в 1 и более спринт. Потому что была очередь на эти самые автотесты. И ценность от них команда получала только в виде автоматизированной регрессии. И очень часто бывало, что к тому моменту, когда автоматизируют фичу - команда ее уже переделает. И автотесты быстро становятся неактуальными.</li>

32 <li>Cтоимость продукта вырастала. Это следствие 1-го пункта. За счет того, что ручное тестирование уменьшалось со значительной задержкой, команде приходилось тратить деньги на автоматизацию тестирования с надежой на их отложенную ценность. Не говоря уже о том, что наличие прокси-менеджмента увеличивало петлю обратной связи, а это тоже увеличивало стоимость продукта.</li>

33 <li>Отсутствовала прозрачность в процессе тестирования. Никто в командах не знал, чем автотестеры занимаются. Не понимал их загруженность и по какому принципу они распределяли приоритеты.</li>

34 <li>Автотестеры - "купленные" люди (аутсорс). А в этом случае SM или PO считали, что это "приходящие" люди. И они не должны быть частью команды. Да и сами ребята не особо то и стремились становиться частью команды, ведь где гарантия, что их работодатель "не перекинет" их в очередной раз на другой проект?</li>

35 <li>Бизнес не понимал, почему он должен платить в надежде на долгосрочный эффект.</li>

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

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

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

39 <h2>Как тестировщики сотрудничают с автотестерами:</h2>

40 <ol><li>Тестировщики являются заказчиками для разработчиков автотестов.</li>

41 <li>Команда автотестеров - сервисная команда для продуктовых команд. И у такой команды есть свой тимлид, который проксирует запросы от тестировщиков автотестерам. В худшем случае, у тестировщиков тоже есть свой тимлид, который проксирует запросы тестировщиков тимлиду разработчиков автотестов. И на деле у нас получается сломанный телефон, длинная петля обратной связи. И почти нулевая эффективность. Обычно при такой оргструктуре люди выступают на конференциях с темами про то, что автоматизация тестирования это долго и дорого, и что тестировать только "руками" не стыдно.</li>

42 <li>И даже если с коммуникацией не все так плохо, можно поймать другие проблемы в стиле: разработчик(и) в конкретный момент времени заняты другими проектами и не могут здесь и сейчас ответить на запросы тестировщика.</li>

43 <li>Тестировщики не доверяют автотестам. И повторяют автоматизированные сьюиты вручную.</li>

44 </ol><h2>Как разработчики "сотрудничают" с автотестерами</h2>

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

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

47 <ol><li>Дублирование инструментов/фреймворков автоматизации из-за отсутствия коммуникации с разработчиками.</li>

48 <li>Часто решаются одни и те же проблемы разными инструментами. Например, для тестирования необходимо вытаскивать логи из Elasticsearch. У разработчиков уже, к примеру, есть своя написанная библиотека для этой задачи, но вместо того, чтобы переиспользовать и развивать существующий инструмент, автотестеры как правило пишут свое, либо найдут новый инструмент для этого.</li>

49 <li>Автотестеры используют инструменты, которые по каким-то причинам разработчики могут потом отказаться поддерживать или развивать. Например, у нас разработчики использовали maven в качестве сборщика проектов. И когда встала задача интеграции автоматизации тестирования в процесс разработки - пришлось отказаться от старого фреймворка совсем. Так как перевести его на gradle оказалось сложнее, чем написать новый. А использовать maven разработчики не могли, так как вся инфраструктура и окружение у нас уже были “заточены” под gradle.</li>

50 </ol><h2>Как менеджмент "сотрудничает" с автотестерами:</h2>

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

52 <ol><li>Что мы получаем от автоматизации тестирования?</li>

53 <li>Сколько она стоит продукту?</li>

54 <li>Учитывая стоимость, достаточно ли мы выигрываем от автоматизации тестирования?</li>

55 <li>Что плохого может произойти, если будет приостановлено финансирование автоматизации?</li>

56 <li>Какова стоимость технической поддержки написанных автотестов?</li>

57 </ol><p>В итоге, вот<strong>основные фейлы автоматизации тестирования</strong>, когда ее делают выделенные автотестеры:</p>

58 <ol><li>Непрозрачность количества автоматизированного тестового покрытия.</li>

59 <li>Разрабатываем то, что не используется при тестировании продукта. Например, написали или автоматизировали тест-кейсы, которые не включили в запуск регрессионного сьюита. Соответственно, такие автотесты не приносят ценности.</li>

60 <li>Не анализируем результаты тестирования: разработали --> запустили --> не проанализировали результаты. А потом, спустя время, команда обнаруживает "развалившиеся" автотесты из-за того, что тестовые данные сильно устарели. Это в лучше случае.</li>

61 <li>Нестабильные тест-кейсы: постоянно тратим много денег на стабилизацию тест-кейсов. Это проблема отсутствия погружения в контекст приложения, которое пытаемся автоматически тестировать.</li>

62 </ol><h2>Поиск решения проблемы</h2>

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

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

65 <ol><li>Теперь, когда артефакт приходил на тестирование, тестировщик делал приемку.</li>

66 <li>Затем тесты на этот артефакт сразу же автоматизируются.</li>

67 <li>Таким образом вся наша регрессия - автоматизирована.</li>

68 <li>И артефакт деплоится на прод с уже реализованными автотестами.</li>

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

70 <ol><li>Продукт/проект не генерировал соответствующую нагрузку на автотестера. Это несмотря на большое количество встреч, которые присутствовали у команды. И на которые в среднем в недельном спринте тратилось около 10 часов.</li>

71 <li>При этом автотестер отказывается заниматься функциональным тестированием, если попытаться оставить его одного в команде.</li>

72 <li>Но и тестировщик не настолько компетентен, чтобы писать автотесты самостоятельно.</li>

73 <li>Когда же предложили писать сервисы для приложения разработчику автотестов - он отказался, так как его навыков не хватало. И, как ни странно, не все автотестеры заинтересованы в развитии себя как разработчика.</li>

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

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

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

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

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

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

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

80 <p>1.Для начала мы выстроили правильную пирамиду тестирования. Согласно ей, наша тестовая стратегия заключалась в том, чтобы тесты были на разных слоях приложения. И между каждыми слоями должны быть интеграционные тесты. И руками тестироваться должны только приемочные тесты. При этом сразу после приемки - они автоматизируются. То есть в следующую итерацию тестировщик снова тестирует ТОЛЬКО изменение.</p>

81 <p>2.“Размазали” процесс автоматизации тестирования по команде. Так как тесты были разные, то и разрабатывали их разные члены команды. Тесты на api разрабатывались разработчиком api. Фронт-разработчик покрывал свои UI-компоненты тестами. Тестировщик должен быть запроектировать тестовую модель и реализовать интеграционные тесты, которые исполнялись со стороны браузера (selenium-тесты).</p>

82 <p>3.Использовали простые инструменты для автоматизации тестирования. Мы решили не усложнять себе жизнь и выбрали наиболее простую обертку над selenium-ом. На текущий момент - это selenide, если ваши автотесты пишутся на java.</p>

83 <p>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.</p>

84 <p>5.Научили тестировщиков чуть-чуть программировать. Среднее время обучения занимало от 2 недель до 2 месяцев.</p>

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

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

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

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

89 <h2>А не пострадает ли качество тестов</h2>

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

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

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

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

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

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

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

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

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

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

100 <h2>Выводы:</h2>

101 <ol><li>Наличие выделенной команды автотестеров - это не agile.</li>

102 <li>Наличие выделенных разработчиков автотестов - это дорого для продукта/команды.</li>

103 <li>Поиск/хантинг таких людей дорог и долог. И это тормозит развитие продукта.</li>

104 <li>Разработка автотестов значительно отстает от разработки продукта. В итоге мы получаем не максимальное велью от автоматизации тестирования.</li>

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

106 <ol><li>Тестировщик тоже инженер. И покуда команда к нему не начнет относиться как к инженеру, у того не возникнет мотивации развиваться или учиться программировать.</li>

107 <li>Команда тоже отвечает за качество. Не тестировщик, на которого в случае чего повесят всю ответственность за качество продукта. А вся команда. Включая заказчика (PO).</li>

108 <li>Автотесты тоже часть продукта. Покуда вы будете думать, что автотесты - это продукт для другого продукта, так и будут закрываться спринты без написанных автотестов. А автотесты будут вашим техдолгом, который, как правило, не закрывается. Важно понимать, что автотесты - это то, что гарантирует качество вашего продукта.</li>

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

110