Архитектор Качества: Кто Он И Когда Он Нужен?

С каждым днем в IT-сфере появляется все больше новых задач, в том числе и в сфере тестирования.

Если раньше тестировщику нужно было просто протестировать по требованиям (или без них), то теперь ему нужно сначала понять, как это можно тестировать, какие технологии для этого нужны, что можно автоматизировать и как включить цикл релиза во все этот бардак и т. д. Кто должен ответить на эти вопросы? Кто будет общаться с заказчиком и уточнять требования? Кто будет создавать подходы к тестированию, архитектуру, требования? Работая руководителем и координатором тестирования на проектах для крупных компаний и решая все эти вопросы в течение трёх лет, я понял, что всё равно важно привлечь отдельного человека, который ответит на главный вопрос: «Как проводить тестированиеЭ» Я провел небольшое исследование и обнаружил, что такая должность уже существует, называется «Архитектор качества», но мало кто о ней знает. А описания вакансий «Архитектора качества» на сайтах работодателей поражают перечнем обязанностей и навыков, но я думаю, что это скорее связано с непониманием того, кто такой «Архитектор качества».

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

Краткое описание проекта

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

Какие тестовые роли у вас были в проекте?

Наш проект не стал исключением.

Работал над проектом:

• 1 менеджер по тестированию или руководитель тестирования
• 40 ручных тестировщиков, работавших со scrum-командами (7 команд)
• 2 разработчика (это скорее исключение, так как разработчики не любят работать над задачами по автоматизации) и 2 автоматизатора тестов
• 2 тестировщика, которые участвовали в нагрузочном тестировании
• 1 функциональный тестер для тестирования продуктов, разработанных разработчиками и специалистами по автоматизации тестирования

Ручное тестирование

Для этого тестировщики обычно:

1. Создайте планы тестирования.

2. Создайте стратегию тестирования.

3. Они создают тест-кейсы с прописанными шагами (с ожидаемыми и фактическими результатами).

4. Они запускают тест-кейсы и делают выводы о качестве приложения.

Была только старая система и новая и желание: «Заставить работать, но на новой базе».

Поэтому мы могли использовать только сопоставимый подход – сравнение результатов старой и новой систем.

Все осложнялось тем, что мы работали с производственной системой и ежедневно обновляемыми данными.

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

На этом этапе стали возникать вопросы:

1. Как мы можем сделать вывод, что наша система работала правильно, если из-за временного сдвига мы получаем результаты, отличные от тех, которые мы получали в старой системе?
2. Можем ли мы отказаться от производственных данных и работать над стабильными данными? Какие здесь риски?
3. И если мы получим стабильные данные, как мы сможем доказать, что наша система будет правильно работать с ежедневно обновляемыми данными?

Автоматизатор испытаний

• автотесты, которые будут интегрированы с CI/CD;
• приложения, которые помогали функциональным тестировщикам в тестировании;
• и другие разработки, которые были необходимы для внутренних нужд проекта.

И соответственно возникли вопросы:

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

   с приложением работают СА.

2. Кто будет разрабатывать требования к функциональности приложения для тестирования? Есть очевидные требования, но есть и неочевидные.

   Например, нужно ли нам хранить и анализировать логи наших приложений?

3. Кто будет прорабатывать среду приложения с клиентом и фиксировать эти требования? Например, в этом конкретном проекте было ограничение версии Spark 1.4, и это было обнаружено только после создания приложения.

Руководитель отдела тестирования, также известный как руководитель тестирования

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

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



В обоих случаях Test Lead занят работой над уже выбранной стратегией тестирования, но никто не несет ответственности за выбор самой стратегии, обоснование этого выбора перед клиентом, адаптацию ее к изменениям и другим вопросам.

Например:

1. Работа с клиентом над планом перехода на этап приемочного тестирования клиента (UAT).

2. Проработка требований с клиентом, когда считается, что функционал можно перенести в UAT.
3. Проработка с клиентом предположений по тестированию на разных типах сред (очень деликатный момент).

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

4. Работа с клиентом над допустимыми расхождениями метрик при различных видах тестирования.

   Например, какой результат клиент ожидает увидеть во время тестирования производительности? Может ему будет достаточно того, что система работает не хуже.

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

Что в этом плохого?

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

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

   Соответственно, могут быть установлены неправильные приоритеты.

2. Тест-лида обычно включают в проект, когда разработка уже идет или только начинается, т.е.

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

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

   В другом случае руководителю приходится изобретать велосипеды.

Так кто же такой Архитектор качества и зачем он нужен?

Проекты сейчас диктуют другие условия.

Проекты стали крупнее, сложнее в техническом и технологическом отношении и могут охватывать несколько отраслей и технологий.

Тестирование стало не только услугой, но и поставщиком (разработчиком) программного обеспечения для заказчика.

Поэтому необходимо выделить такую роль в тестировании.

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

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

окончательные результаты тестирования.

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

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

Когда архитектор качества не нужен?

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

Первый тип проектов — заказчик оставляет разработку процессов тестирования на усмотрение нанятой им компании.

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

Второй тип проектов — у заказчика есть свое понимание тестирования, четкая картина и налаженные процессы.

В этом случае архитектор качества может не понадобиться; тестирование требуется лишь для того, чтобы вписаться в существующую картину мира и поддержать ее.

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

Третий тип проектов – заказчику не нужны услуги Качественного Архитектора.

Причины могут быть разные:

1. Небольшой и краткосрочный проект с простым функционалом.

2. У заказчика есть свой Архитектор качества.

3. Заказчик отказался от тестирования и т.д.

Навыки архитектора качества

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

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

Короче говоря, по моему мнению, архитектор качества должен иметь:

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

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

3. Лидерские качества и активность, т.к.

   очень часто тестирование стараются оставить на потом.

4. Хорошее знание тестирования в целом, тестовой документации, процессов тестирования, отчетов о тестировании, подходов и т. д.;
5. Хорошее знание правил разработки программного обеспечения: политика выпуска, политика управления версиями, понимание процессов CI/CD и т. д.

Работа Архитектора качества осложняется тем, что часто приходится менять мнение заказчика о тестировании исключительно о внутренней кухне проекта.

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

Заключение

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

Теги: #Карьера в ИТ-индустрии #Управление проектами #Тестирование ИТ-систем #автоматизация тестирования #архитектор решений #тонкости профессии #тестировщик #Архитектор качества

• Простые Шаги По Созданию Собственного Четырехъядерного Компьютера

  19 Oct, 24

• Основы Контекстной Рекламы Для Коммерческой Деятельности

  19 Oct, 24

• Бывший Руководитель Проекта Rambler Дмитрий Кочнев Назначен Директором По Развитию Бизнеса «Евросети»

  19 Oct, 24

• Простой Бессерверный Интерфейс Спереди И Сзади

  19 Oct, 24

• Переход От Одного Инструмента Планирования Разработки К Другому — От Xplanner К Redmine

  19 Oct, 24

• Поговорим О Взаимодействии С Фрилансерами

  19 Oct, 24

• Hp И Eaton Разрабатывают Модульный Дата-Центр По Заказу Министерства Энергетики Сша

  19 Oct, 24

• Использование Оболочки Visual Studio 2010 Для Компиляции Проектов С Помощью Gcc В Linux

  19 Oct, 24

• Jii: Масштабируемый Сервер И Клиент Comet

  19 Oct, 24

• Киберпанк Комната/Квартира

  19 Oct, 24