Что делать, если на отдел QA попадает много UI-тестов? Отвечает эксперт

Добрый день, коллеги!

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

Вопрос от слушателя:

Есть отдел QA, который радеет за качество продукта, есть бизнес, радеющий за выполнение бизнес-целей, чтобы продукт не отставал от конкурентов. И есть некий внешний отдел разработки, чья задача — реализовать по agile пожелания заказчика. Продукт развивают, все работают. В один прекрасный момент отдел QA видит, что на него попадает очень много UI-тестов, и задает сам себе закономерный вопрос: а почему команде не написать апи-тесты, почему разработчикам не написать unit-тесты для продукта, чтобы уменьшить время тестирования.

Мой вопрос вот в чем: прежде чем вынести этот вопрос на ретро, где бизнес может вполне культурно отморозиться, нужно найти какое-то SLA, по которому работает внешняя компания, или какого-то человека, кто должен отвечать за данную активность и может ее реализовать? Как это обычно происходит в командах, поделитесь опытом\рекомендациями, пожалуйста?

Отвечает автор и тренер курса «Аудит и оптимизация QA-процессов» Олег Грабко

А внешняя команда разработки радеет за продукт?

Вы акцентировали внимание на здоровых целях бизнеса и QA-команды, а разработчики остались без такой ремарки. Вопрос риторический, просто обращаю ваше внимание.

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

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

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

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

1. Пообщался с разработкой (в идеале старшим разработчиком/тимлидом):

• Пишут ли они юниты?
• Если не пишут, то почему было принято такое решение?
• Проверяют ли они каким-либо образом продукт, прежде чем отдать вам его в тест?
• А как, если «да»?
• Предварительно обсудил их реакцию на необходимость обвязывать код юнитами (чтобы когда в паблик выносить предложение, знать примерное мнение на сей счет коллег из разработки)

2. Посмотрел статистику возвратов на доработку кода, ввиду наличия блокирующих тестирование ошибок (особенно на предмет тех, которые вылезают в момент первого запуска/воспроизведения основного бизнес-сценария).

3. Подготовил аргументацию — почему юнит-тесты нам нужны (в том числе и экономический фактор: сэкономит на этом бизнес время/деньги или нет), и вынес бы это на обсуждение. Обязательно состоятельную аргументацию, с цифрами, прогнозами (а не гипотетическое «будет полезно», если мы что-то хотим внедрить, в первую очередь мы должны знать:

а) что решаем, какую проблему

б) зачем / надо вообще ее решать?

в) как (почему именно таким подходом)

г) какой прогноз успеха/выгоды ).

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

Договориться о том, кто со стороны разработки отвечает за эту активность (насколько понимаю, для вас это закрытая «кухня», соответственно мы можем оценивать только по результату).

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

—
Внедрение API+UI это уже больше разговор для QA-команды+бизнеса, но алгоритм действий будет тот же. Сначала нужно убедиться, что мы действительно получим из этого пользу, далее – продать это своей команде и бизнесу, а дальше уже смотреть структуру и знания QA-команды на предмет обеспечения практики (в т.ч. во избежание избыточности покрытия)

Курсы для руководителей тест-команд от «Лаборатории Качества»:

1. Для тех, кто только собирается стать тест-менеджером, а также с опытом 1-2 года

«Школа тест-менеджеров V-2.0»

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

Чтобы понять, необходим ли вам этот курс, пройдите этот тест

Мы открыли первый вебинар этого курса

2. Курс «Аудит и оптимизация QA-процессов», будет полезен для:

• руководителей отделов тестирования,
• QA-менеджеров,
• тест-лидов.

За 6 недель, применяя выработанные нами алгоритмы, научитесь:

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

Посмотрите первый вебинар курса