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

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

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

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

Мы разработаем для вас персональный подход к регрессионному тестированию. Проведенм исследование тех элементов функциональности системы, которые наиболее подвержены появлению ошибок. Ручное исследовательское тестирование позволяет нам глубоко проработать ваш продукт в короткие сроки, чем это позволяют сделать стандартные подходы, подразумевающие полное покрытие кода. Всегда ли нужна ручная регрессия? Ответ простой – да, всегда. Тестировщик – последний фланг перед передачей продукта пользователю поэтому надо обязательно убедиться, что система ведет себя так, как планировалось и ничего нигде не сломается при нажатии на кнопку. Автоматизация не дает 100% гарантии, что вручную все будет работать, поэтому нужна проверка сценариев в ручную.

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

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

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

Готовы начать!

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

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

Регрессия необходима практически всегда, когда нет выстроенного процесса разработки:

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

Готовы начать!

Повторное появление одних и тех же ошибок при разработке программного обеспечения достаточно частое явление. Это происходит из-за ошибок при работе с системой управления версиями или по причине человеческих ошибок. Но настолько же часто решение проблемы бывает «недолго живущим»: после следующего изменения в программе решение перестаёт работать. И наконец, при переписывании какой-либо части кода часто всплывают те же ошибки, что были в предыдущей реализации.
Считается хорошей практикой при исправлении ошибки создать тест на неё и регулярно прогонять его при последующих изменениях программы. Хотя регрессионное тестирование может быть выполнено и вручную, но чаще всего это делается с помощью специализированных программ, позволяющих выполнять все регрессионные тесты автоматически. В некоторых проектах даже используются инструменты для автоматического прогона регрессионных тестов через заданный интервал времени. Обычно это выполняется после каждой удачной компиляции (в небольших проектах) либо каждую ночь или каждую неделю.

Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20—50 %) влечет появление новой, весь процесс идет по принципу «два шага вперед, шаг назад». Почему не удается устранять ошибки более аккуратно? Обычно дефекты проявляют себя в одном месте, но на самом деле баги часто имеют неочевидные разветвления по всей системе. Попытки исправить баги минимальными усилиями приводят к исправлению локального и очевидного. Но если структура приложения не ясна, документация не полна, то отдалённые последствия этого исправления останутся незамеченными.

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