Как называется такой подход к разработке, тестировани и баг-фиксу?
====================================================================

 Работал на проекте, где совершенно не было тестов, но и завала по багам так же не было.  

Вот почему то вспомнилось и приспичило узнать, есть ли название следующему подходу:  

Весь код заливается через строгий и тщательный код-ревью. На дев сервере тестится только руками, зачастую мелкие баги попадают в продакшн.  

Баг фикс организован таким образом, что клиент где-то натыкается на ошибку, ошибка сразу репортится в канал Slack и сохраняется в базе, как необработанная. Ошибка анализируется по стеку и переменным окружения, которые прилагаются к записи этой ошибки. Исправляется и заливается хот-фикс.   

Сама ошибка, фактически - это отловленный Exception, который записывается в базу со всей доступной информацией. Если, например, произошла некоторая абстрактная ошибка, то при фиксе ставится исключение уже с человеческим названием, и если вдруг из за изменения некоторого модуля снова попадаем в ту же исключительную ситуацию - получаем уже абсолютно точное название, по которому понятно, что за ошибка произошла и можно даже вспомнить, где её искать (хотя, к ошибки крепится номер файла и строки, так что можно и не вспоминать).  

Минусы очевидны - логические ошибки таким образом не выловишь, только по обращению клиента. Ну и, само собой, автотесты предусмотрели бы ошибку заранее.   

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

Это просто такой компромиссный способ разработки продукта с баг-фиксом малой кровью, или у такого подхода есть название и он является в некоторой степени вполне рабочей альтернативой? Хотелось бы узнать больше и почитать на эту тему.   

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

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

 Спонтанное, не систематизированное "протыкивание" программы с целью нахождения дефектов называется ad-hoc testing 

 старая тема, но всегда актуальная  
  

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

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

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

QA работает как у всех с тикетами и нашими фиксами, но количество тестирования несравнимо меньше, а качество продашкн удивляет даже меня 

 Это совершенно нормальный подход к разработке. У нас в компании это называется data-driven development.  
  

Суть в том что вместо тестов, весь проект плотно покрыт всякими разными метриками. Например покупки в минуту, регистрации в минуту, клики по кнопкам в конце концов. Все эти метрики отображаются на графиках. При релизе любой новой фичи мы смотрим на эти графики и алерты.  
  

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