Home

Автор: Фроленков Роман
Оригинал статьи

Привет! Меня зовут Роман Фроленков, я являюсь руководителем группы тестирования QA в компании «Комус-Тех». В нашей команде более 10 внутренних QA-специалистов, а также свыше 15 специалистов из аутсорса, которые работают в составе продуктовых команд.

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

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

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

Работая в QA, я часто сталкивался с проблемой: как объективно оценить трудозатраты на тестирование задач? Не раз замечал, что оценки «на глаз» оказывались неточными. Ведь если заложить слишком много рисков — в релиз попадут не все задачи, а если их не заложить — есть и вовсе риск не успеть провести полноценный регресс или найти дефекты только за несколько часов до релиза.

Вкратце про наш флоу тестирования задач:

1. Создается спецификация, на основе нее создается задача. В рамках данной задачи мы осуществляем тестирование спецификации на предмет ошибок. После завершения проставляем верхнеуровневую оценку.

2. После разработки — в Jira создается задача — QA Task, в рамках которой QA‑специалист начинает тестирование на QA‑стенде своей команды, заводит дефекты, пишет тест‑кейсы.

3. После завершения тестирования и исправления дефектов — задача передвигается далее по статусу и ждет утверждения в составе релиза

4. После утверждения состава релиза — деплоится новая релизная ветка на STAGE стенд, после чего (помимо общего регресса) осуществляется проверка задачи по ранее написанным тест‑кейсам.

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

1️⃣ Оценка на основе спецификации (Оценка на QA-стенд)

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

Изначально я планировал использовать метод распределения работ (или декомпозиции задач)* в сочетании с техникой PairWise — разбиваем спецификацию на детальные требования, оцениваем их среднюю сложность проверки, после чего рассчитываем количество проверок техникой PairWise с учетом платформы, браузеров и т. д., далее высчитываем время ну, и закладываем риск, а также время на написание тест‑кейсов.

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

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

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

Таким образом, для первой точки я выбрал методы эмпирической и сравнительной оценки тестирования* (Методы верхнеуровневой оценки), поскольку детальная оценка требует значительных временных затрат и может быть неэффективной.

Однако для крупных задач, где оценка превышала плюс‑минус 100 человеко‑часов, возникали значительные расхождения между оценкой и фактическими затратами. В таких случаях мы начали использовать метод — Pert анализа (анализ трех точек)*, что позволило нам найти баланс между трудозатратами и качеством оценки.

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

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

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

Решение: метод анализа трёх точек в комбинации с методами эмпирической и сравнительной оценки помогает сбалансировать скорость оценки и её точность.

2️⃣ Оценка после завершения тестирования на QA-стенде (Оценка на STAGE)

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

✔️ Написаны тест-кейсы.
✔️ Заведенные дефекты.
✔️ Чёткое понимание рисков.

Ранее, на данном этапе, оценка проводилась методами эмпирической и сравнительной оценки или высчитывалась в процентном соотношении от времени тестирования на QA, что часто приводило к значительным расхождениям с фактическими затратами.

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

Формула оценки трудозатрат:

Где:

• Tst — общее время тестирования (часы).

• Nтк — количество тест-кейсов (включая регрессионные).

• Kстк — сложность выполнения одного тест-кейса (в среднем 15 минут, но может варьироваться).

• Kр — коэффициент риска (в среднем 15%, но увеличивается для сложных задач, например, с интеграциями).

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

Как мы это автоматизировали?

1. Калькулятор в Confluence
   Мы создали калькулятор (JS + CSS + HTML), встроив его с помощью макроса "HTML" в страницу Confluence. QA-инженерам достаточно ввести значения в поля калькулятора в соответствии с формулой, чтобы мгновенно получить результат.
   

   

2. Обновление Jira

   В каждой задаче появились обязательные для заполнения поля оценки:

   ✔️Оценка задачи (Stage) — заполняется при переводе задачи в следующий статус после тестирования на QA-стенде.

   ✔️Оценка каждого дефекта (Stage) — заполняется при перемещении дефекта по статусам после тестирования на QA стенде.

   После завершения тестирования на QA-стенде, QA-специалист оценивает задачу (QA Task) с помощью формулы и калькулятора, вводя итоговую оценку в соответствующее поле в Jira. Затем он проверяет исправление каждого дефекта (BUG) и вносит оценку в аналогичное поле для каждого дефекта.

   Эти оценки автоматически суммируются и отображаются в отдельном поле User Story, так как QA Task и BUG связаны с единой User Story. Таким образом, итоговая оценка становится доступной всем заинтересованным сторонам.

   На основе этой оценки и наличия ресурса QA у команды (помимо прочих факторов) — принимается решение о включении задач в ближайший релиз.

3. Обязательные тест-кейсы

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

   Эти «одноразовые» тест‑кейсы не проходят ревью, не сохраняются в основном наборе и используются только один раз в рамках релиза. Это решение позволило:

   ✔️Оценивать любую задачу по формуле, после завершения тестирования на QA.

   ✔️Сократить время на погружение другого QA-специалиста, если изначально тестировавший задачу сотрудник находится в отпуске, на больничном или покинул компанию.

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

Результаты

Благодаря данным методам:

• Удалось уменьшить отклонения между прогнозами и фактическими трудозатратами.

• Команда тратит меньше времени на расчёт и согласование оценок, благодаря единому процессу оценки и калькулятору.

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

А как обстоят дела у вас?

Какие подходы вы используете для оценки трудозатрат в QA? Поделитесь своим опытом и инсайтами — возможно, ваши идеи помогут нам улучшить наши процессы!

* Источники и описание методов можно посмотреть здесь: TestGrow

Обсудить в форуме