Почему для agile-тестирования нужен именно T-shaped QA?

Привет! Я Илья Рыбаков, руководитель QA-отдела в компании «Вебпрактик». Хочу поделиться нашим видением эффективного QA-инженера в разработке и рассказать, для чего мы обучаем сотрудников по модели T-shaped, совмещая глубокую экспертизу в тестировании и развитие скилов в смежных сферах. Подробно объясню, как мы к этому пришли и какие результаты получили.

Хочешь легко войти в айти, иди в тестировщики — распространенный стереотип. И мы столкнулись с ним на практике, когда несколько лет назад начали формировать отдел QA. К нам приходили люди с совершенно разным опытом: выпускники профильных вузов, базовых курсов по тестированию, среди которых были даже врачи и юристы, мечтающие построить карьеру в ИТ. Кто-то смог успешно влиться в команду разработки, почувствовать свой вклад в общее дело, меньше зависеть от действий коллег при выполнении своих задач. А у кого-то это получалось меньше или вообще никак.

Хотя эта ситуация довольно распространенная, важно проанализировать происходящее, чтобы извлечь уроки и увеличить эффективность процесса разработки.

Итак, с одной стороны у нас agile-разработка со свойственной ей спецификой:

С другой стороны, на рынке засилье узкопрофильных QA:

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

Проведем экспресс-опрос.Попробуйте ответить на следующие вопросы:

1. Есть ли у вас в команде по одному QA каждого профиля?

2. Достаточно ли эффективно работает QA на проекте?

3. В команде отсутствуют конфликты между смежными ролями?

4. Удовлетворены ли сами QA результатами своей работы?

5. Всегда ли команда понимает, что делает QA и устраивает ли результат?

Если на все вопросы вы ответили «да», я вам искренне завидую. Если нет, давайте поищем решение.

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

В общем понимании, T-shaped — это специалист обладающий глубокими знаниями в одной области и базовыми знаниями в широком многообразии смежных областей.

Мы адаптировали общий T-shaped профиль для QA специалистов, после чего у нас получилась модель компетенций включающая 3 варианта профиля.

QA-специалист должен обладать глубокими знаниями в одном из трех направлений (вертикальная часть «Т»):

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

Также QA должны иметь общее понимание других областей разработки ПО (горизонтальная часть «Т»). Это методология разработки, формирование требований, особенности архитектуры и применяемые технологии.

Кстати, известный многим создатель Allure Testops в своем недавнем докладе подсветил причины подобной динамики. Но на наш взгляд, нельзя забывать про производственное качество и процессы. Ведь предотвратить баг всегда дешевле, чем исправить.

Профессиональное развитие по T-shaped модели позволяет QA-инженерам вносить ценный вклад на всех этапах разработки и обеспечивать комплексный подход к качеству продукта.

На рынке мало специалистов с подобным навыками, поэтому логичным решением стала прокачка T-shaped профиля тестировщика внутри компании.

Мы начали строить свою модель обучения для QA и «зашили» в нее теорию тестирования и тест-дизайн, общие технические знания, инструменты, автоматизацию и ЯП, процессы разработки и многое другое. Кроме того, сформировали прозрачную систему грейдов и скилов для QA и условились ее поддерживать, следуя за трендами в технологиях и инструментах.

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

Развиваясь в рамках принятой модели, QA-специалисты всех видов и грейдов получают следующие преимущества:

Наш подход в построении QA-команды в «Вебпрактик» и ее развитии по T-shaped модели показал себя с положительной стороны. Да, он оказался многоступенчатым и трудозатратным, но в итоге мы сформировали четкое понимание, куда мы движемся.

Если коротко, скорее, да. Спрос на технически прокаченных и разносторонних QA-инженеров растет. Kuber, Docker, Redis, Kafka, SQL для QA — уже норма. Спецы, пишущие автотесты на Typescript, уже не вызывают удивления. И эффективность T-shaped QA обычно выше, а им самим работать интереснее несмотря на то, что поначалу бывает сложно и больно.

Подходит ли такой профиль для всех QA? Думаю, не для всех. На QA курсах кому-то до сих пор обещают легкий способ войти в IT, а выходец такого курса совсем не хочет никуда «тишейпиться». А кто-то посредине QA-пути понял, что тяготеет больше к менеджменту, а не к инженерии. Но умения добывать, систематизировать и применять новые знания всегда будут в тренде. Так почему бы не прокачивать эти навыки уже сейчас!