Что такое регрессивное тестирование
Регресс или регрессив в тестировании
О себе писать не буду (кто я и чем занимаюсь). Моя статья возможно ответит на эти вопросы.
Не могу терпеть эту боль и слышать как неправильно произносят некоторые определения в тестировании.
Да, я — тестировщик. Хотя мои близкие меня постоянно спрашивают — «Ты точно тестировщик? Не похожа!» Очень смешно.
В общем статья сегодня вот о чем. Как правильно говорить — регрессионное или регрессивное тестирование? Как вы сами думаете? Лично я и мои «нормальные» коллеги заняты большую часть времени на работе, проводя регрессионное тестирование. Хм… А может они проводят всё-таки регрессивное тестирование? Пойду-ка спрошу у своих ребят. И вот я в поисках правды провела небольшой опрос среди 20 человек. Опрос легкий с одним вопросом — «привет! ты проводишь регрессивное или регрессионное тестирование?». Большая часть из них сказали «регрессионное», два человека сказали, что это для них одно и тоже, один сказал — «регрессивное». Опроса мне не хватило, и я пошла к знакомой (кандидат филологических наук), спросила про перевод слова «regression». Знакомая сказала, что переводится как регрессия, и скинула скрин вырезки этого перевода из multitran.ru. Оказывается как прилагательное это слово переводится и как «регрессионный», и как «регрессивный».
Недолго думая посмотрела перевод слова «regressive» в этом же сервисе:
После просмотренной информации пришла к выводу, что тому, чем мы занимаемся на работе, больше подходит слово «регрессионное». Поясню. Регрессивный — в моем понимании как в переводе это всё-таки «убывающий» или «уменьшающий» или «действующий в обратном направлении». А регрессионный — «возвращение в исходное или прежнее состояние» или «возврат к более ранней точке развития» (если цитировать предложенные переводы).
Если подойти к этой проблеме с другой более простой стороны и открыть Glossary ISTQB, то при поиске слова «регрессивный» мы ничего не найдем, а при поиске «регрессионный» — найдем определение и несколько совпадений этого слова в других определениях.
Но всё же остаётся проблема — почему некоторые тестировщики говорят «регрессивный»? В этом вопросе мне помогла еще одна моя знакомая, которая недавно читала книгу Романа Савина «Тестирование Dot Com или Пособие по жесткому обращению с багами в интернет-стартапах». Книга очень популярная среди начинающих тестировщиков. Я её тоже в своё время читала. Оказывается в этой книге Савин употребляет слово «регрессивный», как я понимаю вместо «регрессионный». Почему он так делает я не выясняла, но вернулась к своему опросу и вспомнила трех коллег, ответивших «регрессивный». Они — начинающие тестировщики с опытом работы год, меньше года или чуть больше года. Савин по моему мнению поделил тестировщиков не регрессивных и регрессионных!
В чём разница Smoke, Sanity, Regression, Re-test и как их различать?
Оригинал. Перевод разбавлен размышлениями и дополнениями автора из своего опыта
О чём это всё
Будучи инженером по тестированию, вы, вероятно, слышали о таких видах тестирования как «дымовое» (smoke), «санитарное тестирование» (sanity), «ре-тест» и регрессионное тестирование. Вполне возможно, многие из этих видов используются вами на ежедневной основе.
В этой статье я хотел бы внести ясность и объяснить разницу между этими видами тестирования и попробовать разобраться, провести границы (хоть и условные) где заканчивается один вид тестирования, и начинается другой.
Для новичков в тестировании (и даже опытных тестировщиков) разделение этих понятий может быть затруднительно. И в самом деле, как отличить где начинается санити-тестирование и заканчивается smoke? Насколько сильно нам надо ограничить проверку части функциональности системы или её компонентов, чтобы назвать это «дымовым» тестированием? Является ли ввод логина/пароля в пользовательскую форму входа на сайт дымовым тестом, или сам факт её появления на странице сайта уже является пройденным тестом?
Строго говоря, вы всё равно сможете проводить тестирование, даже при том что не сможете точно сказать, в чём же разница. Можно даже не задумываться о разграничении, каким именно видом тестирования вы сейчас заняты. Но всё же, чтобы расти над собой в профессиональном смысле, нужно знать что вы делаете, зачем, и насколько правильно вы это делаете.
Ликбез
Ниже приведены краткие определения видов тестирования, которые мы сегодня сравниваем:
Ну а по существу?
Приведу пример разграничения понятий на моём текущем проекте.
Пример: у нас есть веб-сервис с пользовательским интерфейсом и RESTful API. Будучи тестировщиками, мы знаем:
Подведём итог
Надеюсь, что после чтения данной статьи, у вас появится ясность в определении какой вид тестирования вы используете на каком этапе, и в чём разница между этими видами тестирования. Как и было упомянуто вначале, граница между этими понятиями весьма условная и остаётся на ваше усмотрение в рамках проекта.
UPD:
Часто «тестирование согласованности» или «тестированием на вменяемость», называют термином «санитарное тестирование». Думаю что это пошло из-за фонетических свойств английского слова sanity, схожего по звучанию с чем-то «санитарным». Гугл транслейт вносит ясность. В интернете встречаются оба варианта. Относительно данной статьи прошу считать «санитарное» тестирование как «тестирование на согласованность».
Что такое регрессивное тестирование
Войти
Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal
Регрессионное тестирование
Главной задачей этапа сопровождения является реализация систематического процесса обработки изменений в коде. После каждой модификации программы необходимо удостовериться, что на функциональность программы не оказал влияния модифицированный код. Если такое влияние обнаружено, говорят о регрессионном дефекте. Для регрессионного тестирования функциональных возможностей, изменение которых не планировалось, используются ранее разработанные тесты. Одна из целей регрессионного тестирования состоит в том, чтобы, в соответствии с используемым критерием покрытия кода (например, критерием покрытия потока операторов или потока данных), гарантировать тот же уровень покрытия, что и при полном повторном тестировании программы. Для этого необходимо запускать тесты, относящиеся к измененным областям кода или функциональным возможностям.
Другая цель регрессионного тестирования состоит в том, чтобы удостовериться, что программа функционирует в соответствии со своей спецификацией, и что изменения не привели к внесению новых ошибок в ранее протестированный код. Эта цель всегда может быть достигнута повторным выполнением всех тестов регрессионного набора, но более перспективно отсеивать тесты, на которых выходные данные модифицированной и старой программы не могут различаться.
Важной задачей регрессионного тестирования является также уменьшение стоимости и сокращение времени выполнения тестов.
Виды регрессионного тестирования
Поскольку регрессионное тестирование представляет собой повторное проведение цикла обычного тестирования, виды регрессионного тестирования совпадают с видами обычного тестирования. Можно говорить, например, о модульном регрессионном тестировании или о функциональном регрессионном тестировании.
Другой способ классификации видов регрессионного тестирования связывает их с типами сопровождения, которые, в свою очередь, определяются типами модификаций. Выделяют три типа сопровождения:
• Корректирующее сопровождение, называемое обычно исправлением ошибок, выполняется в ответ на обнаружение ошибки, не требующей изменения спецификации требований. При корректирующем сопровождении производится диагностика и корректировка дефектов в программном обеспечении с целью поддержания системы в работоспособном состоянии.
• Адаптивное сопровождение осуществляется в ответ на требования изменения данных или среды исполнения. Оно применяется, когда существующая система улучшается или расширяется, а спецификация требований изменяется с целью реализации новых функций.
• Усовершенствующее (прогрессивное) сопровождение включает любую обработку с целью повышения эффективности работы системы или эффективности ее сопровождения.
В процессе адаптивного или усовершенствующего сопровождения обычно вводятся новые модули. Чтобы отобразить то или иное усовершенствование или адаптацию, изменяется спецификация системы. При корректирующем сопровождении, как правило, спецификация не изменяется, и новые модули не вводятся. Модификация программы на фазе разработки подобна модификации при корректирующем сопровождении, так как из-за обнаружения ошибки вряд ли требуется менять спецификацию программы. За исключением редких моментов крупных изменений, на фазе сопровождения изменения системы обычно невелики и производятся с целью устранения проблем или постепенного расширения функциональных возможностей
Соответственно, определяют два типа регрессионного тестирования: прогрессивное и корректирующее.
• Прогрессивное регрессионное тестирование предполагает модификацию технического задания. В большинстве случаев при этом к системе программного обеспечения добавляются новые модули.
• При корректирующем регрессионном тестировании техническое задание не изменяется. Модифицируются только некоторые операторы программы и, возможно, конструкторские решения.
Прогрессивное регрессионное тестирование обычно выполняется после адаптивного или усовершенствующего сопровождения, тогда как корректирующее регрессионное тестирование выполняется во время тестирования в цикле разработки и после корректирующего сопровождения, то есть после того, как над программным обеспечением были выполнены некоторые корректирующие действия. Вообще говоря, корректирующее регрессионное тестирование должно быть более простым, чем прогрессивное регрессионное тестирование, поскольку допускает повторное использование большего количества тестов.
Подход к отбору регрессионных тестов может быть активным или консервативным. Активный подход во главу угла ставит уменьшение объема регрессионного тестирования и пренебрегает риском пропустить дефекты. Активный подход применяется для тестирования систем с высокой исходной надежностью, а также в случаях, когда эффект изменений невелик. Консервативный подход требует отбора всех тестов, которые с ненулевой вероятностью могут обнаруживать дефекты. Этот подход позволяет обнаруживать большее количество ошибок, но приводит к созданию более обширных наборов регрессионных тестов.
Управляемое регрессионное тестирование
Для обеспечения управляемости регрессионного тестирования необходимо выполнение ряда условий:
• Как при модульном, так и при интеграционном регрессионном тестировании в качестве модулей, вызываемых тестируемым модулем непосредственно или косвенно, должны использоваться реальные модули системы. Это легко осуществить, поскольку на этапе регрессионного тестирования все модули доступны в завершенном виде.
• Информация об изменениях корректна. Информация об изменениях указывает на измененные модули и разделы спецификации требований, не подразумевая при этом корректность самих изменений. Кроме того, при изменении спецификации требований необходимо усиленное регрессионное тестирование изменившихся функций этой спецификации, а также всех функций, которые могли быть затронуты по неосторожности. Единственным случаем когда мы вынуждены положиться на правильность измененного технического задания, является изменение технического задания для всей системы или для модуля верхнего (в графе вызовов) уровня, при условии, что кроме технического задания, не существует никакой дополнительной документации и/или какой-либо другой информации, по которой можно было бы судить об ошибке в техническом задании.
• В программе нет ошибок, кроме тех, которые могли возникнуть из-за ее изменения.
• Тесты, применявшиеся для тестирования предыдущих версий программного продукта, доступны, при этом протокол прогона тестов состоит из входных данных, выходных данных и траектории. Траектория представляет собой путь в управляющем графе программы, прохождение которого вызывается использованием некоторого набора входных данных. Ее можно применять для оценки структурного покрытия, обеспечиваемого набором тестов.
• Для проведения регрессионного тестирования с использованием существующего набора тестов необходимо хранить информацию о результатах выполнения тестов на предыдущих этапах тестирования.
Обоснование корректности метода отбора тестов
• Некоторые участки кода программы не получают управление при выполнении некоторых тестов.
• Если участок кода реализует требование, но измененный фрагмент кода не получает управления при выполнении теста, то он и не может воздействовать на значения выходных данных программы при выполнении данного теста.
• Даже если участок кода, реализующий требование, получает управление при выполнении теста, это далеко не всегда отражается на выходных данных программы при выполнении данного теста. Действительно, если изменяется первый блок программы, например, путем добавления инициализации переменной, все пути в программе также изменяются, и, как следствие, требуют повторного тестирования. Однако может так случиться, что только на небольшом подмножестве путей действительно используется эта инициализированная переменная.
• Не каждый тест, проверяющий код, находящийся на одном пути с измененным кодом, обязательно покрывает этот измененный код.
• Код, находящийся на одном пути с измененным кодом, может не воздействовать на значения выходных данных измененных модулей программы.
• Не всегда каждый оператор программы воздействует на каждый элемент ее выходных данных
Классификация тестов при отборе
Создание наборов регрессионных тестов рекомендуется начинать с множества исходных тестов. При заданном критерии регрессионного тестирования все исходные тесты подразделяются на три подмножества:
• Множество тестов, пригодных для повторного использования. Это тесты, которые уже запускались и пригодны к использованию, но затрагивают только покрываемые элементы программы, не претерпевшие изменений. При повторном выполнении выходные данные таких тестов совпадут с выходными данными, полученными на исходной программе. Следовательно, такие тесты не требуют перезапуска.
• Множество тестов, требующих повторного запуска. К ним относятся тесты, которые уже запускались, но требуют перезапуска, поскольку затрагивают, по крайней мере, один измененный покрываемый элемент, подлежащий повторному тестированию. При повторном выполнении такие тесты могут давать результат, отличный от результата, показанного на исходной программе. Множество тестов, требующих повторного запуска, обеспечивает хорошее покрытие структурных элементов даже при наличии новых функциональных возможностей.
• Множество устаревших тестов. Это тесты, более не применимые к измененной программе и непригодные для дальнейшего тестирования, поскольку они затрагивают только покрываемые элементы, которые были удалены при изменении программы. Их можно удалить из набора регрессионных тестов.
• Новые тесты, которые еще не запускались и могут быть использованы для тестирования.
Классификация тестов по отношению к изменениям в коде требует анализа последствий изменений. Тесты, активирующие код, затронутый изменениями, могут требовать повторного запуска или оказаться устаревшими. Чтобы тест был включен в класс тестов, требующих повторного запуска, он должен быть затронут изменениями в коде, а также должен способствовать увеличению степени покрытия измененного кода по используемому критерию. Затронутым элементом теста может быть траектория, выходные значения, или и то, и другое. Чтобы тест был включен в класс тестов, пригодных для повторного использования, он должен вносить вклад в увеличение степени покрытия кода и не требовать повторного запуска.
Степень покрытия кода определяется для тестов, пригодных для повторного использования, поскольку к этому классу относятся тесты, не требующие повторного запуска и способствующие увеличению степени покрытия до желаемой величины. Если имеется компонент программы, не задействованный пригодными для повторного использования тестами, то вместо них выбираются и выполняются с целью увеличения степени покрытия тесты, требующие повторного запуска. После запуска такой тест становится пригодным для повторного использования или устаревшим. Если тестов, требующих повторного запуска, больше не осталось, а необходимая степень покрытия кода еще не достигнута, порождаются дополнительные тесты и тестирование повторяется.
Окончательный набор тестов собирается из тестов, пригодных для повторного использования, тестов, требующих повторного запуска, и новых тестов. Наконец, устаревшие и избыточные тесты удаляются из набора тестов, поскольку избыточные тесты не проверяют новые функциональные возможности и не увеличивают покрытие.
Возможности повторного использования тестов
К изменению существующих тестов могут привести три следующих вида деятельности программистов:
• Создание новых тестов.
• Выполнение тестов.
• Изменение кода.
Поскольку каждый тест содержит входные данные, выходные данные и траекторию, эти компоненты могут подвергнуться изменению в любой комбинации. При изменении входных данных существующего теста будем считать, что старый тест прекращает существование, и создается новый тест. Таким образом, к числу разрешенных изменений теста относятся всевозможные пертурбации выходных данных или траекторий. Изменение выходных данных без изменения траектории и/или входных данных невозможно. Следовательно, существует только два возможных варианта изменения теста: изменение траектории или изменение траектории и выходных данных.
Классификация выборочных методов
Для проверки корректности различных подходов к регрессионному тестированию используется модель оценки методов регрессионного тестирования. Основными объектами рассмотрения стали полнота, точность, эффективность и универсальность.
Регрессионное тестирование: цели, подходы, этапы проведения
В данной статье мы расскажем о виде тестирования, который обычно воспринимается как должное и редко вызывает вопросы. Однако, на наш взгляд, руководители ИТ-проектов должны знать, как и для чего проводится регрессионное тестирование. Понимание процесса даст возможность разработать грамотную стратегию, снизить расходы на тестирование и получить продукт высокого качества.
Начнём. Изменения в коде неизбежно сопровождают процесс разработки программного обеспечения. Добавляется новая функциональность, вносятся изменения в существующую, устраняются дефекты. При этом любые изменения могут затронуть уже существующую функциональность, которая исправно работала. Проверить, чтобы изменения не «поломали» рабочее ПО, – задача регрессионного тестирования.
Цель регрессионного тестирования – удостовериться в том, что существующая функциональность не была затронута изменениями в коде.
Приведём пример. Представьте, что ваша команда разработала простое приложение-фонарик. В приложении есть всего две функции: включение и выключение фонарика. Вы проводите тестирование функциональности, чтобы убедиться в правильной работе этих функций и приложения в целом. Результат тестирования положительный – вам не о чем беспокоиться.
Спустя какое-то время вы решаете усовершенствовать приложение, добавив в него функцию включения от того, что пользователь встряхивает телефон. Новая функциональность добавлена, проводится очередной раунд тестирования. Однако на этот раз вам необходимо проверить работоспособность не только новой функциональности, но и включения/выключения. А вдруг изменения затронули и её каким-то образом?
Этот пример демонстрирует место регрессионного тестирования в процессе разработки ПО.
Регрессионное тестирование и методологии управления проектами
Рассмотрим, как на проведение регрессионного тестирования влияет методология проекта. Возьмём для примера три самых популярных: гибкую, каскадную и гибридную.
Гибкая методология (Agile)
Разработка по Agile ведётся короткими итерациями (спринтами), продолжительностью 4–6 недель каждая. В конце каждой итерации заказчик получает готовый продукт, который может выполнять определённые функции. В идеале регрессионное тестирование проводится в конце каждого спринта, но на деле так происходит редко.
В чём трудность? Жёсткие дедлайны и задержки при разработке оставляют меньше времени на тестирование, чем требуется.
Решение. В конце каждого спринта проводится регрессионное тестирование с частичным покрытием, проверяются области, которые с большей долей вероятности могли быть затронуты разработкой. Перед крупными релизами проводится регрессионное тестирование всего продукта.
Каскадная методология (Waterfall)
Каскадная методология предполагает переход к следующему этапу только после полного завершения предыдущего. Таким образом, тестирование начинается после окончания разработки.
В чём трудность? Вносить изменения в готовый продукт – трудоёмкий и дорогостоящий процесс. Неудивительно, что каскадная модель применяется на небольших проектах с чёткими требованиями, которые не меняются в процессе разработки.
Решение. До того как начать процесс разработки, рекомендуется провести тестирование требований и убедиться, что они обладают всеми характеристиками качественных требований: единичностью, актуальностью, выполнимостью и т. д.
Рекомендуем доверять тестирование требований независимым специалистам, которые их объективно оценят и дадут рекомендации по оптимизации. Ведь устранение ошибок в требованиях – это исправление в тексте. Исправление ошибок в готовом продукте – это часы работы разработчиков и тестировщиков.
Гибридная методология
Все преимущества гибкой и каскадной методологий объединила в себе гибридная методология управления проектами. Этапы планирования и определения требований проходят согласно каскадной методологии, а этапы проектирования, разработки, внедрения и оценки – согласно гибкому подходу.
Соответственно, на разных стадиях проекта будет выполняться полное или частичное регрессионное тестирование.
7 стадий регрессионного тестирования
Независимо от того, какой методологии придерживаетесь вы, изменения ПО требуют выполнения регрессионного тестирования, состоящего из следующих стадий:
Каждый дефект вносится в баг-трекинговую систему, описываются шаги для его воспроизведения. Если возможно, описание сопровождается видео, скриншотами.
На этой стадии QA-инженеры проверяют, действительно ли дефект исправлен. Если проблема остается, создаётся новый отчет. В некоторых случаях устранение дефекта подлежит обсуждению. Все критические и значительные дефекты должны быть устранены обязательно, а вот минорные, устранение которых требует больших затрат, могут быть оставлены. Особенно в тех случаях, если пользователю они не видны.
Исходя из опыта команды a1qa, в среднем требуется не менее трёх раундов регрессионного тестирования для устранения всех дефектов и стабилизации приложения.
Регрессионное тестирование: ручное или автоматизированное?
На любом проекте регрессионные тесты – первые кандидаты на автоматизацию. Они запускаются регулярно, в большом количестве. Автоматизация позволяет не только сократить сроки тестирования, но и высвобождает ресурсы для более высокоуровневых задач, исследования приложения.
Однако несмотря на востребованность автоматизации, ручное регрессионное тестирование также имеет место быть.
Ручное тестирование
Внедрять автоматизацию на небольших проектах, которые длятся всего несколько месяцев, не всегда целесообразно: затраты могут не окупиться, а разработка автотестов лишь затянет сроки реализации проекта. В таком случае тестирование проводится вручную без каких-либо особых инструментов, за исключением баг-трекинговой системы, например, JIRA.
Однако если проект разрастается, функциональность ПО увеличивается с каждым последующим релизом, это влечёт за собой увеличение объемов тестирования. В таком случае стоит задуматься о привлечении специалистов по автоматизации.
Автоматизация тестирования
Решение об автоматизации принимает заказчик, а исполнение ложится на плечи профессиональных инженеров по автоматизации, которые обладают необходимым опытом, знают языки программирования.
Выгоду автоматизации тестирования нельзя недооценивать:
Кстати, есть и такие проекты, на которых разумно совместить ручные проверки с автоматизированными. Все зависит от специфики программного продукта.
Подведём итог
Согласно отчёту World Quality Report 2017, в среднем 26% всего ИТ-бюджета компаний идет на тестирование. Опыт компании a1qa говорит о том, что 40–70% этих затрат приходится на регрессионное тестирование.
Если вы переведёте проценты в реальные деньги, то поймете, почему регрессионное тестирование заслуживает вашего внимания и требует тщательно продуманной стратегии. Выбор правильного подхода поможет эффективно обнаружить все проблемные места, устранить их, обеспечить высокое качество программного решения.
Как подобрать стратегию тестирования, оптимальную для вашего ПО? Спросите у нас! Получить бесплатную консультацию QA-специалиста.