Регрессионное тестирование – это набор тестов, направленных на обнаружение дефектов в уже протестированных частях приложения.
Не секрет, что скорость регресса является важным элементом общего процесса:
- Во-первых, от нее зависит, как быстро мы пофиксим найденные баги;
- Во-вторых, она влияет на общую скорость релиза;
- В-третьих, высокая скорость уменьшает общий бюджет проекта.
Именно поэтому на своих проектах мы непрерывно работаем над сокращением срока проведения регрессионного тестирования. Например, в мае мы проводили очередную итерацию ускорения на проекте по тестированию страхового ПО и теперь можем гордиться достигнутым результатом.
Как это было
На проекте поменялась команда — к нам пришли новые сотрудники. Их погружение в проект мы начали с двухнедельной сессии, где каждый день был посвящён определённой теме. Таким образом, опытные сотрудники ежедневно рассказывали про функционал тестируемого ПО и задачи, которые необходимо решать. После чего новички самостоятельно выполняли задачи и проходили тест-кейсы.
На момент обучения наших новичков на проекте новые поставки появлялись примерно раз в месяц. Требовалось проводить регресс, который состоит из 400-500 тест-кейсов, а на его прогон выделялось 4-5 дней. Естественно, нам не всегда хватало этого времени, ведь новые сотрудники проходили кейсы не так быстро.
Мы поставили ближайшую цель: сократить время на прогон регресса до трёх дней, потому что заказчиком были запланированы поставки нового функционала, и хотелось все успеть.
Наш коллективный разум после мозгового штурма создал следующую модель оптимизации процесса:
1. Задачи между ребятами распределяем по принципу SMART, и это, пожалуй, стало самым сложным. Заранее обговариваем с заказчиком, что блоки, закрепленные за сотрудниками, могут меняться от регресса к регрессу.
2. Проводим (и по сей день) еженедельные обучающие 15-тиминутки, чтобы поделиться с командой новыми знаниями, рассказать об интересных кейсах и зависимостях.
3. Создаем тестовые сущности при помощи SOAP UI, что сокращает время создания на 50%! Заодно и интеграционное тестирование прокачиваем. Как это реализовано? Очень просто: мы завели таблицу, которую заполняем перед самым регрессом. В ней ребята пишут, какие сущности и в каком количестве им понадобятся, а кто-то один сразу их генерирует, на выходе предоставляя заказчикам сущностей их айдишники!
4. Всегда помним, что около 30% кейсов с высоким приоритетом могут закрыть наши автоматизаторы. Честь им и хвала.
Таким образом, мы не просто смогли реализовать поставленную цель (уложиться в три дня), а сократили общее время проведения регресса до 1 дня! Надо ли после этого уточнять, что заказчик был в восторге? Оптимизация процесса дала нам такой результат, на который на старте мы даже и не рассчитывали. Так проблема превратилась в задачу, решение которой показало нашу готовность к покорению новых вершин и возможности нашего коллектива.
А ещё мы успели протестировать кейсы от бизнеса, получить много добрых отзывов от заказчиков и поисследовать продукт по нашим “домашним” мнемоникам. Кто молодец?
