🔎Ретест (Re-test)

Что это? Повторная проверка одного и того же дефекта после того, как разработчик его исправил. Берем баг-репорт, который был в статусе «Fixed», и убеждаемся, что теперь всё работает как надо.

Когда делаем? Сразу после того, как получили от разработчика билд с исправлением. Это быстрая точечная операция.

Зачем? Чтобы поставить дефекту статус «Closed» и двигаться дальше. Это формальность, но обязательная.

Простая аналогия: Представьте, что у вас в машине перегорела лампочка в фаре. Вы ее заменили. Ретест — это когда вы включаете фару, чтобы проверить, горит ли та самая, новая лампочка.

💡Регрессионное тестирование (Regression Testing)

Что это? Это более масштабная проверка. Мы убеждаемся, что новое исправление (или новая функциональность) не сломала существующий, ранее работавший функционал.

Когда делаем?

• После исправления серьезного или сложного бага.

• После добавления новой фичи.

• После изменения кода (рефакторинга).

• Перед выпуском версии (релизом) — это ОБЯЗАТЕЛЬНЫЙ этап.

Зачем? Потому что код — это часто карточный домик. Можно ткнуть в одном месте, и оно упадет в другом. Регресс — это наша страховка от таких сюрпризов.

Простая аналогия: Продолжая пример с машиной. Вы поменяли лампочку в фаре (ретест показал, что она горит). Регресс — это когда вы заводите машину, проверяете ближний/дальний свет, габариты, поворотники, печку, магнитолу и т.д. Вдруг при замене лампочки вы случайно задели проводку, и теперь не работает поворотник?

Выводы Сначала ретест. Всегда сначала убедись, что починили именно тот баг, что ты нашел. Закрой его.

Потом — регресс. Подумай, что еще могло задеть это исправление, и проверь эти области. Особенно то, что связано логически.

#знания