В этой статье рассмотрим очень важный тип тестирования — повторное тестирование (retesting).
В рамках жизненного цикла дефекта тестировщик создаёт баг-репорт каждый раз, когда находит ошибку в приложении. Дефект регистрируется в баг-трекинговой системе. Руководитель проекта или тимлид проверяет баг и передает его разработчику для исправления.
После того как разработчик устраняет проблему, команда тестирования должна убедиться, что баг действительно был исправлен. Более того, необходимо проверить, что это исправление не повлияло на другие функции приложения. Процесс проверки бага после его устранения называется повторным тестированием (retesting). Далее мы более подробно рассмотрим эту тему.
🔥 Важное для QA-специалистов! 🔥
В QaRocks ты найдешь туториалы, задачи и полезные книги, которых нет в открытом доступе. Уже более 15.000 подписчиков – будь среди нас! Заходи к нам в телеграм канал QaRocks
Содержание
- Что такое повторное тестирование?
- Пример повторного тестирования
- Преимущества повторного тестирования
- Недостатки повторного тестирования
- Разница между регрессионным тестированием и повторным тестированием
- Заключение
Что такое повторное тестирование?
«Повторное тестирование (англ. retesting) — это процесс повторной проверки тех тест-кейсов, которые ранее завершились неудачно, после того как связанные с ними дефекты были исправлены разработчиками. Это запланированный этап тестирования, также известный как подтверждающее тестирование (confirmation testing)».
Повторное тестирование является частью жизненного цикла дефекта. В этом цикле баг не может быть закрыт, пока он не будет устранен разработчиком и повторно проверен тестировщиком. Если после ретестинга баг действительно ушел, его можно закрывать. Если нет — он возвращается обратно в разработку.
Во время ретестинга тестировщик воссоздает тот же сценарий, при котором возник баг, чтобы убедиться, что проблема решена. Кроме того, тестировщику необходимо проверить связанные с багом функции, чтобы убедиться, что изменения в коде не повлияли на другие, логически связанные участки приложения.
Пример повторного тестирования
Рассмотрим процесс расчёта суммы заказа в e-commerce-приложении:
- Цена товара + стоимость доставки = общая стоимость товара
- Общая стоимость товара — примененный промокод = итоговый заказ (сумма к оплате)
Тестировщик обнаруживает баг: «При оформлении заказа, после применения корректного промокода, скидка не учитывается в расчете итоговой суммы». Тестировщик оформляет баг-репорт, и баг назначается разработчику.
Дальше возможны два варианта:
- Разработчик исправляет баг. Баг возвращается тестировщику для повторного тестирования. Во время ретестинга тестировщик выполняет те же шаги: применяет промокод и проверяет, учтена ли скидка в финальной сумме. Если да — баг закрывается.
- Разработчик отклоняет баг. Баг возвращается тестировщику, который должен повторно его проверить и убедиться, что отказ был обоснован. Если тестировщик не согласен с отклонением — баг переоткрывается и переназначается разработчику.
Преимущества повторного тестирования
- Повторное тестирование позволяет тестировщикам убедиться, что баг был действительно исправлен разработчиком. Они проверяют, что дефект больше не воспроизводится при выполнении тех же шагов. После успешного ретестинга баг закрывается. Таким образом, ретестинг способствует повышению качества программного обеспечения за счёт проверки ранее проваленных тест-кейсов.
- Кроме того, ретестинг требует меньше времени, так как охватывает только конкретный баг или провалившийся тест-кейс.
Недостатки повторного тестирования
- Иногда для устранения бага требуется незначительное изменение в коде. Однако даже для проверки одного такого бага разработчику необходимо выполнить полноценное развертывание новой версии, что может быть затратным по времени.
- Кроме того, ретестинг может быть трудоемким и для тестировщика, поскольку требует повторного выполнения всех шагов, необходимых для воспроизведения и проверки устранения дефекта.
Разница между регрессионным тестированием и повторным тестированием
Часто возникает путаница между регрессионным тестированием и повторным тестированием. Рассмотрим основные различия между этими двумя подходами.
Возьмем рассмотренный выше пример с e-commerce сайтом. В первом сценарии есть дополнительная возможность развития событий: при устранении бага разработчик допустил ошибку, из-за которой «стоимость доставки» не добавляется к общей сумме заказа, в результате чего рассчитывается некорректный итог.
Таким образом, исходный баг исправлен, но возник побочный эффект, повлиявший на другую функциональность той же страницы. Именно поэтому тестировщик должен проверять не только применение скидочного кода, но и корректность всех связанных расчётов. Такая проверка уже относится к регрессионному тестированию.
Регрессионное тестирование — это процесс проверки программного обеспечения после внесения изменений в код. Оно проводится с целью убедиться, что новые изменения не повлияли на другие, ранее не затронутые модули системы.
Ключевые различия между повторным тестированием и регрессионным тестированием:
- В повторном тестировании проверяется конкретный тест-кейс и устраненный дефект. Тестировщик воспроизводит шаги, приведшие к багу, и убеждается, что проблема устранена. В регрессионном тестировании проводится проверка приложения в целом, чтобы убедиться, что внесенные изменения в код не затронули другие, ранее работающие участки системы. Здесь повторно выполняются тест-кейсы, ранее успешно пройденные.
- Регрессионное тестирование может быть автоматизировано, тогда как автоматизация ретестинга не всегда возможна или целесообразна.
- Верификация дефекта выполняется только в процессе ретестинга. В регрессии эта цель не ставится.
- Регрессионное и повторное тестирование могут выполняться параллельно, однако приоритизация должна отдаваться ретестингу, так как он напрямую подтверждает устранение дефекта.
Заключение
Ретестинг — важный и необходимый вид тестирования, который обеспечивает надежность и безошибочность системы. Он подтверждает, что ранее упавшие тест-кейсы были исправлены, что облегчает работу не только командам тестирования и разработки, но и клиенту.
Перевод статьи «Retesting».