Регрессионное Тестирование (Regression Testing)

21 июня, 2021

Ты хочешь понять, что такое регрессионное тестирование, зачем оно нужно, почему про него говорят все тестировщики и при чем здесь автоматизация?

Тогда ты в правильном месте 🙂

В этой статье отвечаю на самые частые вопросы, связанные с этим типом тестирования.


Как обычно, начинаем с определений.

Что такое регрессионное тестирование?

Регрессионное Тестирование, Just as I expected..
Регрессионное Тестирование, Just as I expected..

Регрессионное тестирование (regression testing) это проверки ранее протестированной программы, выполняющиеся после изменения кода программы и/или ее окружения для получения уверенности в том, что новая версия программы не содержит дефектов в областях, не подвергавшихся изменениям.

Или в оригинале:

Regression testing — testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its environment is changed. [ISTQB Glossary]


Regression Testing является одним из двух видов тестирования, связанных с изменениями. [ISTQB FL]

Зачем нужно регрессионное тестирование?

Регрессионное тестирование необходимо для получения уверенности, что изменения ПО не коснулись и не сломали другие, не измененные, части ПО.

Say what???
Say what???

Здесь возникает вопрос: “Каким образом изменения одной части ПО могут сломать другие?”

Ответ: это загадка природы 🙂


На самом деле нет)

В мире не бывает идеальных вещей и все мы ошибаемся. ПО и программисты — не исключение. 

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

Особенно часто эта проблема проявляется в проектах с низким уровнем качества кода, плохой архитектурой и большим техническим долгом.


Фредерик Брукс в своей книге «Мифический человеко-месяц» (1975) писал: «Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20–50%) влечёт появление новой». [Куликов С., Базовый курс, 3-е издание]


Можно предположить, что в наше время вероятность появления ошибки — значительно меньше 20-50%, так как программы и среда разработки 1975 года сильно отличаются от современных. 

Но, тем не менее, даже сегодня вероятность ошибки точно больше 0%.

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

Когда проводят регрессионное тестирование?

Регрессионное тестирование проводится после изменения кода программы (добавили / удалили / изменили) или изменения рабочего окружения (обновили версию PHP / Node JS / Java / Ubuntu / Windows / MySQL / MongoDB / переехали на новые сервера и т.п.)


Стоит отметить, что регрессионные тесты не нужно проводить после каждого изменения!

Например, вы изменили дату в футере сайта.

Нужно ли нам проходить 350 тест-кейсов и перепроверять весь сайт? — конечно же нет! Вы потратите свое время зря)

Такие исправления можно протестировать за 10 секунд используя самый простой чек-лист или сделав code review.

Если же такие исправления “ложат” / “ломают” сайт — вам срочно нужно задуматься о профессионализме разработчиков, это не нормально!


Или, другой пример. На одном из полей формы изменяется правило валидации: до этого максимальная длина строки равнялась 20 символам, а теперь нужно сделать 16. 

Зачем после такой правки перепроверять весь сайт? (Вы не поверите, но существуют компании и команды, который до сих пор этим занимаются…) 

Единственное, что нужно проверить — валидацию конкретно этого поля и, возможно, валидацию такого же поля на других формах (если они вообще существуют)

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

Вместо того, чтоб постоянно выполнять бесполезные проверки, лучше нанять более профессионального кодера. Через 2 месяца вы начнете экономить кучу денег.


При принятии решения о необходимости повторного тестирования вспоминаем принципы тестирования и задаем себе вопрос: ЧТО нам нужно проверять после этих изменений?

Какие плюсы регрессионного тестирования?

К плюсам можно отнести:

  • повышение качества продукта (находим и исправляем новые дефекты)
  • регрессионные дефекты показывают реальное качество кода / архитектуры системы и процесса разработки (чем больше дефектов — тем хуже код / процесс)

Выполнение повторного тестирования необходимо для анализа и улучшения качества продукта и рабочих процессов, чем, кстати, и занимаются настоящие QA Engineers.

Какие минусы регрессионного тестирования?

К минусам можно отнести:

  • временные / денежные затраты (дефектов находим мало, времени тратим много, дефекты — “золотые”)
  • рутина (очень немногие получают удовольствие от прохождения одних и тех же тестов по 100500 раз)
  • “замыливание глаз” и парадокс пестицида

Пытаясь бороться с описанными выше минусами многие компании автоматизируют регрессионные проверки 🙂

Но, решает ли автоматизация эти проблемы? Или только усугубляет? Давайте разбираться…

Автоматизация и regression testing

Когда увлекся написанием автотестов…

Регрессионные тесты выполняются много раз и обычно проходят медленно, поэтому такие тесты — это серьезный кандидат на автоматизацию. [ISTQB FL]


На первый взгляд — выглядит логично. Но давайте посмотрим немного “глубже”.

Предположим, у нас есть небольшой проект и 50 тест-кейсов. Мы, после очередного видео / доклада — “Автоматизируй все!” — решаем их автоматизировать 🙂

Через 2 недели все готово: тесты проходят, все зеленое — класс, у нас авто-тесты, Agile и CI! (в видео сказали, что будет так)

Проходит 2 года. Количество тест-кейсов увеличилось в 20 раз, до 1,000. Иии…


Сравнение теоретического “до” и “после”:

До:

  • 50 тестов
  • 1,500$ на написание тестов (1 тест-кейс = 30$)
  • среднее время прогона 50 * 6 сек = 5 минут
  • затраты на 1 тестовый сервер = 200$ / мес

После:

  • 1000 тестов
  • 18,000$ на написание тестов (1 тест-кейс = 20$, стало проще, так как “основа” уже есть, но не 10$ — потому что старые тесты нужно постоянно поддерживать)
  • среднее время прогона 1000 * 6 сек = 100 минут (!!!)
  • затраты на 1 тестовый сервер = 200$ / мес

Решили ли мы проблемы, описанные выше? — нет. 

Возможно, рутины стало чуть меньше. Но остальное — никуда не пропало + появилось новое:

  1. Очень высокие затраты на тестирование (автоматизаторы, сервера, поддержка, новые инструменты и т.п.)
  2. Очень большое время “прогона” 
  3. Парадокс пестицида никуда не делся…

Теоретически, мы можем уменьшить время прогона, купив более мощные сервера, или подняв кластер (привет новый DevOps), но это сделает затраты еще большими…

И здесь появиться финансовый вопрос — а не дешевле ли нам иметь 5 джунов, которые будут проходить регрессионные тест-кейсы изо дня в день, за те же 100 минут? (Знакомо, да? Мы вернулись туда, откуда начали)

Парадокс автоматизации? Наверное, можно так сказать 🙂 

Пытаясь уменьшить затраты — мы сделали их еще больше!


Давайте вспомним, что регрессионные тесты — это серьезный кандидат на автоматизацию. 

Но! Серьезный кандидат != 100% автоматизация!

Поэтому, учитывая все, написанное выше, мы можем предложить решение проблем и сделать следующие выводы:

  • Автоматизировать тесты нужно, но с умом
  • Каждый тест-кейс, который автоматизируется, должен быть оценен с финансовой точки зрения (= экономить ресурсы)
  • Отбор теста в регрессию — должен быть обдуманным процессом (ведь каждый новый тест-кейс увеличит время прогона)
  • Запуск автоматизированных проверок — должен быть “умным”. Мы не должны перепроверять весь сайт и ждать 10-15-50 минут после нескольких правок в тексте!

Все эти проблемы решаются только настоящими специалистами, включая QA лидов, автоматизаторов и DevOps инженеров. 

Поэтому в следующий раз хорошенько подумай, перед тем, как “автоматизировать все”.

И помни, что работа любого специалиста должна быть направлена на повышение эффективности работы и качества продуктов компании, а не на увеличение ее финансовых затрат! 

Псс.. Несколько инструментов тестировщика, которые точно помогут тебе стать более эффективными, без автоматизации)

Резюме

Stay strong!

В статье мы детально ознакомились с одним из типов тестирования, связанного с изменениями, а именно регрессионным тестированием. 

Мы узнали что это такое, зачем оно необходимо, какие у него «плюсы» и «минусы», и что нам “готовит” автоматизация таких тест-кейсов.

Если у тебя есть вопросы / предложения / замечания — пиши нам!)


Если тебе интересна эта тема, и ты хочешь получать актуальную информацию о тестировании — подписывайся на наш Телеграм канал, там интересно: статьи, тесты, опросы, нет спама! 🙂

🔥 Присоединяйся к 4,014
тестировщикам в Телеграм!