Корректность фиксов багов

Должны ли разработчики проверять корректность своих фиксов?
Проблема обсуждалась неоднократно на форуме проекта it4business.ru , в блогах и т.д. Попробуем разобраться в ситуации.

Априори предполагаем наличие здравого смысла в организации процесса и ясность смысла проверок всем ясна. Итак, если проверки необходимы, то их кто-то должен делать- либо сами разработчики, либо тестировщики. Рассмотрим 2 варианта: 1- тестировщиков на проекте не достаточно; 2- тестировщиков достаточно для того, чтобы смотреть еще и за результатами фиксов, несмотря на то, что времени на тестирование всегда не хватает. Второй утопический случай можно смело отбросить) и поставить вопрос так: должны ли разработчики сами проверять не только корректность конкретного фикса, но и некоторое минимальное окружение вокруг этого фикса (бага)? То есть ограничиваться ли автору фикса проверкой только лишь того конкретного бага\проявления бага, который указан в баг репорте? Или все-таки включить мозг, попробовать другие действия, окружение и т.д.

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

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

Что получилось:

Вобщем я решил, что такой регламент должен быть коротким, чтобы разработчикам было не лень его читать и применять. Также чтобы он описывал только основные моменты.
Смысл его введения:
1. Разработчики дожны проверять, что то, что они сделали (написали\пофиксили), работает вообще.
2. Разработчики дожны проверять, что то, что они сделали, работает корректно.
3. Разработчики дожны проверять (хотя бы в минимальной степени), что то, что они сделали, не ломает существующий, корректно работающий функционал.
Можно переложить почти все эти проверки на тестировщиков при условии, что как максимум на 4 разработчиков будет 1 тестировщик. В нашем случае это без вариантов.
По опыту тестирования (конкретного софта) могу сказать, что очень много времени у меня уходило: на поиск существующих в системе баг трекинга баг репортов + их возвращение, комментирование; на запись похожих. При организации проверки фиксов разработчиками этого бы не понадобилось. А потраченное время я бы потратил на более серьезную проверку.

Проверка фикса (не только):
1. Время верификации каждого фикса не более 10-20 мин.
2. В первую очередь производится попытка воспроизведения бага (по описанным шагам).
3. Во вторую- анализ областей, в которых вероятно возникновение этого бага.(Например, если был обнаружен баг с фильтром, работающим при вызове какого-то меню, то имеет смысл проверить все схожие типы меню, работающих по такому же принципу.).
4. Проверка этих областей.
5. Анализ возможности вызова повторения бага другими методами (отличающимися от описанного в баг репорте (Например, если был обнаружен баг при удалении записи, имеет смысл проверить удаление группы записей и т.п.)).
6. Проверка этих методов.
Минимальное свободное тестирование (специфично для определенного софта):
7. Проверка работы с некорректными данными (например, сохранение, поиск по ним).
8. Повторяющиеся действия (например, попытка удаления уже удаленного объекта, двойной импорт).
9. Проверка вывода обязательных сообщений (например, при сохранении с незаполненными
обязательными полями).
10. Если, например, теструется установка дистрибутива или импорт данных, имеет смысл
использовать виртуальные машины для одновременной проверки разного функционала или
параллельной проверки при различных условиях (пример- при тестировании импорта\экспорта удобнее и быстрее на одной машине произвести импорт, затем экспорт, а на другой- импорт этих экспортированных данных; с последующей одновременной проверкой данных).

Все это опять же- FYI.