scrum cross-functional-team

Ручные тестировщики в кросс-функциональной команде: нужны ли они нам?

3 марта 2023 г.

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

Эта статья основана на опыте менеджеров Exadel, которые работали над проектами без ручного контроля качества. Мы обсудим, как команда самостоятельно справлялась с этими заданиями и находила баланс между затратами и ресурсами контроля качества.

Введение

Каждый владелец проекта сталкивается с одними и теми же ключевыми вопросами, когда речь идет об обеспечении качества (QA):

Как сократить расходы по проекту?
Нужен ли мне отдельный тестер программного обеспечения с ручным управлением?
Каковы последствия привлечения ручного тестировщика из команды Scrum в команду разработчиков?
Зачем мне нужен автоматизированный контроль качества в дополнение к ручному или вместо него и как автоматизация снизит стоимость проекта?

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

Почему необходим контроль качества?

Основная цель специалистов по контролю качества — проверить, соответствует ли ваш новый инкремент бизнес-требованиям, и оценить его качество.

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

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

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

Кейс Exadel: как нам добиться успеха без ручного тестировщика

Иногда клиент говорит, что ручной тестер больше не нужен. Заказчик владеет бюджетом и может решить, насколько быстро ему нужен проект, поэтому мы должны решить, что делать дальше с этим новым направлением. Стоит ли экономить деньги и сокращать команду? Полностью отказаться от ручного тестирования? Ответ заключается в том, чтобы разработчики и тестировщики автоматизации (AQA) взяли на себя ручное тестирование.

В этой ситуации AQA и разработчики могут работать вместе. AQA более глубоко разбираются в тест-кейсах, поэтому они несут ответственность за их написание. Разработчик берет тест-кейсы и вручную проверяет инкремент продукта после разработки, но перед передачей задачи на тестирование. Далее AQA пишет автотесты и снова тестирует вручную. Хотя у AQA будет больше работы, это все же возможно.

Мы сделали это в сложном проекте! Мы закончили разработку истории, но не проводили тестирование из-за проблем с емкостью, подводными камнями и оценкой. Поэтому, когда в последний день и без того сложного спринта на нашу AQA посыпались билеты, им нужно было попросить о помощи, и они это сделали. За результат каждого инкремента отвечает вся Скрам-команда, поэтому мы все были готовы помочь. К тому же, поскольку инкремент дошел до тестирования, у нашего разработчика появилось свободное время. Этот подход «попросить о помощи» работает в обоих направлениях; если бы у разработчика было слишком много тикетов, мы бы тоже тут же включились.

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