Что такое регресс в рамках Agile

В Agile принято считать каждую крупицу времени. Как же тогда уместить в спринт регрессионное тестирование, которое может занять чуть ли не большую часть доступных ресурсов?

Agile методология

В последнее время, про Agile в IT слышал каждый. Если вы не слышали, то вкратце напомню. Суть данной методологии, тщательно распланировать задачи на небольшой промежуток времени(спринт) и тем самым точно оценивать свои возможности. С такой методикой планы делаются небольшими шагами и становятся более предсказуемыми и контролируемыми на фоне общей картины проекта. Меньше рисков очень сильно просрочить разработку проекта или погрязнуть в багфиксах. Огромное количество команд уже пытаются или пытались работать по этой методологии, либо по собственной модификации agile. Подробное описание лучше почитать в википедии или книге. Кстати это довольно полезное знание для тестировщика, вам будет намного проще влиться в Agile команду.

Регрессионное тестирование

Думаю не ошибусь если скажу что это самый ненавистный вид тестирования для нас тестировщиков. Довольно неприятно повторять одинаковые тест кейсы, а еще потом точно также перепроверять багфиксы. Тестирование регресса просто убивает весь интерес к процессу и желание к творческому подходу. Причем если у вас большой проект, регрессионное тестирование будет постоянно увеличиваться. Еще объем работ очень сильно зависит от того насколько тщательно браться за этот процесс. Можно заморочиться и  добавить в регресс море тест-кейсов.

Регрессионные тесты

Первый и самый дельный совет — автоматизировать регрессионные тесты. Для этого великолепно подходит Continuous Integration.

В проекте обязательно должны быть

  • Unit тесты
  • Acceptance тесты

Unit тесты это стихия программистов и их обязанность. Еще лучше когда в команде практикуется TDD. Acceptance тесты(приемочные тесты) должны писать тестировщики. Выбирайте язык и фреймворк и начинайте писать, хорошим вариантом можно назвать тесты на Codeception.  Все это должно автоматически запускаться на каждый коммит. Причем тесты должны проходить за короткий промежуток времени.

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

Регрессионный тест сет

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

  • Определяем самые критичные процессы  в проекте
  • Пишем небольшой тест сет для каждого критичного процесса, включающего в себя 5-10 тест-кейсов
  • Проходимся по этому тест сету каждый спринт/релиз
  • Мотивируем разработчиков проходиться по тест сету, если они работают со смежными процессами

Такой подход все равно имеет некоторые минусы

  • Это по прежнему ручные тесты, которыми не очень интересно заниматься
  • Проект может быть настолько сложным, что тест сет может разрастись до немыслимых размеров
  • Тест сет нужно поддерживать и периодически редактировать

Чтобы немного нивелировать эти минусы, попробуйте писать тест-сеты с самым минимальным набором тестов.

Я уверен что такой подход не единственный, и мне очень интересно узнать ваши варианты в комментариях. Спасибо.

3 Комментарии

  1. Прокомментирую только минусы.
    1) Ручные тесты нужно выполнять всегда. Ни один алгоритм (а автотесты — это алгоритмы, выполняемые фреймворками) не застрахован от сбоя и/или появления сайд-эффектов на 100%
    2) и 3) Есть у меня цель, которую еще ни разу за свою практику реализовать не вышло (и тут идет список из 100к отмазок), которая появилась после прочтения книги «как гугл тестирует ПО»: в тестовом фреймворке должен быть заложен «зачаточный искусственный интеллект» — происходить тесты по самопроверке и самовалидации (как подтралливают друзья-программеры, которые не любят юнит-тестирование — нужно писать «тесты на тесты»).

    Подход может и не единственный — но хороший:)

  2. Так и есть. Agile. С десяток acceptance тестов, которые ловят баги на смоуке, и столько же на регрессии. В это время тестировщики по майнд-картам проходят оставшуюся часть регрессии и ловят оставшиеся баги. И почти все перечисленные минусы в наличии 😐

  3. Те же минусы.
    Стараюсь бороться — перекладыванием регрессии на автотесты: исправлять или переписывать автотест, по моему мнению, интереснее, чем повторять кейсы вручную.
    Хотя все не автоматизируешь и количество only-hand кейсов в регрессии — растет.

Добавить комментарий