Ответ
Повторное тестирование (re-testing) — это целенаправленная проверка исправленного дефекта для подтверждения его устранения. Тестировщик выполняет те же шаги, что и при первоначальном обнаружении бага.
Ключевые отличия от регрессионного тестирования:
- Re-testing проверяет только исправленный функционал.
- Регрессионное тестирование проверяет, не повлияло ли исправление на другие части системы.
Пример процесса:
- Баг найден: Кнопка "Сохранить" неактивна после заполнения обязательных полей.
- Исправление: Разработчик фиксит код и помечает дефект как "Ready for test".
- Re-testing: Тестировщик повторяет сценарий:
Дано форма с обязательными полями Когда я заполняю все обязательные поля Тогда кнопка "Сохранить" становится активной - Результат: Если кнопка активна — баг закрыт. Если нет — дефект возвращается разработчику.
Практическое правило: Для re-testing всегда используйте те же входные данные и окружение, что и при первоначальном падении теста.
Ответ 18+ 🔞
Да что ж это за жизнь такая, блядь! Сидишь ты, значит, тестируешь, находишь баг — ну, классика, кнопка «Сохранить» тупо не активна, хотя все поля заполнены. Всё, пиздец, праздник души! Заводишь баг, разработчику — иди, мудила, чини.
А он взял, починил, и пишет тебе: «Готово к тесту, ёпта». И вот тут начинается самое интересное, блядь — re-testing, или, по-нашему, «повторное тестирование, сука».
Смысл-то в чём, а? В том, чтобы взять и тупо повторить ровно те же шаги, на которых всё и посыпалось в первый раз. Никаких отсебятин! Те же данные, то же окружение, та же последовательность действий. Как будто ты застрял в петле времени, блядь.
Вот смотри, как это бывает:
- Нашёл баг: Кнопка «Сохранить» — мёртвый груз, хоть обоссысь.
- Починили: Разраб что-то там похерил в коде и говорит «проверяй».
- Re-testing: Ты, затаив дыхание, снова заполняешь эти ёбаные обязательные поля.
Дано форма с обязательными полями Когда я заполняю все обязательные поля Тогда кнопка "Сохранить" становится активной - Итог: Если кнопка ожила — ну, слава богу, закрываем баг и идём пить чай. Если нет — о, ёперный театр! Тогда ты с чувством выполненного долга возвращаешь дефект обратно, желательно с намёком, что у разработчика руки растут не из того места.
И главное, не путай это с регрессионным тестированием, а то мозги набекрень! Re-testing — это точечный удар, проверка только того, что починили. А регресс — это когда ты, блядь, после каждого чиха начинаешь бояться, что фикс одной кнопки похерил половину остального функционала. Там уже надо бегать и всё тыкать, а не одно место.
Короче, правило простое, как три копейки: для re-testing всегда, блядь, одинаковые данные и окружение. Иначе получится хуй в пальто, а не проверка. Сделал раз — упало. Починили — проверяй ровно то же самое. Всё, больше никакой магии!