Дефекты с прода: понять и простить?
Привет, охотники! 🏹 Дочитала книгу Ольги Назиной "Баг-трекинг: локализация и оформление дефектов". Читала с мыслью, что все уже знакомо - и схема оформления дефектов, и баг-трекинговые приложения, и жизненный цикл задачи. Однако под конец меня все-таки заинтересовала одна из глав Анализ дефектов с прода, а именно размышления над тем, как избегать таких проблем в будущем. Да, понятно, что рефлексировать (особенно над своими ошибками) бывает неприятно, но это и есть точки роста Автор предлагает копать глубже, чем просто "аа это не проверили, а надо было бы". Необходимо понять, а что привело к тому, что проверок было недостаточно, почему пропустили Причины, по которым они могли быть пропущены, разные:
- проверки потерялись в большом количестве кейсов
- в тз не учли, что правки могли что-то зааффектить
- (ну или банально) отвлекли на более срочную задачу Я для себя, например, решила, что по типовым задачам (а также найденным по ним багам) начну вести универсальные чек-листы, чтобы в процессе тестирования не упускать детали А вы анализируете причины дефектов с прода? Если да, то насколько подробно?
· 06.11.2025
Есть путь решения. Автотесты. Загнал новую фичу, пустил по кругу( добавьте шутку айтишники) И по новой. Все, нет проблем, ты кайфовый сотрудник, тебя все любят, ты на коне.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 06.11.2025
Конечно регрессионное тестирование никто не отменял, но если фича новая, то тут автотестов не напишешься на каждый кейс 🤔
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 06.11.2025
Я к тому, что тесты пишут разрабы, у которых есть руки, только потом подключатся QA если разраб инвалид Лмао
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён