Повторное тестирование

• Определение
• Характеристики
• Применение
• Быстрый пример
• Преимущества
  • Недостатки
• Чем отличается от
  • дымового тестирования
  • регрессионного

Определение

(Ретест) — процедура повторной проверки отдельных тест-кейсов, при выполнении которых были обнаружены баги. 

Также повторное (полное) тестирование проводят, когда продукт уже полностью протестирован, и по каким-то причинам нужно это сделать еще раз. 

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

Друзья, поддержите нас вступлением в наш телеграм канал QaRocks. Там много туторилов, задач по автоматизации и книг по QA.

Характеристики

• Повторение тестовых действий проводится с теми же файлами и процессами
• Также проводится с упавшими тест-кейсами, после устранения причин подтверждая успешность тестового процесса в целом
• Если в самом тесте возможна ошибка и тест отклоняется разработчиком как не имеющий багов, тест повторно выполняется в QA-департаменте, чтобы уточнить ситуацию и найти причину проблемы (действительно это баг или все-таки ошибка тестировщика). См. Жизненный цикл дефекта.
• Иногда для этого потребуется повторно тестировать всю программу (то есть весь билд)
• В случаях, когда автоматизация повторного теста нецелесообразна (что бывает часто), применяется ручное и/или исследовательское

Применение

• Как говорилось выше, когда нужно прояснить ситуацию с багом/дефектом (верифицировать)
• И когда баг отклонен разработчиками, теперь QA-отдел должен проверить еще раз, проявляется ли этот баг
• А также, чтобы проверить всю систему (окончательно верифицировать ее функциональность)
• Или верифицировать функциональность самой важной части системы
• Или когда пользователи/клиенты требуют провести повторное тестирование, по своим причинам

Быстрый пример

Стандартный процесс: тестирование в Facebook. Чтобы полноценно пользоваться соцсетью, нужна учетная запись, для этого нужно зарегистрироваться, вводя свои данные (ФИО, дата рождения, опционально город/адрес, место учебы/работы и так далее). После этого нажать кнопку «Регистрация». А она не работает! Пользователь пишет жалобу разработчикам, они устраняют дефект (кнопка уже работает). Далее дефект передают QA-департаменту для повторной проверки, и тестировщик будет проверять только эту кнопку «Регистрация».

Преимущества

• Ретест гарантирует, что баг 100% устранен и все работает как хочет пользователь
• Повышает общий уровень качества
• На повторное тестирование обычно не требуется много времени (ограниченное количество дефектов, чаще один)
• Не требуется какой-то новый софт или другая конфигурация
• Поскольку тестировщик имеет дело с теми же данными и процессами что и ранее

Недостатки

• Если требуется ретест всего приложения, нужен рабочий билд и много времени
• В целом повторное тестирование требует внимательности и опыта
• Не факт что удастся автоматизировать
• Если и ретест не дал внятного результата, поиск причин проблемы потребует еще больше времени

Чем ретест отличается от смок-тестирования

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

А дымовое тестирование проверяет общую работоспособность/стабильность (нового) билда, почему и называется еще «Верификацией билда» или «Confidence Testing». Простое смок-тестирование верифицирует основную функциональность (работает или нет в целом) и позволяет передать продукт на доработку или следующие стадии тестирования. Дымовое тестирование выполняется на каждом новом билде и является очень «общим», поверхностным. Может успешно автоматизироваться.

Повторное тестирование (ретест)	Дымовое тестирование (смок-тест)
Цель: тест-кейсы, ранее упавшие, теперь проходят, после устранения дефектов	Цель: основная функциональность продукта в целом работает
Верификация устранения дефектов	Верификация общей работоспособности и минимальной стабильности системы
Предполагается верификация дефектов	Не предполагается верификация дефектов, просто экспресс-проверка системы
Повторное тестирование проводится обычно перед санитарным	Смок-тестирование проводится обычно перед регрессионным
Повторное не является подвидом какого-либо другого вида тестирования	Типологически дымовое является как бы подмножеством регрессионного тестирования
Мало тест-кейсов (только упавшие и вызывающие вопросы)	Покрывает только критическую функциональность, обычно мало тест-кейсов
Плюсы: Простая верификация устраненных дефектов Не нужно много времени Не требует нового окружения, новой конфигурации	Плюсы: Простая оценка работоспособности системы Не нужно много времени Простая проверка, или регресс, что функциональность сохранилась Также проверка после интеграции компонентов
Минусы: Автоматизация сложная или неуместная Если и ретест не дал результата, возможно придется делать полное повторное, что значительно сложнее	Минусы: Являются продолжением плюсов — дымовое тестирование слишком поверхностное по своей природе Только явные дефекты

Чем повторное отличается от регрессионного

Повторное	Регрессионное
Нацелено на проверку, пофиксили ли конкретные баги	Не нацелено на конкретные баги
Не фокусируется на функциональности предыдущей версии, проверяет, сохранилась ли функциональность после багфикса	Ориентировано на изменения, проверяет, сохранилась ли функциональность предыдущей версии после обновления/изменения продукта
Так как нацелено на один дефект, трудно автоматизировать	Часто автоматизируется. Ручное тестирование рутинного регресса утомительно.
Не является обязательной частью процесса тестирования, а только если есть проблемные области/дефекты	Является едва ли не обязательной частью стандартного процесса тестирования; всякий раз как код изменен, хорошая практика провести «регрессы»
Высокоприоритетный тип тестирования, поскольку направлен на известные дефекты (критические)	Сравнительно меньше приоритет, рутинная проверка продукта на потенциальные дефекты
Поскольку нацелено на малое количество дефектов, обычно проводится быстро	Чаще проверяет достаточно обширные области приложения, поэтому может требовать много времени

Сходство в том, что оба вида нацелены на «повторные» действия. Основное различие в том, что ретест направлен на известные баги.

Источник «Повторное тестирование».