Скорость обратной связи в процессе «тест-баг-фикс»

Рассмотрим следущие петли обратной связи в процессе «тест-баг-фикс»:

1. По способу применения
   
2. По уровню тестов
   
3. По формализации и уровню
   
4. По исполнителю
   

Итак, что мы имеем в результате:

Быстрее всего найти баг может разработчик юниттестами на несобранном приложении, и при этом он может не заносить баг в БТС.

Средний по скорости вариант, это когда баг найден тестировщиком на уже собранном приложении, во время системного или приемочного тестирования, где все баги заносятся в БТС.

Дольше всего баг будет идти к разработчику от конечного пользователя, т.к. приложение должно уже быть собрано, протестировано своими тестировщиками и доступно заказчику.

Что можно предложить, для того чтобы укоротить обратную связь?

1. Увеличивать покрытие модульными и интеграционными тестами
2. Привлекать тестировщиков к созданию тестов на уровне кода и API (иногда тестировщики могут более точно и оптимально подобрать тестовые данные на основании раличных техник тест дизайна)
3. Автоматизировать дымовые и приемочные тесты
4. Увеличить надежность и скорость прогона системных автоматических тестов (исключить ложные падения, использовать многопоточность, оптимизировать код тестов, исключить дублирующие проверки, использовать мок объекты и заглушки, там где можно)
5. ...