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

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

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

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

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

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

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

Тестировщик с нуля / Урок 5. Что такое регрессионное тестирование и smoke тестирование?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Регрессионное тестирование (Regression testing) | Курс тестирование ПО с нуля — Урок 19 | QA Labs

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

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

Нужно ли нам проходить 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 инженеров.

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

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

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

Резюме

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

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

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

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

Источник: beqa.pro

Антирегрессионное тестирование – минимизируйте затраты

Регрессионное тестирование играет важнейшую роль в разработке продукта и считается непростой задачей. С этим трудно не согласиться, когда вы тестируете то, что уже было протестировано, а потом тестируете это снова. Термин «регрессия» ассоциируется у членов команды с большими усилиями. Мы знаем, насколько головоломным и вместе с тем незаменимым может быть регрессионное тестирование для процесса релиза и спрашиваем «Приведет ли невыполненное регрессионное тестирование к неудовлетворительному результату?» и «Нужно ли проводить регрессионное тестирование, если программа без ошибок – это недостижимая цель?» Что ж, ответом будет «Да! Регрессионное тестирование нужно проводить регулярно».

Что подразумевается под регрессионным тестированием?

На этот вопрос можно ответить одной фразой: «Исправляя одну ошибку, вы привносите в приложение несколько новых ошибок». Регрессионное тестирование – это то, что позволяет обеспечить исправление ошибки без побочных эффектов.
Во время тестирования выявляются некоторые ошибки, при этом разработчики проекта проводят быструю отладку. Тестировщики и разработчики проводят регрессионное тестирование, чтобы исправление ошибок не привело к нарушению функционала приложения.

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

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

Сам термин «регрессионное тестирование» в некотором роде неточен. Правильнее было бы назвать тестирование «антирегрессионным», так как мы выполняем тесты, чтобы проверить, что система не регрессировала (то есть в результате внесения изменений в ней не возникло еще больше ошибок). Точнее говоря, цель регрессионного тестирования состоит в том, чтобы убедиться, что изменение или улучшение кода программы или среды не нарушило функциональность и не создало побочных эффектов.

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

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

Почему с регрессионными дефектами трудно иметь дело?

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

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

Временные сложности: Время регрессионного тестирования приходит после завершения одного этапа разработки и тестирования. По мере приближения сроков выполнения проекта регрессионное тестирование становится серьезным испытанием для команды. У разработчиков остается очень мало времени на исправление ошибок, а у тестировщиков – на проведение повторных функциональных и регрессионных испытаний.

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

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

1. С регрессионным тестированием можно прекрасно справляться путем ревью кода, а также автоматизации как можно большего числа функциональных и нефункциональных сценариев. Каждый раз необходимо стараться избегать переделок. Это трудно сделать при совместной работе большого числа участников, однако можно попытаться исключить доработки.
2. Существенные изменения программы и ошибки – обычные явления в разработке продукта. При необходимости каких-либо доработок необходимо обсудить их на совещании, на котором количество ошибок в регрессионном тестировании сводится к минимуму.
3. Подтвердите каждую ошибку, выявленную в программе, и обсудите ее с членами команды. Это позволяет лучше понять программу и усовершенствовать продукт.
4. Сосредоточьтесь на наиболее частых сценариях использования программного приложения вместо того, чтобы пытаться протестировать все сразу. Например, лучше всего начать с регистрации пользователей, входа пользователей или покупок.
5. В регрессионную проверку следует включать этап исследовательского тестирования, которое помогает обеспечить проведение проверок и работу программного обеспечения в соответствии с пользовательскими ожиданиями.

Сравнение регрессионного тестирования и повторного тестирования

Очень тонкая линия разделяет регрессионное тестирование и повторное тестирование.

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

Автоматизация – ключевой фактор регрессионного тестирования, тогда как повторное тестирование невозможно автоматизировать по причине неопределенности. Проверка дефекта проводится только в рамках повторного тестирования.

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

Регрессионное тестирование рекомендуется выполнять при возникновении следующих событий:

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

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

Другие интересные статьи в нашем блоге (от переводчика):

1. Property-based тестирование с QuickCheck
2. Haskell – хороший выбор с точки зрения безопасности ПО?
3. Как мы выбираем языки программирования в Typeable
4. Язык моделирования Alloy и приключения с параллельными запросами к базе данных

• тестирование
• тесты
• тестирование по
• регрессионное тестирование
• qa
• qa testing
• quality assurance
• testing
• regression testing
• regression
• regression tests

Источник: habr.com

Регрессионное тестирование — это что, где и зачем оно используется?

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

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

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

Такие ошибки могут получаться непреднамеренно. Разработчику дали установки, что исправить — он исправил. А то , что эти исправления могут спровоцировать ошибку в другом месте , может быть совсем не видно. Из этого следует, что регресси онное тестирование — это один из ключевых инструментов для обеспечения качества программы в случае внесения каких-либо исправлений в ее скрипты после уже проведенного удачного тестирования.

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

• исправления багов;
• умышленное изменение кода: добавление, изменение, удаление функций;
• внесение изменений в конфигурацию рабочего окружения: обновили PHP, Java, Linux, Windows, MySQL и т. д.;
• переезд на другие сервер ы ;
• и др.

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

• улучш ение конечно го качеств а программного продукта;
• наличие регрессионных ошибок демонстрирует истинное качество программирования и архитектуры проекта : чем больше ошибок, тем хуже качество кода.

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

Заключение

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

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Источник: codernet.ru