Нашли проблему — завели задачу. Нашли другую — поставили новую. Если две задачи похожи — поставили связь между ними, большинство баг-трекеров позволяет это сделать.
Плюсы подхода:
- Он помогает не продолбать какую-то ошибку (поставили баг на 15 пунктов — разработчик исправил только 13)
- Проще отслеживать статус — сколько из 15 пунктов исправлено?
- Проще искать — на точечный баг будет конкретное название, на комплексный — непонятно что.
Минусы:
- Когда тестируем большую фичу — приходится бегать по 30 связанным задачам, хотя половину можно записать одной строкой
- Если слишком увлечься, можно начать ставить разные баги на одну проблему (нелокализовали и пошли каждое проявление отдельно фиксировать)
Допустим, мы тестируем
Дадату, которая умеет обрабатывать и стандартизировать данные. Туда можно грузить файлики с данными. И вот мы что-то заморочились и навыдумывали кучу ФИО, адресов, телефонов... Загрузили файл и огребли сразу несколько проблем:
— адрес из одних «ОоОоОо» рушит систему;
— телефон из всех девяток тоже все ломает;
— сложное ФИО не разобралось;
— более 1000 строк обработать нельзя, они просто удаляются;
— ...
Конечно, мы пока не знаем этих причин, у нас просто файлик рухнул из-за адреса. Что делать дальше? Я периодически сталкиваюсь с таким подходом:
— Ну вот ведь файлик есть, на нем падает! А дальше пусть разработчик разбирается, отчего.
Как будет выглядеть в таком случае баг? «Падает обработка файла». Отчего? Неизвестно, пока разработчик не посмотрит.
