Как Подели оптимизировал процессы тестирования с Test IT

BNPL-сервис Подели, партнер Альфа-Банка, поделился опытом использования Test IT в процессе трансформирования процессов тестирования. Система управления тестированием помогла ускорить выпуск новых функций и улучшила качество работы, а также стала ключевым инструментом для управления тестированием в условиях быстрого роста и усложняющейся архитектуры. Подробности — в рассказе CTO Подели Андрея Евглевского. 

Как Test IT помогает команде Подели

Подели — партнер Альфа-Банка, предоставляющий сервис BNPL (Buy Now, Pay Later). Сервис оплаты покупок по частям доступен как онлайн, так и в розничных магазинах. В момент покупки необходимо оплатить только 25% стоимости товаров, а остальное — тремя равными платежами без комиссий и переплат. . С момента запуска компания активно растет, уже привлечены более 1,6 миллиона уникальных пользователей, а партнерская сеть расширена до 70 тысяч магазинов.

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

1. Переход на продуктовые команды и изменение структуры тестирования

Изначально тестировщики в Подели были разделены по областям специализации: бэкенд, фронтенд и мобильные приложения, включая Android и iOS, которые работали отдельно друг от друга. Каждая из этих команд тестировала свою часть функциональности, что приводило к дублированию работы и неэффективному использованию ресурсов в случае разработки полнофункциональных фич, затрагивающих одновременно все специализации.

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

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

На время выпуска релиза команды «скидывались» по тестировщику на проведение регрессионного тестирования. Таким образом обеспечивается ротация на регрессе и возникает необходимость единого окна управления регрессом, с ролью которого с успехом справляется Test IT.

2. Использование Test IT для актуализации и систематизации тест-кейсов

До Test IT существовали проблемы с организацией и управлением тест-кейсами — одновременно и оперативно шла разработка MVP системы и построение процессов в разработке и тестировании. Каждый функциональный блок вел собственную коллекцию тестов, и процесс поддержания актуальности тестовой документации был довольно громоздким.

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

В начале переживали, что система не справится с масштабом данных, но Test IT отлично показала себя в плане гибкости и простоты управления большими объемами информации. Мы смогли легко перевести все тесты в единый репозиторий и работать с ними гораздо быстрее.

3. Планирование и управление тестированием с помощью Test IT

Test IT стала ключевым инструментом для планирования и управления тестированием в Подели, особенно в условиях быстрого роста и масштабирования  Одной из ключевых задач было создание «легкого» регрессионного теста, который бы не перегружал команду, но при этом обеспечивал необходимую проверку системы. В Test IT эта задача решалась с помощью гибкого управления наборами тестов, что позволило тестировщикам сосредоточиться на наиболее критичных областях.

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

4. Автоматизация тестирования и улучшение покрытия

Не менее важной задачей для команды стало увеличение покрытия системы автотестами. До внедрения Test IT автотесты использовались, но их было недостаточно для обеспечения высокого уровня стабильности и качества продукта. В начальной стадии автотестирование в основном было направлено на интеграционные тесты, и, хотя система развивалась, покрытие было ограниченным.

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

Стандартно во время проведения регресса делается два прогона: при первом прогоне выявляются проваленные тест-кейсы (например, из-за новых изменений функциональности) по дашборду из Test IT, которые в течение дня правятся. Второй тестран проводится по проваленным ранее кейсам. Оставшиеся после него кейсы проходятся вручную.

На текущий момент покрытие автотестами составляет примерно 93%. Процесс тестирования стал более эффективным, поскольку теперь автотесты запускаются не только на сертификационном стенде, но и на стендах разработчиков — это позволило выявлять ошибки на более ранних этапах. Каждый набор автотестов проходит дважды за время регрессионного тестирования, и благодаря Test IT стало возможным более точно отслеживать метрики, такие как количество упавших тестов.

На данный момент из 392 автотестовых кейсов при релизах падает в среднем лишь 14 тестов. Этот результат удалось достигнуть благодаря меткам и статистике, которые предоставляет Test IT. На ее основе можно корректировать стратегию тестирования и избежать долгих периодов поиска решений.

Результаты и выводы

С переходом на продуктовые команды и внедрением Test IT компания значительно повысила эффективность тестирования. Новый подход позволил существенно сократить время на тестирование, повысить качество работы и ускорить релизные циклы. В результате:

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

• Централизованное управление тестами. Благодаря Test IT все тестовые сценарии были переведены в единый репозиторий, что значительно упростило их актуализацию и улучшило доступность для всей команды.

• Улучшение качества тестирования. Использование Test IT позволило минимизировать избыточность, уменьшить количество ошибок при регрессионных тестах и сделать тестирование более гибким.

• Увеличение покрытия автотестами. Благодаря более атомарной структуре автотестов и улучшенной настройке процессов покрытие системы автотестами составило 93%, а количество упавших тестов при релизах снизилось до 18 из 392.

• Гибкость и прозрачность. Test IT обеспечила гибкость в управлении тестированием на разных этапах разработки и сделало процесс тестирования более прозрачным, что позволило быстрее выявлять и устранять дефекты.