Почему заказчика важно вовлекать в тестирование и как сделать это правильно?
Когда проект переходит из стадии MVP в активное развитие, у команды появляется чёткая задача: новый релиз не должен уменьшить предыдущий функционал.
Чтобы избежать регресса, важно понимать, какой функционал критичен. Обычно тестировщики ведут чек-листы и сценарии в Google-таблицах, проставляют галочки и фиксируют прохождение тестов. Но для заказчика это — чёрный ящик. Большинство агентств показывают только финальный результат, не раскрывая, как именно проходит тестирование.
Мы поняли, что важно вовлекать заказчика и в этот этап. Чем больше продукт, тем больше времени уходит на регрессионное тестирование — и тем важнее понимать, что именно мы проверяем и зачем.
Если сценарий регрессионного тестирования не согласован с заказчиком, то есть большая вероятность, что кейсы, которые тестировщик считает важными, заказчик с точки зрения бизнеса важными может не считать.
Чтобы этого не происходило, мы сделали тестовую документацию прозрачной и дали заказчику еще один рычаг управления с помощью TMS:
— Заказчик видит, какие сценарии мы тестируем, особенно при регрессии. — Система формирует наглядные отчёты и графики — не нужно гадать, что проверено. — Тест-кейсы ведутся по стандарту, а не в случайных таблицах.
Заказчик видит, что мы тестируем, и понимает, что для нас означает «протестировано». Мы делаем работу сами, но даём заказчику возможность влиять на процесс. Это и есть добавочная ценность аутсорса. Без прозрачности заказчик либо не доверяет качеству, либо переплачивает. Нас не устраивает ни то, ни другое.
Наша задача — решать проблемы бизнеса, а не создавать новые.
Подробнее о том, как мы сделали QA-прозрачным для заказчика читайте в новой статье на Хабре
