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

Определение

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

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

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

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

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

Применение

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

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

1 КОММЕНТАРИЙ

Подписаться
Уведомить о
guest

1 Комментарий
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
Принц
Принц
11 месяцев назад

интересно

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

? Популярное

? Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас