В процессе разработки сайта или приложения разработчикам приходится вносить изменения в код или добавлять новые функции. Часто после этого программное обеспечение работает не так, как работало раньше, в нем может произойти сбой или даже полный отказ системы. Чтобы предотвратить негативные последствия изменения программного обеспечения проводится регрессионное тестирование.
Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туториалов, задач по автоматизации и книг по QA.
Содержание
- Что такое регрессионное тестирование?
- Зачем и когда проводить регрессионное тестирование?
- Отбор регрессионных тест-кейсов
- Трудности регрессионного тестирования
- Лучшие практики регрессионного тестирования
Что такое регрессионное тестирование?
Регрессионное тестирование направлено на обнаружение ошибок в уже протестированных участках исходного кода. Эти ошибки могут возникать после внесения изменений в программу.
Регрессионное тестирование помогает избавиться от рисков, которые могут быть связаны с обновлением веб-сайтов и приложений. Оно выполняется командой QA после завершения работы командой разработчиков.
Зачем и когда проводить регрессионное тестирование?
Мы проводим регрессионное тестирование каждый раз, когда код подвергается изменениям.
Ниже приведены возможные сценарии, требующие проведения регрессионного тестирования.
1. Добавление новых функциональных возможностей.
На сайте или в приложении есть функция входа в систему, которая позволяет пользователям входить в систему только с помощью Email. Теперь добавляется новая возможность входа в систему с помощью номера телефона.
2. Необходимость внесения изменений в требования.
Убрана кнопка “Запомнить пароль”, которая присутствовала ранее.
3. После исправления дефектов.
Например, тестировщик обнаруживает, что кнопка регистрации не работает, и переводит этот баг на разработчика. Разработчик исправляет его, и после исправления ошибки тестировщик проверяет работоспособность кнопки “Регистрация”. Аналогичным образом тестировщик проверяет и другую функциональность, связанную с этой кнопкой.
4. После решения проблем с производительностью.
Проводится регрессионное тестирование производительности всего приложения для проверки того, что внесенные изменения решили проблему.
Отбор регрессионных тест-кейсов
- Приоритизация тест-кейсов. Приоритетность тест-кейсов зависит от критичности и частоты использования функциональности, для которой они были написаны. Выбор тест-кейсов на основе их приоритетности позволяет сократить размер тестового набора.
- Выбор тест-кейсов из уже имеющихся. Вместо того, чтобы выполнять все тесты заново, вы выбираете определенные тест-кейсы из тестового набора, относящиеся к тестируемым функциональностям. В дальнейшем среди этих тест-кейсов можно выделить как многократно используемые, так и устаревшие тесты.
Трудности регрессионного тестирования
- Иногда из-за нехватки времени и бюджета невозможно выполнить весь набор регрессионных тестов.
- Чем больше функций в продукте, тем большее количество тест-кейсов требуется для регрессионного тестирования.
- Оптимизировать тестовый набор для сокращения времени выполнения и достижения максимального тестового покрытия не просто.
- Необходимо понимать, когда следует запускать тестовый набор: при каждом незначительном изменении, после каждой сборки или при появлении исправлений.
Лучшие практики регрессионного тестирования
Техника регрессионного тестирования надежна, но требует больших затрат времени и средств. Поэтому имеет смысл объединять тест-кейсы в наборы согласно каждому модулю программы. В итоге в ходе регрессионного тестирования специалисты по обеспечению качества будут затрагивать только только те модули, которые подверглись изменениям. Также стоить помнить, что невозможно полностью избежать ручного тестирования.
Итак, какие лучшие практики стоит включить в планирование регрессионного тестирования?
- Регулярно обновляйте набор регрессионных тестов. Поддерживайте регрессионные тест-кейсы в актуальном состоянии, согласно любым вносимым изменениям в код или требования.
- Выполняйте повторно даже успешно пройденные тест-кейсы. Даже если в предыдущем цикле регрессионного тестирования тест-кейс был выполнен успешно, это не значит, что новые изменения в коде не “сломают” проверенную ранее функциональность. Вот почему в каждом цикле регрессионных тестов необходимо повторять все тест-кейсы из набора.
- Автоматизируйте регрессионные тесты. Инструменты автоматизации могут ускорить выполнение определенных действий по сравнению с человеком. Таким образом, автоматизация является лучшим решением для увеличения скорости выполнения тест-кейсов. Также она позволяет тестировщику сфокусироваться на более сложных тестах, в то время как более простые сценарии будут выполнятся автоматически.
Заключение
Главной проблемой при сопровождении продукта является тот факт, что исправление одной ошибки с большой вероятностью влечёт появление новой. В теории, после каждого исправления нужно запустить весь набор тест-кейсов, по которым система проверялась ранее, чтобы убедиться, что она работает исправно. На практике же регрессионное тестирование занимает много времени и очень дорого стоит. Поэтому целесообразно уделять достаточно времени предварительному планированию, чтобы в дальнейшем на сам процесс тестирования затрачивалось меньшее количество ресурсов.
Еще можете почитать про 7 лучших практик регрессионного тестирования.
Перевод статьи «Best practices for regression testing».