С каждым днём в сфере IT появляется всё больше новых задач, в том числе и в сфере тестирования. Если раньше тестировщику нужно было просто провести тестирование по требованиям (или без них), то сейчас ему необходимо сперва понять, как это вообще можно протестировать, какие технологии для этого нужны, что может быть автоматизировано, и как во всё это безобразие включить релизный цикл и т.д. Кто должен отвечать на эти вопросы? Кто пообщается с заказчиком и прояснит требования? Кто создаст подходы и архитектуру тестирования, требования?
Работая руководителем и координатором тестирования на проектах для крупных компаний и решая все эти вопросы на протяжении трёх лет, я поняла, что важно всё-таки привлекать отдельного человека, который будет отвечать на главный вопрос: «Как проводить тестирование?».
Я провела небольшое расследование и обнаружила, что такая роль уже существует, и называется она Test Solution Architect (TSA), но об этом мало кто знает. А описание вакансий TSA на сайтах работодателей поражают своим перечнем обязанностей и навыков, но я думаю, что это скорее от непонимания того, кто такой TSA.
Основываясь на своем опыте в этом направлении, я решила показать на примере одного из реальных проектов, кто же такой TSA и когда он нужен.
Задачей проекта была замена одной базы данных на другую, точнее Cassandra и её придаток в виде FilloDB заменялись на SnowFlake, в бизнес-процессе ежедневного, ежечасного и даже ежеминутного потока поставки и обработки данных. Подобных потоков было больше 50-ти, и по задумке архитекторов это должно было решить огромное количество проблем, связанных с производительностью, потерей данных, расходами на содержание и покупку дополнительных лицензий на Cassandra и т.д. Но какие из этих ожиданий оправдались и какие нет — это тема другой статьи.
Исторически в тестировании выделяют следующие роли: ручной тестировщик или функциональный тестировщик, автоматизатор тестирования (тот, кто пишет код и тесты) и руководитель тестирования (тот, кто решает все остальные вопросы). Наш проект не был исключением. На проекте работали:
Основной целью функциональных тестировщиков было протестировать работу приложения и сказать, удовлетворяет ли оно требованиям заказчика. Для этого тестировщики обычно:
У нас же не было требований заказчика или описаний системы. Была только старая система и новая и пожелание: «Сделайте, чтобы работало, но с новой базой». Поэтому мы могли применять только подход like-for-like — сравнение результатов старой и новой системы. Всё осложнялось тем, что мы работали с продакшн-системой и ежедневно обновляемыми данными. К сожалению, мы не могли запускать нашу систему в то же время, что и продакшн-систему, и запускали её позже, а это приводило к тому, что данные в старой и новой системе различались.
На этом этапе стали возникать вопросы:
Это только верхушка айсберга списка подобных вопросов, возникших на проекте при функциональном/ручном тестировании.
У автоматизаторов тестирования (и разработчиков) была цель написать приложения, которые смогут тестировать автоматически или/и облегчат работу функциональным тестировщикам:
На проекте все приложения, что были разработаны для тестирования, должны были быть отдельным продуктом, которые подчинялись всем правилам разработки и в итоге были бы поставлены заказчику. И, соответственно, возникли вопросы:
И это тоже далеко не все вопросы, возникающие на проекте в части автоматизации тестирования.
Test Lead должен организовать процессы тестирования на проекте. В его функции входило распределение задач, проведение внутренних митингов с тестировщиками, организация работы с заказчиком (выяснение деталей, ревью результатов) и т.д. То есть он был сосредоточен на текущем процессе и решении ежедневно встающих проблем/задач, а не в проработке задач подхода, стратегии, архитектуры тестирования.
Если мы говорим о техническом Test Lead, то в его ведении была работа с техническими решениями: организация разработки приложений для тестирования как процесса создания отдельного программного продукта, который подчиняется всем правилам разработки, например, создание unit-testов, интеграция с CI/CD процессами и т. д.
На нашем проекте эти роли исполняли два человека, и расписание каждого выглядело вот так:
В обоих случаях Test Lead занят проработкой уже выбранной стратегии тестирования, но никто не отвечает за выбор самой стратегии, обоснование этого выбора клиенту, её адаптацию к изменениям и другие вопросы. Например:
Вопросы выше обычно возлагают на плечи Test Lead, но тут есть порочность подхода:
И это далеко не все проблемы, которые падают на Test Lead, когда нет TSA.
Test Solution Architect — это человек, который рассматривает задачу с точки зрения бизнеса, информации и технологий, согласовывает и прорабатывает требования с заказчиком, составляет roadmap со сроками и прорабатывает решения на уровне интерфейсов.
Проекты сейчас диктуют другие условия. Проекты стали больше, сложнее в техническом и в процессном плане, могут охватывать несколько отраслей и технологий. Тестирование стало не только сервисом, но и поставщиком (разработчиком) ПО для заказчика. Поэтому в тестировании есть необходимость выделения подобной роли. Причем этот человек должен входить в проект вместе с SA, кто занимается продакшн-приложением, и начинать работать над всеми вопросами в тот же момент.
Конкретно на нашем проекте роль TSA исполнял Test Lead, который присоединился к проекту через 3 месяца после начала разработки, и это повлекло за собой огромное количество дополнительной работы по согласованию требований, окружений, выяснение видения итоговых результатов тестирования у заказчика. В результате проект большую часть своей жизни не укладывался в сроки, и клиенты были недовольны поставками и результатом тестирования. Не потому, что работа была выполнена плохо, а потому, что результат, который выпускала команда, не соответствовал ожиданиям заказчика.
Понятно, что такая роль нужна не на всех проектах. Ниже я предлагаю простейший способ определения необходимости TSA на проекте в зависимости от того, как заказчик видит подход к тестированию.
Первый тип проектов – заказчик отдаёт постановку процессов тестирования на усмотрение компании, которую он нанял.
В таком случае TSA входит в проект с момента начала работы над ним, совместно с SA прорабатывает требования к тестированию, разрабатывает high level схему тестирования, решает, что будет автоматизировано/разработано в виде отдельных приложений, определяет требования к этим приложениям и, конечно, согласовывает с заказчиком, приоритезирует задачи проекта в соответствии с ожиданиями бизнеса.
Второй тип проектов – заказчик обладает своим пониманием тестирования, явная картина и налаженные процессы.
В таком случае TSA может не понадобиться, от тестирования требуется лишь вписаться в существующую картину мира и поддержать её. Но если понимание поверхностное, то TSA необходимо не только выполнить все те действия, что и для проектов первого типа, но ещё и доказать заказчику, что это всё необходимо.
Третий тип проектов – заказчик не нуждается в услугах TSA.
Причины могут быть разные:
В разработке уже очень давно и успешно применяется практика Solution Architect. Основываясь на этом успешном опыте, а также учитывая объёмы и сложности проектов, вопросы, которые превышают зону ответственности Test Lead, можно сказать, что выделение роли TSA — это естественное развитие событий. Причём TSA должен быть обучен тем же процессам, техникам и подходам, что и SA.
Если коротко, на мой взгляд, TSA должен обладать:
Исходя из вышесказанного, TSA должен обладать всеми теми же знаниями, что и SA, но быть сосредоточенным на задачах предоставления заказчику качественного продукта. Осложняется работа TSA тем, что зачастую приходится менять мнение заказчика о тестировании как исключительно о внутренней кухне проекта.
Именно те знания, которые я получила в школе Solution Architect, позволили на проекте, что был описан выше, восстановить доверие заказчика, решить множество вопросов в тестировании и успешно завершить поставку всей функциональности почти вовремя, а ещё наладить процессы и подписать контракты на будущие работы.
Отрасль IT развивается, появляются новые задачи (вызовы если хотите) и в случае тестирования стала насущной выделенная позиция TSA. Естественно, все зависит от проекта, но в проектах, где TSA необходим, нужно привлекать к работе на самом начальном этапе, это позволит избежать проблем в будущем и поможет развитию проекта.
Работая руководителем и координатором тестирования на проектах для крупных компаний и решая все эти вопросы на протяжении трёх лет, я поняла, что важно всё-таки привлекать отдельного человека, который будет отвечать на главный вопрос: «Как проводить тестирование?».
Я провела небольшое расследование и обнаружила, что такая роль уже существует, и называется она Test Solution Architect (TSA), но об этом мало кто знает. А описание вакансий TSA на сайтах работодателей поражают своим перечнем обязанностей и навыков, но я думаю, что это скорее от непонимания того, кто такой TSA.
Основываясь на своем опыте в этом направлении, я решила показать на примере одного из реальных проектов, кто же такой TSA и когда он нужен.
Краткое описание проекта
Задачей проекта была замена одной базы данных на другую, точнее Cassandra и её придаток в виде FilloDB заменялись на SnowFlake, в бизнес-процессе ежедневного, ежечасного и даже ежеминутного потока поставки и обработки данных. Подобных потоков было больше 50-ти, и по задумке архитекторов это должно было решить огромное количество проблем, связанных с производительностью, потерей данных, расходами на содержание и покупку дополнительных лицензий на Cassandra и т.д. Но какие из этих ожиданий оправдались и какие нет — это тема другой статьи.
Какие test-роли были на проекте?
Исторически в тестировании выделяют следующие роли: ручной тестировщик или функциональный тестировщик, автоматизатор тестирования (тот, кто пишет код и тесты) и руководитель тестирования (тот, кто решает все остальные вопросы). Наш проект не был исключением. На проекте работали:
- 1 руководитель тестирования или Test Lead
- 40 ручных тестировщиков, которые работали со scrum-командами (7 команд)
- 2 разработчика (это скорее исключение, т. к. разработчики не любят работать над задачами автоматизации) и 2 автоматизатора тестирования
- 2 тестировщика, которые занимались нагрузочным тестирование
- 1 функциональный тестировщик для тестирования продуктов, что разрабатывали разработчики и автоматизаторы тестирования
Ручное тестирование
Основной целью функциональных тестировщиков было протестировать работу приложения и сказать, удовлетворяет ли оно требованиям заказчика. Для этого тестировщики обычно:
- Создают тестовые планы.
- Создают тестовую стратегию.
- Создают test-cases с расписанными шагами (с ожидаемым и актуальным результатом).
- Выполняют test-cases и делают вывод о качестве приложения.
У нас же не было требований заказчика или описаний системы. Была только старая система и новая и пожелание: «Сделайте, чтобы работало, но с новой базой». Поэтому мы могли применять только подход like-for-like — сравнение результатов старой и новой системы. Всё осложнялось тем, что мы работали с продакшн-системой и ежедневно обновляемыми данными. К сожалению, мы не могли запускать нашу систему в то же время, что и продакшн-систему, и запускали её позже, а это приводило к тому, что данные в старой и новой системе различались.
На этом этапе стали возникать вопросы:
- Как сделать вывод, что наша система отработала корректно, если из-за временного сдвига мы получаем результаты, отличающиеся от тех, что мы получаем в старой системе?
- А можем ли мы уйти от продакшн данных и работать на стабильных данных? Какие тут риски?
- И если всё-таки придём к стабильным данным, то как доказать, что наша система будет работать и с ежедневно обновляемыми данными корректно?
Это только верхушка айсберга списка подобных вопросов, возникших на проекте при функциональном/ручном тестировании.
Автоматизатор тестирования
У автоматизаторов тестирования (и разработчиков) была цель написать приложения, которые смогут тестировать автоматически или/и облегчат работу функциональным тестировщикам:
- автотесты, которые были бы интегрированы с CI/CD;
- приложения, которые помогали в тестировании функциональным тестировщикам;
- и другие разработки, которые нужны были для внутренних нужд проекта.
На проекте все приложения, что были разработаны для тестирования, должны были быть отдельным продуктом, которые подчинялись всем правилам разработки и в итоге были бы поставлены заказчику. И, соответственно, возникли вопросы:
- Кто вместе с заказчиком разработает нефункциональные требования к приложениям для тестирования? Solution Architect сказали, что это не их работа, т.к. SA работают с приложением, что было заказано заказчиком.
- Кто разработает требования к функциональности приложений для тестирования? Есть очевидные требования, но есть и неочевидные. Например, нужно ли нам хранить логи наших приложений и анализировать их?
- Кто проработает окружение для приложений с клиентом и зафиксирует эти требования? Например, конкретно на этом проекте было ограничение по версии spark 1.4, и это было обнаружено только после создания приложения.
И это тоже далеко не все вопросы, возникающие на проекте в части автоматизации тестирования.
Руководитель тестирования, он же Test Lead
Test Lead должен организовать процессы тестирования на проекте. В его функции входило распределение задач, проведение внутренних митингов с тестировщиками, организация работы с заказчиком (выяснение деталей, ревью результатов) и т.д. То есть он был сосредоточен на текущем процессе и решении ежедневно встающих проблем/задач, а не в проработке задач подхода, стратегии, архитектуры тестирования.
Если мы говорим о техническом Test Lead, то в его ведении была работа с техническими решениями: организация разработки приложений для тестирования как процесса создания отдельного программного продукта, который подчиняется всем правилам разработки, например, создание unit-testов, интеграция с CI/CD процессами и т. д.
На нашем проекте эти роли исполняли два человека, и расписание каждого выглядело вот так:
В обоих случаях Test Lead занят проработкой уже выбранной стратегии тестирования, но никто не отвечает за выбор самой стратегии, обоснование этого выбора клиенту, её адаптацию к изменениям и другие вопросы. Например:
- Проработка с клиентом плана выхода в стадию приёмочного тестирования со стороны клиента (UAT).
- Проработка с клиентом требований, когда считается, что функциональность может быть передана в UAT.
- Проработка с клиентом допущений тестирования на разных типах окружений (очень тонкий момент). Поскольку обычно тестовое окружение не соответствует продакшн, то все вопросы, связанные с тестированием на другом окружении, должны быть проработаны с клиентом.
- Проработка с клиентом допустимого расхождения метрик в различных типах тестирования. Например, какой результат ожидает увидеть клиент при перформанс тестировании? Может ему достаточно будет того, что система работает не хуже.
- Сбор всех возможных метрик в цифрах, например, расхождение данных для этой таблицы допустимо не более чем на 10%, или время работы скрипта должно быть не более восьми часов.
Что же тут не так?
Вопросы выше обычно возлагают на плечи Test Lead, но тут есть порочность подхода:
- Их не учат процессам, при которых Test Lead должен проработать все подобные вопросы с заказчиком. Чаще всего опытный Test Lead это понимает и, возможно, даже умеет, но, скорее всего, за рамками его понимания остаётся такая важная часть, как цель бизнеса или конкретных доработок. Соответственно, могут выставляться неверные приоритеты.
- Test Lead обычно входит в проект, когда уже ведётся или только начинается разработка, т.е. он сталкивается с условиями, что уже есть какие-то договорённости или даже всё уже зафиксировано. Повезло, если SA достаточно опытный и грамотный человек и пойдёт навстречу тестированию — поможет адаптировать первоначальные договорённости с заказчиком под нужды тестирования. В другом случае лиду приходится изобретать велосипеды.
И это далеко не все проблемы, которые падают на Test Lead, когда нет TSA.
Так кто же всё-таки такой TSA и зачем он нужен?
Test Solution Architect — это человек, который рассматривает задачу с точки зрения бизнеса, информации и технологий, согласовывает и прорабатывает требования с заказчиком, составляет roadmap со сроками и прорабатывает решения на уровне интерфейсов.
Проекты сейчас диктуют другие условия. Проекты стали больше, сложнее в техническом и в процессном плане, могут охватывать несколько отраслей и технологий. Тестирование стало не только сервисом, но и поставщиком (разработчиком) ПО для заказчика. Поэтому в тестировании есть необходимость выделения подобной роли. Причем этот человек должен входить в проект вместе с SA, кто занимается продакшн-приложением, и начинать работать над всеми вопросами в тот же момент.
Конкретно на нашем проекте роль TSA исполнял Test Lead, который присоединился к проекту через 3 месяца после начала разработки, и это повлекло за собой огромное количество дополнительной работы по согласованию требований, окружений, выяснение видения итоговых результатов тестирования у заказчика. В результате проект большую часть своей жизни не укладывался в сроки, и клиенты были недовольны поставками и результатом тестирования. Не потому, что работа была выполнена плохо, а потому, что результат, который выпускала команда, не соответствовал ожиданиям заказчика.
Когда не нужен TSA?
Понятно, что такая роль нужна не на всех проектах. Ниже я предлагаю простейший способ определения необходимости TSA на проекте в зависимости от того, как заказчик видит подход к тестированию.
Первый тип проектов – заказчик отдаёт постановку процессов тестирования на усмотрение компании, которую он нанял.
В таком случае TSA входит в проект с момента начала работы над ним, совместно с SA прорабатывает требования к тестированию, разрабатывает high level схему тестирования, решает, что будет автоматизировано/разработано в виде отдельных приложений, определяет требования к этим приложениям и, конечно, согласовывает с заказчиком, приоритезирует задачи проекта в соответствии с ожиданиями бизнеса.
Второй тип проектов – заказчик обладает своим пониманием тестирования, явная картина и налаженные процессы.
В таком случае TSA может не понадобиться, от тестирования требуется лишь вписаться в существующую картину мира и поддержать её. Но если понимание поверхностное, то TSA необходимо не только выполнить все те действия, что и для проектов первого типа, но ещё и доказать заказчику, что это всё необходимо.
Третий тип проектов – заказчик не нуждается в услугах TSA.
Причины могут быть разные:
- Маленький и недолгосрочный проект с несложной функциональностью.
- У заказчика есть свой TSA.
- Заказчик отказался от тестирования и т.д.
Навыки TSA
В разработке уже очень давно и успешно применяется практика Solution Architect. Основываясь на этом успешном опыте, а также учитывая объёмы и сложности проектов, вопросы, которые превышают зону ответственности Test Lead, можно сказать, что выделение роли TSA — это естественное развитие событий. Причём TSA должен быть обучен тем же процессам, техникам и подходам, что и SA.
Если коротко, на мой взгляд, TSA должен обладать:
- Техническими знаниями как в общем, так и в доменной области, где он работает, знать проблематику этой области, типичные ошибки, проблемы и способы их проверки.
- Хорошими коммуникативными навыками, уметь обратить внимание заказчика на вопросы тестирования, проработать требования к тестированию, подходы тестирования, отчетность тестирования и множество сопутствующих вопросов, такие как окружение для тестирования.
- Лидерскими навыками и быть проактивным, т.к. тестирование очень часто пытаются оставить на потом.
- Хорошими знаниями о тестировании в целом, тестовой документации, процессах тестирования, отчетности тестирования, подходах и т.д.;
- Хорошими знаниями правил разработки ПО: релизной политики, политики версионирования, разбираться в процессах CI/CD и т. д.
Исходя из вышесказанного, TSA должен обладать всеми теми же знаниями, что и SA, но быть сосредоточенным на задачах предоставления заказчику качественного продукта. Осложняется работа TSA тем, что зачастую приходится менять мнение заказчика о тестировании как исключительно о внутренней кухне проекта.
Именно те знания, которые я получила в школе Solution Architect, позволили на проекте, что был описан выше, восстановить доверие заказчика, решить множество вопросов в тестировании и успешно завершить поставку всей функциональности почти вовремя, а ещё наладить процессы и подписать контракты на будущие работы.
Вывод
Отрасль IT развивается, появляются новые задачи (вызовы если хотите) и в случае тестирования стала насущной выделенная позиция TSA. Естественно, все зависит от проекта, но в проектах, где TSA необходим, нужно привлекать к работе на самом начальном этапе, это позволит избежать проблем в будущем и поможет развитию проекта.
SPBQA
that's fine