Что происходит с баг репортом, после того, как разработчик пофиксиг баг ?
Спросят с вероятностью 8%
После того, как исправили баг, баг-репорт проходит через несколько этапов, чтобы гарантировать, что ошибка действительно устранена и не возникли новые проблемы. Эти этапы включают повторное тестирование, проверку качества и закрытие баг-репорта. Рассмотрим этот процесс подробнее:
Этапы обработки
1️⃣Повторное тестирование (Re-testing)
✅Тестировщик получает уведомление о том, что баг был исправлен. Это может быть автоматическое уведомление из системы управления задачами (например, Jira, Bugzilla) или сообщение от разработчика.
✅Тестировщик проводит повторное тестирование, чтобы убедиться, что баг действительно исправлен. Это обычно включает выполнение тех же шагов, которые привели к обнаружению бага, и проверку, что проблема больше не воспроизводится.
2️⃣Регрессионное тестирование (Regression Testing)
✅Помимо проверки исправления конкретного бага, тестировщик также проводит регрессионное тестирование. Это необходимо для удостоверения, что внесённые изменения не вызвали новых ошибок в других частях системы.
✅Регрессионное тестирование может быть частичным (тестирование только связанных функциональных областей) или полным (тестирование всей системы), в зависимости от масштаба изменений.
3️⃣Качество кода и проверка (Code Review and Verification)
✅Исправленный код может пройти через процесс ревью кода, если это принято в команде. Другие разработчики проверяют изменения, чтобы убедиться, что код соответствует стандартам качества и не содержит скрытых проблем.
✅Иногда проводится автоматическое тестирование с использованием CI/CD (Continuous Integration/Continuous Deployment) систем, чтобы автоматически проверить все изменения.
4️⃣Обновление статуса баг-репорта
✅Если тестировщик подтверждает, что баг исправлен и не возникло новых проблем, он обновляет статус баг-репорта на «Исправлен» (Fixed) или «Закрыт» (Closed), в зависимости от используемой системы управления задачами.
✅В некоторых случаях баг-репорт может быть переведен в статус «Подтверждено исправление» (Verified), а затем «Закрыт» после финальной проверки.
5️⃣Документирование результатов
✅Тестировщик документирует результаты повторного тестирования и регрессионного тестирования, добавляя комментарии в баг-репорт. Это помогает сохранять историю исправлений и тестов, что может быть полезно для будущих исследований и анализа.
6️⃣Релиз и развертывание
✅После того как баг исправлен и проверен, изменения включаются в следующий релиз. Команда DevOps или ответственные за релиз специалисты разворачивают обновления на тестовых, а затем на продуктивных средах.
✅Важно убедиться, что исправление бага протестировано на всех соответствующих средах перед его выпуском в продуктив.
Пример процесса исправления
1️⃣Баг-репорт создан и назначен.
2️⃣Разработчик исправляет баг и обновляет статус на «Исправлено».
3️⃣Тестировщик получает уведомление и проводит повторное тестирование.
4️⃣Тестировщик проводит регрессионное тестирование, чтобы проверить отсутствие новых проблем.
5️⃣Если баг исправлен, тестировщик обновляет статус баг-репорта на «Подтверждено исправление» или «Закрыт».
6️⃣Результаты тестирования документируются, и баг-репорт закрывается.
7️⃣Исправления включаются в релиз и разворачиваются на продуктивную среду.
После того как исправляется баг, тестировщик проверяет, что баг действительно исправлен, и проводит регрессионное тестирование. Если все в порядке, баг-репорт закрывается.
👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1855 вопроса на Тестировщика. Ставь 👍 если нравится контент
🔐 База собесов | 🔐 База тестовых
Спросят с вероятностью 8%
После того, как исправили баг, баг-репорт проходит через несколько этапов, чтобы гарантировать, что ошибка действительно устранена и не возникли новые проблемы. Эти этапы включают повторное тестирование, проверку качества и закрытие баг-репорта. Рассмотрим этот процесс подробнее:
Этапы обработки
1️⃣Повторное тестирование (Re-testing)
✅Тестировщик получает уведомление о том, что баг был исправлен. Это может быть автоматическое уведомление из системы управления задачами (например, Jira, Bugzilla) или сообщение от разработчика.
✅Тестировщик проводит повторное тестирование, чтобы убедиться, что баг действительно исправлен. Это обычно включает выполнение тех же шагов, которые привели к обнаружению бага, и проверку, что проблема больше не воспроизводится.
2️⃣Регрессионное тестирование (Regression Testing)
✅Помимо проверки исправления конкретного бага, тестировщик также проводит регрессионное тестирование. Это необходимо для удостоверения, что внесённые изменения не вызвали новых ошибок в других частях системы.
✅Регрессионное тестирование может быть частичным (тестирование только связанных функциональных областей) или полным (тестирование всей системы), в зависимости от масштаба изменений.
3️⃣Качество кода и проверка (Code Review and Verification)
✅Исправленный код может пройти через процесс ревью кода, если это принято в команде. Другие разработчики проверяют изменения, чтобы убедиться, что код соответствует стандартам качества и не содержит скрытых проблем.
✅Иногда проводится автоматическое тестирование с использованием CI/CD (Continuous Integration/Continuous Deployment) систем, чтобы автоматически проверить все изменения.
4️⃣Обновление статуса баг-репорта
✅Если тестировщик подтверждает, что баг исправлен и не возникло новых проблем, он обновляет статус баг-репорта на «Исправлен» (Fixed) или «Закрыт» (Closed), в зависимости от используемой системы управления задачами.
✅В некоторых случаях баг-репорт может быть переведен в статус «Подтверждено исправление» (Verified), а затем «Закрыт» после финальной проверки.
5️⃣Документирование результатов
✅Тестировщик документирует результаты повторного тестирования и регрессионного тестирования, добавляя комментарии в баг-репорт. Это помогает сохранять историю исправлений и тестов, что может быть полезно для будущих исследований и анализа.
6️⃣Релиз и развертывание
✅После того как баг исправлен и проверен, изменения включаются в следующий релиз. Команда DevOps или ответственные за релиз специалисты разворачивают обновления на тестовых, а затем на продуктивных средах.
✅Важно убедиться, что исправление бага протестировано на всех соответствующих средах перед его выпуском в продуктив.
Пример процесса исправления
1️⃣Баг-репорт создан и назначен.
2️⃣Разработчик исправляет баг и обновляет статус на «Исправлено».
3️⃣Тестировщик получает уведомление и проводит повторное тестирование.
4️⃣Тестировщик проводит регрессионное тестирование, чтобы проверить отсутствие новых проблем.
5️⃣Если баг исправлен, тестировщик обновляет статус баг-репорта на «Подтверждено исправление» или «Закрыт».
6️⃣Результаты тестирования документируются, и баг-репорт закрывается.
7️⃣Исправления включаются в релиз и разворачиваются на продуктивную среду.
После того как исправляется баг, тестировщик проверяет, что баг действительно исправлен, и проводит регрессионное тестирование. Если все в порядке, баг-репорт закрывается.
👉 Можно посмотреть Примеры как отвечают люди на этот вопрос, или перейти К списку 1855 вопроса на Тестировщика. Ставь 👍 если нравится контент
🔐 База собесов | 🔐 База тестовых