Как сократить сроки регрессионного тестирования с 3 до 1 дня?

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

Не секрет, что скорость регресса является важным элементом общего процесса:

  • Во-первых, от нее зависит, как быстро мы пофиксим найденные баги;
  • Во-вторых, она влияет на общую скорость релиза;
  • В-третьих, высокая скорость уменьшает общий бюджет проекта.

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

Как это было

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

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


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

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

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

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

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

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

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

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

Об авторе

Работает в Лаборатории качества с 2015 года. На сегодняшний день возглавляет отдел маркетинга и продаж

Поиск
Облако меток
api (5)kpi (1)kpi в тестировании (1)postman (1)rest api (2)scrum (1)scrumban (1)soap api (1)sqa days (1)TDD (1)UX-экспертиза (1)won't fix (1)А/Б тестирование (1)День дарения книг (1)ПОИНТ (2)Приёмочное тестирование (1)автоматизация тестирования (5)аудит (1)аудит тестирования (1)аутсорс (1)баги (4)вакансии (5)варианты использования (1)веб-приложения (1)веб-тестирование (2)верстка (1)граничные значения (1)дедлайн (2)диаграмма Исикавы (1)дополнительные материалы (1)ежемесячный отчет (12)интернет-магазин (1)исследовательское тестирование (2)коммуникации (3)конфликты (1)кроссбраузерное тестирование (1)курсы для тестировщиков (2)лаборатория качества (19)лайф-хаки (3)локализация (1)международные проекты (1)метрики (2)модель ситуационного лидерства (1)мотивация (3)новый год (2)обеспечение качества (7)обучение (6)оптимизация тестирования (13)поздравление (1)поздравления (2)пользовательские истории (1)пример (1)проблемы (1)проектные риски (1)проекты (4)процесс тестирования (24)развитие команды (5)разработчики (1)распределенная команда (3)решения (1)собеседование (1)специализация (2)с чего начать (1)тест-анализ (2)тестирование (44)тестирование безопасности (2)тестирование мобильных приложений (1)тестирование серого ящика (1)тестирование требований (1)тестирование черного ящика (1)тестировщики (10)тестовая документация (1)тестовое покрытие (1)тесты (1)техники тест-дизайна (1)требования (1)удобство использования (2)управление проектами (2)управление рисками (1)успехи (1)целевая аудитория (3)юзабилити (2)
Получите совет