Привет! Я Слава, QA в мобильной разработке СберЗдоровья, и я хочу рассказать о том, как менялись наши процессы тестирования за прошедший год, какие проблемы в связи с этим встречались, и как мы их решали.
Я думаю, многие из вас заметили, что в IT-среде изменения происходят быстро. а из-за пандемии и различных ограничений они стали еще быстрее, поэтому я не удивлюсь, если некоторые описанные мною кейсы будут похожи на ваши ситуации в компаниях.
В начале 2021 на проекте мобильного приложения "СберЗдоровье" у нас было на обе платформы 4 manual QA и 2 автоматизатора.
Приложение большое и обращается к четырем бекендам. В итоге мы тратили неделю на регресс порядка 450 кейсов (ручную проверку каждого экрана и каждой кнопки в новой версии приложения) без передышки, потом 3 дня на ретест багов, часть дня на ручной смоук и пару дней на проверку новых задач и фич. А дальше новый спринт и все с начала. В общем, носились как белки в колесе, а багов не убавлялось. Несколько бизнес-заказчиков приносили всё новые и новые задачи и торопили по срокам. Поэтому к тестированию новых фич мы приступали уже после их разработки, так как нам просто не хватало времени. Кроме того, многие тест-кейсы устаревали, а новые писались медленно. Бесконечный регресс угнетал и все это подрывало наш боевой дух.
Таким образом у нас вырисовывалось 4 крупных проблемы, связанных между собой:
Высокая загруженность QA.
50% рабочего времени тратилось на ручной регресс.
Большое количество багов в новых фичах.
Неактуальная тест-модель.
(Узнали себя?)
Тогда мы стали думать, как же решить эти неприятности, чтобы наша жизнь стала лучше, а в приложении было меньше багов.
В скором времени мы наняли двух новых QA. Да, это не целевое решение, но, все же, нагрузка немного распределилась, и времени на регресс мы стали тратить меньше. Однако, процессы все еще никак не изменились, и новые задачи мы встречали уже влитыми в мастер-ветку. Естественно, с парой десятков багов и недоработок.
Тогда к нам пришла мысль внедрить тест-анализ на этапе грумминга задач, чтобы QA подключались к работе как можно раньше (времени, свободного от регресса, ведь стало побольше). В рамках тест-анализа помимо прочего мы составляли чек-лист экранов новой фичи и их взаимосвязь с другими модулями приложения, а также риски и потенциальные проблемы, которые могут привести к увеличению сроков проекта, финансовым и репутационным проблемам компании. И действительно, часть проблем подсвечивалась нами еще до начала кодинга, на этапе дизайна (по нему, кстати, баги мы тоже встречали и репортили).
Отлично, багов стало меньше, нагрузка распределилась и все счастливы. Однако, проблема с актуальностью тест-модели все еще осталась.
Чтобы это исправить, мы попросили менеджеров выделить нам 20% рабочего времени на работу с техдолгом, по аналогии с разработчиками. И эти 20% мы использовали для обновления нашей документации: тест-кейсов, инструкций по работе с инструментами и настройки окружения.
Таким образом, мы пришли к следующим результатам:
Сократили время регресса с 5 дней до 4.
Сократили число багов в новых фичах в среднем с 30 до 10.
Подняли актуальность тест-модели с 50% до 80%.
QA больше не чувствуют себя как белки в колесе (по личным ощущениям и отзывам коллег).
Такой вот небольшой и непростой путь прошли мы на пути к улучшению наших процессов. Пусть наш опыт окажется полезным кому-то из вас и поможет решить похожие ситуации в будущем.
