Solution Architect in Test Automation. Part 1

Продолжаем цикл статей о новых дисциплинах в тестировании.

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

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

Из первой части вы узнаете, кто такой Solution Architect in Test Automation (SA in TA), какие задачи и роли он выполняет на проекте. Также мы расскажем, как выглядит его типичный рабочий день, и как долго архитектор работает на проекте.

Кто такой Solution Architect in Test Automation и чем он отличается от Solution Architect в разработке?

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

Чтобы стать Solution Architect, требуется быть ведущим инженером в своей дисциплине. Затем нужно улучшать навыки, специфичные для Solution Architect в разработке или тестировании. Также с точки зрения hard skills важно уметь хорошо работать с кодом, любить ”кодировать”.»

«Solution Architect in Test Automation должен быть немного программистом. Самое важное — это понимание технических процессов, которые происходят на стороне приложения. И если специалист не разрабатывал приложения, ему будет очень сложно стать архитектором даже в автоматизации.

Мой опыт является хорошим примером роста до Solution Architect. Большую часть своей карьеры я работал разработчиком. До прихода в EPAM разрабатывал систему расчета пенсий. Во время работы в EPAM был первым разработчиком Report Portal, а в последствии стал его архитектором. На мой взгляд, именно опыт разработки позволил мне успешно перейти в дисциплину SA in TA.»

Чем занимается SA in TA, как выглядит его типичный рабочий день?

Андрей: «Мой типичный рабочий день может быть очень разным, поскольку архитектора зачастую привлекают к решению важных и срочных задач, таких как пресейл или разработка архитектуры. На данный момент я работаю архитектором инфраструктуры на полставки на одном из проектов. Мы настраиваем всю инфраструктуру для тестирования: деплоймент Report Portal, настройка агентов, которые туда репортят, поднятие инфраструктуры для Selenium в Kubernetes кластер. Также я помогаю разработать тестовый фреймворк, немного пишу код и пишу много документов.

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

Какие документы пишет SA in TA?

Андрей: «Если говорить простым языком, то у нас есть приложение и есть авто тесты, которые тоже являются приложением. Тесты необходимо описать, поскольку они состоят из большого количества модулей и компонентов. Я разрабатываю высокоуровневую диаграмму, которая состоит из схемы фреймворка, его модулей и их взаимодействия как между собой, так и с приложением. И в дальнейшем описываю, как тесты интегрируются в CI\CD, взаимодействуют с остальной частью инфраструктуры (например, Report Portal). Эту диаграмму взаимодействия нужно объяснить текстом, описать, какие доступы нужны между компонентами, какие требования к оборудованию.

Другой тип документов, которые создаются на стадии пресейл – это Запрос информации (Request for information, RFI) и Запрос предложения (Request for proposal, RFP). Это те документы, которые готовит каждый вендор по разработке ПО для тендера. Эти документы состоят из технического описания, описания ресурсов (сколько людей необходимо для реализации проекта) и сколько это будет стоить. На основе таких предложений заказчик принимает решение, какого вендора выбрать. Я отвечаю только за техническую часть того решения, которое ляжет в основу документа. Но также я предоставляю предварительные оценки по ресурсам.»

Назовите топ 3 вопроса, которые задает заказчик архитектору, а архитектор заказчику.

Андрей: «Такие вопросы выделить сложно. Если говорить о пресейл, то, как правило, главная задача архитектора – четко понимать, как работает система и какие ее части необходимо покрыть автоматическими тестами.

Также мы делаем Assessment (оценку) проектов. При такой активности, как правило, нужно понять, где находится проблема на текущем проекте. И для этого есть огромное количество вопросов, которые необходимо задать заказчику:

·       откуда “лезут” баги на продакшн системе

·       какой модуль системы необходимо тестировать

·       почему появляются баги (это может быть процессная проблема, проблема с тестами)

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

Как долго SA in TA работает на проекте?

Андрей: «Обычно SA работает на проекте 3–6 месяцев. Этого времени достаточно, чтобы все настроить, сделать ядро спроектированного решения, набрать правильных людей и подготовить их. По большому счету потом уже не нужно вовлечение архитектора в такой степени.»

Михаил: «Бывают исключения, когда вместе с клиентом требуется сделать большую трансформацию. Например, у заказчика мало того, что есть большое семейство продуктов, которые между собой взаимодействуют, так они еще хотят заменить половину этих продуктов. Для такого заказчика нельзя сразу нарисовать архитектуру на всю трансформацию на несколько лет вперед. В таком случае архитекторы вовлекаются на проект на 2–3 года.

Также иногда POC по автоматизации тестирования, который разрабатывался в начале, может и не сработать. Соответственно, придется продукт переделывать с вовлечением SA in TA.»

Андрей: «Роль архитектора может быть как временной, например, консультант на проекте с вовлечением на 3–6 месяцев, так и постоянной, если он будет являться штатным архитектором на каком-то большом проекте или аккаунте.»

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