Бинарный поиск в действии: разбираем реальный кейс, как найти проблемный коммит среди тысяч изменений кода, затратив минимум времени. Метод git bisect – мощный инструмент для поиска изменения, вызвавшего баг в коде: с его помощью разработчику удалось быстро локализовать проблему, просмотрев всего 11 коммитов вместо изначальных 2088. Исходные данные: Чтобы понять, в каком конкретном изменении появилась ошибка, нужно: Так как в ветке release-5.7.0 ошибки нет, значит, баг появился в ветке main после того, как была создана ветка release-5...

Вы только начинаете карьеру в тестировании. Нашли баг, тщательно описали его, отправили в баг-трекер… А в ответ — тишина. Или, что бывает обиднее: «Это не баг, это фича». «Так и было задумано». «Пользователю всё равно». «Починим потом, сейчас не до этого». Что делать? Ошибка ведь реальная. Но никто, кажется, не хочет её признавать. Разбираемся, как действовать в таких ситуациях — и не терять мотивацию. Иногда багом может показаться то, что работает по специфике бизнес-логики. Перед тем как создавать тикет, стоит: Ваш баг должен быть обоснован, а не просто «по ощущениям что-то не так»...