Home

Автор: Елена Шамхалова

Оригинальная публикация

Регрессионное тестирование – это набор тестов, направленных на обнаружение дефектов в уже протестированных частях приложения.

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

Как это было

На проекте поменялась команда — к нам пришли новые сотрудники. Их погружение в проект мы начали с двухнедельной сессии, где каждый день был посвящён определённой теме. Таким образом, опытные сотрудники ежедневно рассказывали про функционал тестируемого ПО и задачи, которые необходимо решать. После чего новички самостоятельно выполняли задачи и проходили тест-кейсы.

На момент обучения наших новичков на проекте новые поставки появлялись примерно раз в месяц. Требовалось проводить регресс, который состоит из 400-500 тест-кейсов, а на его прогон выделялось 4-5 дней. Естественно, нам не всегда хватало этого времени, ведь новые сотрудники проходили кейсы не так быстро.

Нажмите на картинку для увеличения

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

Наш коллективный разум после мозгового штурма создал следующую модель оптимизации процесса:

1. Задачи между ребятами распределяем по принципу SMART, и это, пожалуй, стало самым сложным. Заранее обговариваем с заказчиком, что блоки, закрепленные за сотрудниками, могут меняться от регресса к регрессу.

Нажмите на картинку для увеличения

2. Проводим (и по сей день) еженедельные обучающие 15-тиминутки, чтобы поделиться с командой новыми знаниями, рассказать об интересных кейсах и зависимостях.

Нажмите на картинку для увеличения

3. Создаем тестовые сущности при помощи SOAP UI, что сокращает время создания на 50%! Заодно и интеграционное тестирование прокачиваем. Как это реализовано? Очень просто: мы завели таблицу, которую заполняем перед самым регрессом. В ней ребята пишут, какие сущности и в каком количестве им понадобятся, а кто-то один сразу их генерирует, на выходе предоставляя заказчикам сущностей их айдишники!

Нажмите на картинку для увеличения

4. Всегда помним, что около 30% кейсов с высоким приоритетом могут закрыть наши автоматизаторы. Честь им и хвала.

Таким образом, мы не просто смогли реализовать поставленную цель (уложиться в три дня), а сократили общее время проведения регресса до 1 дня! Надо ли после этого уточнять, что заказчик был в восторге? Оптимизация процесса дала нам такой результат, на который на старте мы даже и не рассчитывали. Так проблема превратилась в задачу, решение которой показало нашу готовность к покорению новых вершин и возможности нашего коллектива.

А ещё мы успели протестировать кейсы от бизнеса, получить много добрых отзывов от заказчиков и поисследовать продукт по нашим “домашним” мнемоникам. Кто молодец?

Нажмите на картинку для увеличения

Обсудить в форуме