КАК НЕ ОКАЗАТЬСЯ НЕНУЖНЫМ

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

Вопрос:
Я руководитель отдела контроля качества, отвечаю за тестирование в компании и за поддержку продукта. Передо мной поставили задачу перейти к continuous delivery, чтобы были возможно ежедневные релизы. Сейчас у нас цикл разработки длится две недели, релизим один раз в начале каждой недели - итого 2 раза за цикл. Тестирование задач перед релизом преимущественно делается qa командой + запуск автоматизированного набора регрессионных тестов. У нас сейчас 4 продуктовых команды, но 2 выделенных qa. Мы делим ресурсы между остальными продуктовыми командами. Также у нас есть qa automation expert, который занимается только созданием и поддержкой автоматизированных UI e2e тестов на основе сценариев от ручного тестирования, которые в цикле разработки создают qa в продуктовых командах.

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

Как организовать процесс continuous delivery, чтобы qa команда осталась в компании, команды разработки могли быть более автономны от выделенных им qa и руководство было довольно ежедневными релизами?

Ответ:
Начну с того, что опасения справедливы, но думать про это рановато. Даже если взять курс на тотальную автоматизацию процесса QA, уход в CD, отказ от мануального тестирования, то путь этот, мягко говоря, будет небыстрым. А учитывая ограничения по ресурсам – всего 2 QA + эксперт по автоматизации, то и вовсе может занимать долгие месяцы. Так что в ближайшие 6-12 месяцев можно об этом даже не переживать.

Но, как говорится, планировать – делать что-то сегодня, чтобы добиться результатов завтра. И это правильно, что вы заранее озадачились этим вопросом, чтобы по результатам перехода сделать такую структуру, в которой роль QA останется все еще необходимой. Это нужно закладывать сразу.

Как этого добиться? Я бы предложил плавно трансформировать роль QA с инженера, который проверяет, в инженера, который знает, как надо, и говорит, что проверять. В некоторых командах эта роль называется QA-аналитик. Что он должен делать: анализировать требования, проверять их на непротиворечивость и логичность, готовить тест-кейсы для автоматизаторов, консультировать этих самых автоматизаторов, проверять за автоматизаторами чего они там наавтоматизировали.

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

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

Как по мне, сплошные плюсы и полное Job Security!

P.S.
Если у вас есть своя собственная проблема или свой собственный кейс и вы хотите совершенно бесплатный разбор, пишите в форму