Solution Architect in Test Automation. Part 4

22 февраля 2021 года в формате интервью прошел онлайн-ивент ProQuality Community, посвященный еще одной новой дисциплине в автоматизации тестирования «Solution Architect in Test Automation». Опытный Solution Architect в автоматизации тестирования Андрей Воробьев и организатор обучающей программы для архитекторов Михаил Субоч рассказали основное о новой дисциплине: чем занимается Solution Architect, почему IT нуждается в таких специалистах, чем они отличаются от других, а также как вырасти в Solution Architect в автоматизации тестирования.

Мы продолжаем серию статей о самом интересном, что было на мероприятии.

В последней части вы сможете узнать, нужна ли такая специальность, как Delivery Manager in автоматизации тестирования, а также как на интервью отличить Chief специалиста по автоматизированному тестированию от Solution Architect в автоматизации тестирования.

Нужна ли такая специальность, как Delivery Manager или Product Manager в автоматизации тестирования?

«У нас есть понимание, что нужна такая специальность как Delivery Manager в тестировании (DM in Test). Но необходимо отметить, что основные навыки для такого специалиста – это умение управлять проектом. Особенность DM in Test только в том опыте и знаниях, с которыми он пришел. Эта экспертиза поможет ему принимать более взвешенные решения.»

«Мое видение идет в разрез с видением компании. В реальной жизни DM выполняет работу более высокоуровневую и ориентированную на управление проектом. И он должен уметь управлять и разработкой, и тестированием, и автоматизацией.»

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

Андрей: «В качестве примера могу привести ситуацию, когда ты написал свой фреймворк или решение и хочешь развивать его внутри компании. Перед тем, как идти к бизнесу, тебе стоит заполнить Lean Canvas. Потому что на уровне менеджмента более интересно, какие проблемы твой продукт решает, какую пользу (в том числе материальную) он может принести.

При продаже решения заказчику нужно в первую очередь понять, какие проблемы у заказчика требуется решить. Например, во время assessment мы понимаем, что автоматизация работает не так и плохо, но она очень медленная, требует много ресурсов и времени на анализ. В результате регрессия с автоматизацией занимает 5 дней. И когда ты будешь продавать свой фреймворк, то необходимо делать упор на решение этих проблем. Например, что твои тесты запускаются быстрее: в много потоков, параллельно. Для ускорения анализа используется Report Portal.»

Как принимать решение, которое ты продаешь, если у тебя нет технической экспертизы в этой области?

Андрей: «В тех случаях, когда я точно знаю, что моего опыта недостаточно, то я сразу же иду к нишевым специалистам. Это единственно правильное решение в данной ситуации.»

Михаил: «Также всегда будет работать “менеджерский трюк” из метода экспертных оценок, используемого в оценке задач: если ты не уверен, что ты позвал правильного нишевого эксперта, то зови трех, и выслушай их отдельно. И правильное решение должно быть общее среди предложенных.»

В каком количестве SA in TA в данный момент нуждается компания?

Андрей: «На самом деле, не нужно много SA in TA (консультантов). С другой стороны, нам нужно максимально большое количество архитекторов только потому, что это очень зрелые специалисты. Их можно “в случае пожара приложить к ране” в различных областях, от DevOps до ручного тестирования.»

Михаил: «Я бы хотел отметить такой момент, что срок роста и обучения таких специалистов достаточно продолжительный, и спрос на них постоянно растет. Если ты принял решение расти в SA in TA, то к тому моменту, когда ты станешь архитектором, работа всегда найдется.»

Как на техническом интервью определить, что специалист больше подходит на роль SA или Chief?

Андрей: «Если специалист сам говорит, открыт к общению, то он очень пригодиться как SA. Если же человек “социофоб” и очень сильно ориентирован на технологии, то он больше Chief. На мой взгляд, тут не только разница типов работ, а и типов характеров.

Также архитектор должен хотеть путешествовать, ездить в командировки.»

Михаил: «SA специалист должен хотеть делать работу, которая специфична только для SA.»

Нужны ли специфичные навыки у SA in TA, чтобы перейти в DM?

Михаил: «Нужны такие архитектурные знания, как способность читать диаграммы, чтобы говорить на одном языке с архитектором. Эти знания общие для всех архитекторов (System, Quality…).»

Какой тип коммуникаций между SA in TA и Test manager?

Андрей: «В основном это общение об оценках, планах.»

Как можно стать SA in TA: это больше самостоятельное обучение или участие в программе обучения?

Андрей: «С технической точки зрения я бы посоветовал попробовать себя в разработке. В EPAM нет большой проблемы перейти в разработку на время. Коммуникативные навыки очень хорошо прокачиваются на публичных выступлениях.»

На сколько важен опыт работы с Embedded системами для SA in TA?

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

Для нас важно иметь специалистов SA в каждом домене.»

Полная запись ивента доступна на YouTube канале ProQuality Community.