- Определение
- Характеристики
- Применение
- Быстрый пример
- Преимущества
- Чем отличается от
Определение
(Ретест) — процедура повторной проверки отдельных тест-кейсов, при выполнении которых были обнаружены баги.
Также повторное (полное) тестирование проводят, когда продукт уже полностью протестирован, и по каким-то причинам нужно это сделать еще раз.
Отправлять ли компонент/продукт на повторное тестирование, решают разработчики, принимая или отклоняя баг. Если баг найден пользователем, но отклонен разработчиком, тестировщик должен еще раз его проверить и найти причину проблемы.
Характеристики
- Повторение тестовых действий проводится с теми же файлами и процессами
- Также проводится с упавшими тест-кейсами, после устранения причин подтверждая успешность тестового процесса в целом
- Если в самом тесте возможна ошибка и тест отклоняется разработчиком как не имеющий багов, тест повторно выполняется в QA-департаменте, чтобы уточнить ситуацию и найти причину проблемы (действительно это баг или все-таки ошибка тестировщика). См. Жизненный цикл дефекта.
- Иногда для этого потребуется повторно тестировать всю программу (то есть весь билд)
- В случаях, когда автоматизация повторного теста нецелесообразна (что бывает часто), применяется ручное и/или исследовательское
Применение
- Как говорилось выше, когда нужно прояснить ситуацию с багом/дефектом (верифицировать)
- И когда баг отклонен разработчиками, теперь QA-отдел должен проверить еще раз, проявляется ли этот баг
- А также, чтобы проверить всю систему (окончательно верифицировать ее функциональность)
- Или верифицировать функциональность самой важной части системы
- Или когда пользователи/клиенты требуют провести повторное тестирование, по своим причинам
Быстрый пример
Стандартный процесс: тестирование в Facebook. Чтобы полноценно пользоваться соцсетью, нужна учетная запись, для этого нужно зарегистрироваться, вводя свои данные (ФИО, дата рождения, опционально город/адрес, место учебы/работы и так далее). После этого нажать кнопку «Регистрация». А она не работает! Пользователь пишет жалобу разработчикам, они устраняют дефект (кнопка уже работает). Далее дефект передают QA-департаменту для повторной проверки, и тестировщик будет проверять только эту кнопку «Регистрация».
Преимущества
- Ретест гарантирует, что баг 100% устранен и все работает как хочет пользователь
- Повышает общий уровень качества
- На повторное тестирование обычно не требуется много времени (ограниченное количество дефектов, чаще один)
- Не требуется какой-то новый софт или другая конфигурация
- Поскольку тестировщик имеет дело с теми же данными и процессами что и ранее
Недостатки
- Если требуется ретест всего приложения, нужен рабочий билд и много времени
- В целом повторное тестирование требует внимательности и опыта
- Не факт что удастся автоматизировать
- Если и ретест не дал внятного результата, поиск причин проблемы потребует еще больше времени
Чем ретест отличается от смок-тестирования
Кратко: повторное тестирование обычно направлено на один баг, который (все равно) проявляется после того как его (должны были) пофиксили. В стандартном процессе тестировщики находят баг, передают разработчикам, и разработчики устраняют его (присваивая статус fixed), после чего передают на ретест. Простой ретест гарантирует, что проблемы больше нет и все работает.
А дымовое тестирование проверяет общую работоспособность/стабильность (нового) билда, почему и называется еще «Верификацией билда» или «Confidence Testing». Простое смок-тестирование верифицирует основную функциональность (работает или нет в целом) и позволяет передать продукт на доработку или следующие стадии тестирования. Дымовое тестирование выполняется на каждом новом билде и является очень «общим», поверхностным. Может успешно автоматизироваться.
| Повторное тестирование (ретест) | Дымовое тестирование (смок-тест) |
|---|---|
| Цель: тест-кейсы, ранее упавшие, теперь проходят, после устранения дефектов | Цель: основная функциональность продукта в целом работает |
| Верификация устранения дефектов | Верификация общей работоспособности и минимальной стабильности системы |
| Предполагается верификация дефектов | Не предполагается верификация дефектов, просто экспресс-проверка системы |
| Повторное тестирование проводится обычно перед санитарным (что это?) | Смок-тестирование проводится обычно перед регрессионным (что это?) |
| Повторное не является подвидом какого-либо другого вида тестирования | Типологически дымовое является как бы подмножеством регрессионного тестирования |
| Мало тест-кейсов (только упавшие и вызывающие вопросы) | Покрывает только критическую функциональность, обычно мало тест-кейсов |
| Плюсы: Простая верификация устраненных дефектов Не нужно много времени Не требует нового окружения, новой конфигурации | Плюсы: Простая оценка работоспособности системы Не нужно много времени Простая проверка, или регресс, что функциональность сохранилась Также проверка после интеграции компонентов (что это?) |
| Минусы: Автоматизация сложная или неуместная Если и ретест не дал результата, возможно придется делать полное повторное, что значительно сложнее | Минусы: Являются продолжением плюсов — дымовое тестирование слишком поверхностное по своей природе Только явные дефекты |
Чем повторное отличается от регрессионного
| Повторное | Регрессионное |
|---|---|
| Нацелено на проверку, пофиксили ли конкретные баги | Не нацелено на конкретные баги |
| Не фокусируется на функциональности предыдущей версии, проверяет, сохранилась ли функциональность после багфикса | Ориентировано на изменения, проверяет, сохранилась ли функциональность предыдущей версии после обновления/изменения продукта |
| Так как нацелено на один дефект, трудно автоматизировать | Часто автоматизируется. Ручное тестирование рутинного регресса утомительно. |
| Не является обязательной частью процесса тестирования, а только если есть проблемные области/дефекты | Является едва ли не обязательной частью стандартного процесса тестирования; всякий раз как код изменен, хорошая практика провести «регрессы» |
| Высокоприоритетный тип тестирования, поскольку направлен на известные дефекты (критические) | Сравнительно меньше приоритет, рутинная проверка продукта на потенциальные дефекты |
| Поскольку нацелено на малое количество дефектов, обычно проводится быстро | Чаще проверяет достаточно обширные области приложения, поэтому может требовать много времени |
Сходство в том, что оба вида нацелены на «повторные» действия. Основное различие в том, что ретест направлен на известные баги.
