Что значит регрессивное тестирование

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

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

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

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

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

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

Регрессионное тестирование (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]

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

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

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

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

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

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

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

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

Фредерик Брукс в своей книге «Мифический человеко-месяц» (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 инженеров.

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

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

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

Резюме

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

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

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

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

Источник

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

Регрессионное тестирование — задача, с которой сталкивается каждый тестировщик. Ведь любой предмет после изменений в одном месте может начать ломаться в месте, где раньше работал исправно. То же самое касается и ПО, которое мы тестируем. В этой статье мы чуть-чуть подробнее рассмотрим этот вид тестирования и разберём готовую стратегию, которая поможет сэкономить время, и поддержать качество на нужном уровне.

Что это такое?

Для начала разберём 2 понятия:

Перепроверка (Retest, Defect Validation) — Процесс перепроверки упавших (failed) тестов, связанных с исправленным багом.

Регрессионное тестирование (Regression testing) — Тестирование уже протестированной программы,
проводящееся после модификации для уверенности в том, что процесс модификации не внес
или не активизировал ошибки в областях, не подвергавшихся изменениям. Проводится после
изменений в коде программного продукта или его окружении.

В чём разница?

Оба вида тестирования выполняются после любых изменений в коде продукта или его окружении.

Retest проверяет ранее упавшие тесты со статусом Failed .

Regression testing проверят ранее пройденные успешно тесты со статусом Passed c целью удостовериться, что изменения не поломали ранее рабочий функционал.

А зачем это делать?

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

Нашу систему можно представить как сказку о репке.

И вот мы захотели убрать из истории собачку Жучку, чтобы сэкономить количество текста в сказке.

Как фикс, мы убрали её в моменте, где внучка позвала Жучку.

И вот оказалось, что дальше наша история ломается:

• Жучка должна позвать кошку
• Во всех следующих моментах в сказке написано, что Жучка тянет за внучку, а кошка за Жучку.

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

Какие изменения могут повлечь за собой регрессию?

Изменения в коде:

• Новый функционал
• Исправление дефекта
• Рефакторинг кода
• Обновление версий библиотек

Изменения в окружении:

• Переход на другой сервер или базу данных
• Обновление версии сервера или базы данных
• Изменения в сторонних системах, с которыми интегрируется наше приложение

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

Поэтому регрессионные тесты являются одним из первых кандидатов на автоматизацию.

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

Время — это одно из главных наших ограничений.

Поэтому в зависимости от времени мы делаем либо полную регрессию (Complete regression), либо частичную (Partial Regression).
С полной регрессией, думаю, вопросов быть не должно. Мы просто выполняем все тесты, которые у нас есть.
А вот с частичной регрессией всё куда интереснее.

Как выбрать достаточное количество тест-кейсов из общего числа? Не будем же мы брать наугад?

Это, наверное, один из самых важных вопросов в тестировании.
Попробуем на него ответить.

Для выбора тестов мы будем опираться на 2 фактора:

• Сила влияния и важность для приложения (Impact)
  1. Часто используемый функционал
  2. Нечасто используемый функционал
• Вероятность возникновения дефекта (Likelihood)
  1. Места, где были изменения
  2. Места, которые связаны с местами, где были изменения
  3. Сложные места
  4. Другие места

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

Например, мы «кровь из носа» должны зарелизиться к определённой дате и у нас очень мало времени на регрессионное тестирование.

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

Если времени чуть больше, то берём ещё и часть нечасто используемого функционала и совмещаем с тестами из пункта 2 в Likelihood.

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

Подытожим:

Retest — перепроверяет упавшие тесты после исправления дефектов.

Regression testing — проверяет ранее положительно пройденные тесты после любых изменений в коде, либо окружении приложения.

Retest & Regression testing нужно делать как можно чаще. Желательно на каждой сборке либо в каждой итерации.

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

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

Понятие «Регрессионное тестирование», в зависимости от контекста использования может иметь разный смысл. Основные типы: регрессия багов, регрессия старых багов, регрессия побочного эффекта. Регрессия багов (англ. Bug regression ) — попытка доказать, что исправленная ошибка на самом деле не была исправлена. Регрессия старых багов (англ. Old bugs regression ) — попытка доказать, что недавнее изменение кода или данных сломало исправление старых ошибок, то есть старые баги стали снова воспроизводиться. Регрессия побочного эффекта (англ. Side effect regression ) — попытка доказать, что недавнее изменение кода или данных сломало другие части разрабатываемого приложения.

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

Регрессионное программирование — часть экстремального программирования. В этой методологии проектная документация заменяется на расширяемое, повторяемое и автоматизированное тестирование всего программного пакета на каждой стадии процесса разработки программного обеспечения. Также регрессионное тестирование может быть использовано для проверки качества программы [Источник 1] [Источник 2] .

Содержание

Типы, виды и направления регрессионного тестирования

Различают два основных типа тестов: функциональные и нефункциональные. Функциональные тесты основываются на функциях, которые выполняет система. Могут проводиться на компонентном, интеграционном, системном и приемочном уровнях. Основные аспекты, по которым проводится тестирование-требования и бизнес-процессы. При работе над требованиями требуется составить список того, что должно быть протестировано. При этом удобно было бы выделить приоритетные детали, чтобы определиться с направлением работы. Это нужно, чтобы не оставить без внимания весь самый важный функционал. При тестировании бизнес-процессов упор делается именно на них, то есть прогоняются сценарии каждодневной работы. Нефункциональные тесты направлены на проверку всех свойств, которые не относят к функциям системы. Из них можно привести такие параметры, как надежность, производительность, удобство, масштаб, безопасность, портативность.

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

Автоматизация регрессионных тестов

Под автоматизированным тестированием программного обеспечения понимают процесс верификации ПО, во время которого основные функции и задачи, такие как запуск, инициализация и выполнение, а также анализ и выдача результатов, проводятся автоматически, с применением соответствующего инструментария. Это действие выполняется техническим специалистом, отвечающим за создание, отладку и поддержку в рабочем состоянии тест-скриптов, тестовых наборов и инструментария. Работа может проводиться с различным программным обеспечением, в том числе и регрессионное тестирование автоматизированных систем.

Регрессия багов

Это подразумевает под собой поиск проблем, которые официально «были устранены», но есть основания полагать, что они до сих пор существуют. Особенность данного вида проверок заключается в том, что необходимо проверять все действия с определённым объектом в различных комбинациях. В первую очередь тестируют соответствие реальности сообщения об устранении проблемы по тому механизму, благодаря которому она была выявлена. Регрессионное тестирование верстки в данном случае помогает удостовериться в отсутствии нежелательных эффектов.

Регрессия старых ошибок

Подразумевает под собой ситуации, когда недавнее изменение кода в одной части приложения сделало нерабочим некоторые или все другие части разрабатываемой программы. В качестве указания о наличии таких проблем служит отсутствие работоспособности в одной или нескольких частях программы. Задача тестера определить все проблемные места [Источник 3] .

Задачи регрессионного тестирования

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

• Проверка и утверждение исправления ошибки;
• Тестирование последствия исправлений, так как внесенные исправления могут привнести ошибку в код который исправно работал;
• Гарантировать функциональную преемственность и совместимость новой версии (релиза, патча) с предыдущими;
• Уменьшение стоимости и сокращение времени выполнения тестов [Источник 4] .

Преимущества и недостатки регрессивного тестирования

Преимущества

• Сокращение количества дефектов в системе к моменту релиза;
• Исключение деградации качества системы при росте функциональности;
• Уменьшение вероятности критических ошибок при эксплуатации.

Недостатки

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

Источник