Зачем команде тестирования стремиться к зрелости процессов
Тестирование, как и любая другая деятельность в рамках разработки продукта, требует развития — стремление к зрелости процессов делает работу более эффективной. Но культура тестирования в российских IT-компаниях только формируется, и QA-направление нередко остается без должного внимания. Специалисты годами работают по привычным шаблонам, рискуя качеством продукта и его конкурентоспособностью.
QA Lead IT Test Андрей Бракоренко рассказал, по каким сценариям тестирование может развиваться внутри компании, какие признаки указывают на зрелость тестирования, зачем менять процессы, если все и так работает «нормально», и какую роль во всем этом играет TMS.
Сценарии развития тестирования
Стадии развития тестирования зависят от сценария, по которому развивается сам проект, и от роли QA-направления в его рамках. QA может быть полноценной частью проекта или привлекаться по необходимости как дополнительный сервис.
В первом случае процессы тестирования обычно эволюционируют вместе с продуктом и требованиями к нему. Отвечать за обеспечение качества в стартапе поначалу могут разработчики или проджект-менеджеры — это дешевле, чем нанимать отдельных специалистов. Затем продукт усложняется, и прежний подход становится невозможным без рисков потери времени и качества. Команда приглашает в штат QA-инженера, который описывает необходимые наборы проверок, тестирует и ведет документацию, достаточную для покрытия текущего объема задач. Часто используются только чек-листы, кейсов может не быть вообще, а баги в небольших командах могут описываться и сразу устраняться в чатах без формализации жизненного цикла бага в трекере задач.
На следующем этапе развития проекта к команде присоединяется QA-лид, который развивает тестирование как полноценную часть жизненного цикла продукта. Команда начинает уделять внимание однозначности и полноте отчетности, метрикам качества и прослеживаемости процедур тестирования. Именно на этой стадии TMS становится жизненно необходима как инструмент контроля качества, а на канбан-доске появляются отдельные столбцы для QA. Теперь тестирование можно характеризовать как зрелое, потому что оно становится полноценным сервисом внутри продуктовой разработки.
Второй сценарий реализуется в небольших продуктовых компаниях, которым нужны только приемочные тесты во время крупных изменений. Команда может состоять из проджект-менеджера, одного-двух разработчиков и лида — содержать крупный штат нет смысла, поэтому тестировщиков берут на аутсорс или аутстаф. При таком сценарии говорить о стадиях развития тестирования в компании не получится, потому что QA-направление не существует здесь как постоянная часть разработки. Но подобный проект может начать движение по первому пути, если команда решит, например, создать новый масштабный функционал, для которого понадобятся тестировщики на постоянной занятости. Тогда QA придется встраивать в процессы соответственно этапам, описанным выше.
Признаки зрелых процессов тестирования
Главный признак того, что тестирование в компании доросло до зрелого состояния — ориентир QA-лидов и проджектов на метрики качества. Главная метрика здесь — показатель количества багов с приоритетом выше среднего (о том, какие еще бывают метрики в тестировании, мы рассказывали в материале на VC.ru).
Второй признак — привлечение тестировщиков в проект еще на этапе планирования задач и архитектурных решений. QA-инженеры участвуют в написании и валидации документации, составляют кейсы задолго до того, как приступят к тестированию, а также принимают решение о готовности выхода функционала в прод.
Третий признак — однозначность и визабилити процесса тестирования. Все участники команды понимают, зачем тестирование нужно и в каких случаях к нему нужно обращаться, а также ожидают от тестирования конкретной информации:
-сколько времени уйдет на тестирование;
-какие тесты понадобятся для проверки соответствия продукта требованиям;
-на каком окружении будут осуществляться проверки;
-каковы критерии завершения тестирования.
Зачем менять процессы, если все и так работает «нормально»
Критерии того, что считается «нормальной» работой проекта или продукта, формируются совокупностью метрик и требований к качеству. Невозможно сделать объективные выводы о том, что всё действительно работает удовлетворительно, если не ориентироваться на них и не учитывать лучшие практики рынка и степень удовлетворенности клиентов.
Привычка работать по одним и тем же шаблонам может сыграть с продуктом злую шутку: команда рискует не обратить внимание на изменения в метриках, рыночной ситуации и стандартах качества просто потому что не отслеживает эти показатели или не знает об их существовании.
Только ориентируясь на метрики и требования к качеству, можно делать выводы, достигло ли тестирование необходимой проекту степени зрелости, и какие изменения необходимо произвести, чтобы считать тестирование зрелым.
Внедрение TMS обязательно для зрелого тестирования?
Даже крупные проекты могут не использовать TMS. Объяснить это можно тем, что система управления тестированием — не самый дешевый продукт, причем не столько с точки зрения средств, выделенных на подписку и внедрение, сколько с позиции ресурсов на его использование. Эксплуатация TMS — это время, затраченное на написание и поддержку кейсов, выстраивание архитектуры тестовых наборов, сбор метрик и отчётности, а это время тоже оплачивается специалистам.
Некоторые команды предпочитают каждую свободную минуту вкладывать непосредственно в само тестирование, а не иные процедуры QA, и таким образом они рискуют. Каждому QA-специалисту известна формула: исправление дефекта, найденного на стадии продакшена, в 150 раз дороже исправления дефекта, найденного на ранних стадиях. TMS — это инструмент, который минимизирует возможность пропуска багов посредством унификации проверок и сбора метрик. А это в конечном счете помогает не рисковать качеством и репутацией продукта.
Действительно ли внедрение TMS обойдется дороже исправления ошибок в будущем? Решать команде.
