что такое регресс в тестировании
Регресс или регрессив в тестировании
О себе писать не буду (кто я и чем занимаюсь). Моя статья возможно ответит на эти вопросы.
Не могу терпеть эту боль и слышать как неправильно произносят некоторые определения в тестировании.
Да, я — тестировщик. Хотя мои близкие меня постоянно спрашивают — «Ты точно тестировщик? Не похожа!» Очень смешно.
В общем статья сегодня вот о чем. Как правильно говорить — регрессионное или регрессивное тестирование? Как вы сами думаете? Лично я и мои «нормальные» коллеги заняты большую часть времени на работе, проводя регрессионное тестирование. Хм… А может они проводят всё-таки регрессивное тестирование? Пойду-ка спрошу у своих ребят. И вот я в поисках правды провела небольшой опрос среди 20 человек. Опрос легкий с одним вопросом — «привет! ты проводишь регрессивное или регрессионное тестирование?». Большая часть из них сказали «регрессионное», два человека сказали, что это для них одно и тоже, один сказал — «регрессивное». Опроса мне не хватило, и я пошла к знакомой (кандидат филологических наук), спросила про перевод слова «regression». Знакомая сказала, что переводится как регрессия, и скинула скрин вырезки этого перевода из multitran.ru. Оказывается как прилагательное это слово переводится и как «регрессионный», и как «регрессивный».
Недолго думая посмотрела перевод слова «regressive» в этом же сервисе:
После просмотренной информации пришла к выводу, что тому, чем мы занимаемся на работе, больше подходит слово «регрессионное». Поясню. Регрессивный — в моем понимании как в переводе это всё-таки «убывающий» или «уменьшающий» или «действующий в обратном направлении». А регрессионный — «возвращение в исходное или прежнее состояние» или «возврат к более ранней точке развития» (если цитировать предложенные переводы).
Если подойти к этой проблеме с другой более простой стороны и открыть Glossary ISTQB, то при поиске слова «регрессивный» мы ничего не найдем, а при поиске «регрессионный» — найдем определение и несколько совпадений этого слова в других определениях.
Но всё же остаётся проблема — почему некоторые тестировщики говорят «регрессивный»? В этом вопросе мне помогла еще одна моя знакомая, которая недавно читала книгу Романа Савина «Тестирование Dot Com или Пособие по жесткому обращению с багами в интернет-стартапах». Книга очень популярная среди начинающих тестировщиков. Я её тоже в своё время читала. Оказывается в этой книге Савин употребляет слово «регрессивный», как я понимаю вместо «регрессионный». Почему он так делает я не выясняла, но вернулась к своему опросу и вспомнила трех коллег, ответивших «регрессивный». Они — начинающие тестировщики с опытом работы год, меньше года или чуть больше года. Савин по моему мнению поделил тестировщиков не регрессивных и регрессионных!
В чём разница Smoke, Sanity, Regression, Re-test и как их различать?
Оригинал. Перевод разбавлен размышлениями и дополнениями автора из своего опыта
О чём это всё
Будучи инженером по тестированию, вы, вероятно, слышали о таких видах тестирования как «дымовое» (smoke), «санитарное тестирование» (sanity), «ре-тест» и регрессионное тестирование. Вполне возможно, многие из этих видов используются вами на ежедневной основе.
В этой статье я хотел бы внести ясность и объяснить разницу между этими видами тестирования и попробовать разобраться, провести границы (хоть и условные) где заканчивается один вид тестирования, и начинается другой.
Для новичков в тестировании (и даже опытных тестировщиков) разделение этих понятий может быть затруднительно. И в самом деле, как отличить где начинается санити-тестирование и заканчивается smoke? Насколько сильно нам надо ограничить проверку части функциональности системы или её компонентов, чтобы назвать это «дымовым» тестированием? Является ли ввод логина/пароля в пользовательскую форму входа на сайт дымовым тестом, или сам факт её появления на странице сайта уже является пройденным тестом?
Строго говоря, вы всё равно сможете проводить тестирование, даже при том что не сможете точно сказать, в чём же разница. Можно даже не задумываться о разграничении, каким именно видом тестирования вы сейчас заняты. Но всё же, чтобы расти над собой в профессиональном смысле, нужно знать что вы делаете, зачем, и насколько правильно вы это делаете.
Ликбез
Ниже приведены краткие определения видов тестирования, которые мы сегодня сравниваем:
Ну а по существу?
Приведу пример разграничения понятий на моём текущем проекте.
Пример: у нас есть веб-сервис с пользовательским интерфейсом и RESTful API. Будучи тестировщиками, мы знаем:
Подведём итог
Надеюсь, что после чтения данной статьи, у вас появится ясность в определении какой вид тестирования вы используете на каком этапе, и в чём разница между этими видами тестирования. Как и было упомянуто вначале, граница между этими понятиями весьма условная и остаётся на ваше усмотрение в рамках проекта.
UPD:
Часто «тестирование согласованности» или «тестированием на вменяемость», называют термином «санитарное тестирование». Думаю что это пошло из-за фонетических свойств английского слова sanity, схожего по звучанию с чем-то «санитарным». Гугл транслейт вносит ясность. В интернете встречаются оба варианта. Относительно данной статьи прошу считать «санитарное» тестирование как «тестирование на согласованность».
Регрессионное Тестирование (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.
Какие минусы регрессионного тестирования?
К минусам можно отнести:
Пытаясь бороться с описанными выше минусами многие компании автоматизируют регрессионные проверки 🙂
Но, решает ли автоматизация эти проблемы? Или только усугубляет? Давайте разбираться…
Автоматизация и regression testing
Регрессионные тесты выполняются много раз и обычно проходят медленно, поэтому такие тесты — это серьезный кандидат на автоматизацию. [ISTQB FL]
На первый взгляд — выглядит логично. Но давайте посмотрим немного “глубже”.
Предположим, у нас есть небольшой проект и 50 тест-кейсов. Мы, после очередного видео / доклада — “Автоматизируй все!” — решаем их автоматизировать 🙂
Через 2 недели все готово: тесты проходят, все зеленое — класс, у нас авто-тесты, Agile и CI! (в видео сказали, что будет так)
Проходит 2 года. Количество тест-кейсов увеличилось в 20 раз, до 1,000. Иии…
Сравнение теоретического “до” и “после”:
Решили ли мы проблемы, описанные выше? — нет.
Возможно, рутины стало чуть меньше. Но остальное — никуда не пропало + появилось новое:
Теоретически, мы можем уменьшить время прогона, купив более мощные сервера, или подняв кластер (привет новый DevOps), но это сделает затраты еще большими…
И здесь появиться финансовый вопрос — а не дешевле ли нам иметь 5 джунов, которые будут проходить регрессионные тест-кейсы изо дня в день, за те же 100 минут? (Знакомо, да? Мы вернулись туда, откуда начали)
Парадокс автоматизации? Наверное, можно так сказать 🙂
Пытаясь уменьшить затраты — мы сделали их еще больше!
Давайте вспомним, что регрессионные тесты — это серьезный кандидат на автоматизацию.
Поэтому, учитывая все, написанное выше, мы можем предложить решение проблем и сделать следующие выводы:
Все эти проблемы решаются только настоящими специалистами, включая QA лидов, автоматизаторов и DevOps инженеров.
Поэтому в следующий раз хорошенько подумай, перед тем, как “автоматизировать все”.
И помни, что работа любого специалиста должна быть направлена на повышение эффективности работы и качества продуктов компании, а не на увеличение ее финансовых затрат!
Псс.. Несколько инструментов тестировщика, которые точно помогут тебе стать более эффективными, без автоматизации)
Резюме
В статье мы детально ознакомились с одним из типов тестирования, связанного с изменениями, а именно регрессионным тестированием.
Мы узнали что это такое, зачем оно необходимо, какие у него «плюсы» и «минусы», и что нам “готовит” автоматизация таких тест-кейсов.
Если у тебя есть вопросы / предложения / замечания — пиши нам!)
Если тебе интересна эта тема, и ты хочешь получать актуальную информацию о тестировании — подписывайся на наш Телеграм канал, там интересно: статьи, тесты, опросы, нет спама! 🙂
Регрессионное тестирование: цели, подходы, этапы проведения
В данной статье мы расскажем о виде тестирования, который обычно воспринимается как должное и редко вызывает вопросы. Однако, на наш взгляд, руководители ИТ-проектов должны знать, как и для чего проводится регрессионное тестирование. Понимание процесса даст возможность разработать грамотную стратегию, снизить расходы на тестирование и получить продукт высокого качества.
Начнём. Изменения в коде неизбежно сопровождают процесс разработки программного обеспечения. Добавляется новая функциональность, вносятся изменения в существующую, устраняются дефекты. При этом любые изменения могут затронуть уже существующую функциональность, которая исправно работала. Проверить, чтобы изменения не «поломали» рабочее ПО, – задача регрессионного тестирования.
Цель регрессионного тестирования – удостовериться в том, что существующая функциональность не была затронута изменениями в коде.
Приведём пример. Представьте, что ваша команда разработала простое приложение-фонарик. В приложении есть всего две функции: включение и выключение фонарика. Вы проводите тестирование функциональности, чтобы убедиться в правильной работе этих функций и приложения в целом. Результат тестирования положительный – вам не о чем беспокоиться.
Спустя какое-то время вы решаете усовершенствовать приложение, добавив в него функцию включения от того, что пользователь встряхивает телефон. Новая функциональность добавлена, проводится очередной раунд тестирования. Однако на этот раз вам необходимо проверить работоспособность не только новой функциональности, но и включения/выключения. А вдруг изменения затронули и её каким-то образом?
Этот пример демонстрирует место регрессионного тестирования в процессе разработки ПО.
Регрессионное тестирование и методологии управления проектами
Рассмотрим, как на проведение регрессионного тестирования влияет методология проекта. Возьмём для примера три самых популярных: гибкую, каскадную и гибридную.
Гибкая методология (Agile)
Разработка по Agile ведётся короткими итерациями (спринтами), продолжительностью 4–6 недель каждая. В конце каждой итерации заказчик получает готовый продукт, который может выполнять определённые функции. В идеале регрессионное тестирование проводится в конце каждого спринта, но на деле так происходит редко.
В чём трудность? Жёсткие дедлайны и задержки при разработке оставляют меньше времени на тестирование, чем требуется.
Решение. В конце каждого спринта проводится регрессионное тестирование с частичным покрытием, проверяются области, которые с большей долей вероятности могли быть затронуты разработкой. Перед крупными релизами проводится регрессионное тестирование всего продукта.
Каскадная методология (Waterfall)
Каскадная методология предполагает переход к следующему этапу только после полного завершения предыдущего. Таким образом, тестирование начинается после окончания разработки.
В чём трудность? Вносить изменения в готовый продукт – трудоёмкий и дорогостоящий процесс. Неудивительно, что каскадная модель применяется на небольших проектах с чёткими требованиями, которые не меняются в процессе разработки.
Решение. До того как начать процесс разработки, рекомендуется провести тестирование требований и убедиться, что они обладают всеми характеристиками качественных требований: единичностью, актуальностью, выполнимостью и т. д.
Рекомендуем доверять тестирование требований независимым специалистам, которые их объективно оценят и дадут рекомендации по оптимизации. Ведь устранение ошибок в требованиях – это исправление в тексте. Исправление ошибок в готовом продукте – это часы работы разработчиков и тестировщиков.
Гибридная методология
Все преимущества гибкой и каскадной методологий объединила в себе гибридная методология управления проектами. Этапы планирования и определения требований проходят согласно каскадной методологии, а этапы проектирования, разработки, внедрения и оценки – согласно гибкому подходу.
Соответственно, на разных стадиях проекта будет выполняться полное или частичное регрессионное тестирование.
7 стадий регрессионного тестирования
Независимо от того, какой методологии придерживаетесь вы, изменения ПО требуют выполнения регрессионного тестирования, состоящего из следующих стадий:
Каждый дефект вносится в баг-трекинговую систему, описываются шаги для его воспроизведения. Если возможно, описание сопровождается видео, скриншотами.
На этой стадии QA-инженеры проверяют, действительно ли дефект исправлен. Если проблема остается, создаётся новый отчет. В некоторых случаях устранение дефекта подлежит обсуждению. Все критические и значительные дефекты должны быть устранены обязательно, а вот минорные, устранение которых требует больших затрат, могут быть оставлены. Особенно в тех случаях, если пользователю они не видны.
Исходя из опыта команды a1qa, в среднем требуется не менее трёх раундов регрессионного тестирования для устранения всех дефектов и стабилизации приложения.
Регрессионное тестирование: ручное или автоматизированное?
На любом проекте регрессионные тесты – первые кандидаты на автоматизацию. Они запускаются регулярно, в большом количестве. Автоматизация позволяет не только сократить сроки тестирования, но и высвобождает ресурсы для более высокоуровневых задач, исследования приложения.
Однако несмотря на востребованность автоматизации, ручное регрессионное тестирование также имеет место быть.
Ручное тестирование
Внедрять автоматизацию на небольших проектах, которые длятся всего несколько месяцев, не всегда целесообразно: затраты могут не окупиться, а разработка автотестов лишь затянет сроки реализации проекта. В таком случае тестирование проводится вручную без каких-либо особых инструментов, за исключением баг-трекинговой системы, например, JIRA.
Однако если проект разрастается, функциональность ПО увеличивается с каждым последующим релизом, это влечёт за собой увеличение объемов тестирования. В таком случае стоит задуматься о привлечении специалистов по автоматизации.
Автоматизация тестирования
Решение об автоматизации принимает заказчик, а исполнение ложится на плечи профессиональных инженеров по автоматизации, которые обладают необходимым опытом, знают языки программирования.
Выгоду автоматизации тестирования нельзя недооценивать:
Кстати, есть и такие проекты, на которых разумно совместить ручные проверки с автоматизированными. Все зависит от специфики программного продукта.
Подведём итог
Согласно отчёту World Quality Report 2017, в среднем 26% всего ИТ-бюджета компаний идет на тестирование. Опыт компании a1qa говорит о том, что 40–70% этих затрат приходится на регрессионное тестирование.
Если вы переведёте проценты в реальные деньги, то поймете, почему регрессионное тестирование заслуживает вашего внимания и требует тщательно продуманной стратегии. Выбор правильного подхода поможет эффективно обнаружить все проблемные места, устранить их, обеспечить высокое качество программного решения.
Как подобрать стратегию тестирования, оптимальную для вашего ПО? Спросите у нас! Получить бесплатную консультацию QA-специалиста.
Что такое регрессионное тестирование?
Регрессионное тестирование — задача, с которой сталкивается каждый тестировщик. Ведь любой предмет после изменений в одном месте может начать ломаться в месте, где раньше работал исправно. То же самое касается и ПО, которое мы тестируем. В этой статье мы чуть-чуть подробнее рассмотрим этот вид тестирования и разберём готовую стратегию, которая поможет сэкономить время, и поддержать качество на нужном уровне.
Что это такое?
Для начала разберём 2 понятия:
Перепроверка (Retest, Defect Validation) — Процесс перепроверки упавших (failed) тестов, связанных с исправленным багом.
Регрессионное тестирование (Regression testing) — Тестирование уже протестированной программы,
проводящееся после модификации для уверенности в том, что процесс модификации не внес
или не активизировал ошибки в областях, не подвергавшихся изменениям. Проводится после
изменений в коде программного продукта или его окружении.
В чём разница?
Оба вида тестирования выполняются после любых изменений в коде продукта или его окружении.
Regression testing проверят ранее пройденные успешно тесты со статусом Passed c целью удостовериться, что изменения не поломали ранее рабочий функционал.
А зачем это делать?
Так получилось, что любое изменение в коде или окружении нашего приложения может вызвать совсем неожиданные последствия.
Нашу систему можно представить как сказку о репке.
И вот мы захотели убрать из истории собачку Жучку, чтобы сэкономить количество текста в сказке.
Как фикс, мы убрали её в моменте, где внучка позвала Жучку.
И вот оказалось, что дальше наша история ломается:
Так и получается регрессия, когда наш продукт из-за каких-то небольших изменений может очень серьёзно поломаться иногда даже в очень неожиданных местах.
Какие изменения могут повлечь за собой регрессию?
Изменения в коде:
Изменения в окружении:
В идеале, мы должны проводить регрессионное тестирование на каждой новой сборке либо раз в итерацию. Как правило, этот процесс отнимает очень много времени и заставляет грустить многих тестировщиков. Ведь каждый раз нужно проходить одни и те же действия, что делает работу крайне рутинной.
Поэтому регрессионные тесты являются одним из первых кандидатов на автоматизацию.
Как проводить регрессионное тестирование?
Время — это одно из главных наших ограничений.
Поэтому в зависимости от времени мы делаем либо полную регрессию (Complete regression), либо частичную (Partial Regression).
С полной регрессией, думаю, вопросов быть не должно. Мы просто выполняем все тесты, которые у нас есть.
А вот с частичной регрессией всё куда интереснее.
Как выбрать достаточное количество тест-кейсов из общего числа? Не будем же мы брать наугад?
Это, наверное, один из самых важных вопросов в тестировании.
Попробуем на него ответить.
Для выбора тестов мы будем опираться на 2 фактора:
Исходя из наличия времени, берём по одному пункту из каждого фактора в порядке значимости и выбираем тесты, которые им соответствуют.
Например, мы «кровь из носа» должны зарелизиться к определённой дате и у нас очень мало времени на регрессионное тестирование.
В таком случае, мы возьмём тесты, которые проверяют часто используемый функционал и места, где были изменения.
Если времени чуть больше, то берём ещё и часть нечасто используемого функционала и совмещаем с тестами из пункта 2 в Likelihood.
Таким образом, со стратегией регрессионного тестирования можно экспериментировать, добиваясь наилучшего для себя результата с доступными ресурсами.
Подытожим:
Retest — перепроверяет упавшие тесты после исправления дефектов.
Regression testing — проверяет ранее положительно пройденные тесты после любых изменений в коде, либо окружении приложения.
Retest & Regression testing нужно делать как можно чаще. Желательно на каждой сборке либо в каждой итерации.