Привет! Я Слава, QA в мобильной разработке СберЗдоровья, и я хочу рассказать о том, как менялись наши процессы тестирования за прошедший год, какие проблемы в связи с этим встречались, и как мы их решали.

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

В начале 2021 на проекте мобильного приложения "СберЗдоровье" у нас было на обе платформы 4 manual QA и 2 автоматизатора.

Приложение большое и обращается к четырем бекендам. В итоге мы тратили неделю на регресс порядка 450 кейсов (ручную проверку каждого экрана и каждой кнопки в новой версии приложения) без передышки, потом 3 дня на ретест багов, часть дня на ручной смоук и пару дней на проверку новых задач и фич. А дальше новый спринт и все с начала. В общем, носились как белки в колесе, а багов не убавлялось. Несколько бизнес-заказчиков приносили всё новые и новые задачи и торопили по срокам. Поэтому к тестированию новых фич мы приступали уже после их разработки, так как нам просто не хватало времени. Кроме того, многие тест-кейсы устаревали, а новые писались медленно. Бесконечный регресс угнетал и все это подрывало наш боевой дух.

Таким образом у нас вырисовывалось 4 крупных проблемы, связанных между собой:

1. Высокая загруженность QA.

2. 50% рабочего времени тратилось на ручной регресс.

3. Большое количество багов в новых фичах.

4. Неактуальная тест-модель.

(Узнали себя?)

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

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

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

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

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

Таким образом, мы пришли к следующим результатам:

1. Сократили время регресса с 5 дней до 4.

2. Сократили число багов в новых фичах в среднем с 30 до 10.

3. Подняли актуальность тест-модели с 50% до 80%.

4. QA больше не чувствуют себя как белки в колесе (по личным ощущениям и отзывам коллег).

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