Анализ багов при исследовательском тестировании

Для начала представлю видео Ильи Комендантова, в котором он записал полтора часа добротной исследовательской и абсолютно не постановочной сессии.
Возможно смотреть целиком, особенно опытным тестировщикам, необязательно, но для начинающих тестировщиков и эффективных менеджеров, которые о тестировании слыхали только как о процессе, когда обезьянки бессистемно тыкают по кнопкам или по шагам обрабатывают написанные "умным дядей" тест-кейсы - очень полезный материал.

Теперь про анализ. У меня такое замечание/дополнение по процедуре анализа ошибок найденных исследовательским тестированием, да и другими методами тестирования тоже. Я очень понимаю желание проанализировать ошибку до нахождения точных границ фейла ("когда ввожу число 500  - работает, 501 - уже нет"), но со временем пришел к выводу, что обычно этого делать не надо. Достаточно зафиксировать входные параметры, при которых ошибка возникает ("ввел число 650 - не работает") и продолжать поиск других ошибок.

Аргументы такие:

сама ошибка задокументирована, и программист, глядя в код, вероятно быстрее и сам поймёт где лежит граница фейла, а возможно заметит в коде ещё и другие скользкие значения. Ища точную границу ошибки методом черного ящика, мы нерационально используем время тестировочной сессии.

Возможно, я стану искать приближение, если найденное мной первое значение лежит слишком далеко в теоретической области ("нельзя сохранить картинку 1млн пикселей на 1млн пикселей"), чтобы не раздражать программистов чересчур странными данным, но если найден разумный представитель данных для демонстрации бага - поиск заканчивается.

Вернусь к слову обычно. Разумеется, тут есть миллион исключений. Первое, важное для тестировщиков, что пришло в голову - если вы подозреваете, что в поиске границ вы натолкнетесь на новые смежные баги (например граница ровно 65536  - 2^16 натолкнет на мысль, что и в других местах именно это число будет проблемным). Или если программист  - узкое место в проекте, а у нас тестировщиков куча времени свободно. Или другие исключения, которые лежат в области человеческого взаимодействие и компетентности отдельных членов команды. :)

И, буду уж откровенен, иногда и я сам ищу границы ошибок, даже когда это не очень рационально, поэтому что это просто доставляет удовольствие :).

А как у вас?