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

Работал на проекте, где совершенно не было тестов, но и завала по багам так же не было.
Вот почему то вспомнилось и приспичило узнать, есть ли название следующему подходу:
Весь код заливается через строгий и тщательный код-ревью. На дев сервере тестится только руками, зачастую мелкие баги попадают в продакшн.
Баг фикс организован таким образом, что клиент где-то натыкается на ошибку, ошибка сразу репортится в канал Slack и сохраняется в базе, как необработанная. Ошибка анализируется по стеку и переменным окружения, которые прилагаются к записи этой ошибки. Исправляется и заливается хот-фикс.
Сама ошибка, фактически - это отловленный Exception, который записывается в базу со всей доступной информацией. Если, например, произошла некоторая абстрактная ошибка, то при фиксе ставится исключение уже с человеческим названием, и если вдруг из за изменения некоторого модуля снова попадаем в ту же исключительную ситуацию - получаем уже абсолютно точное название, по которому понятно, что за ошибка произошла и можно даже вспомнить, где её искать (хотя, к ошибки крепится номер файла и строки, так что можно и не вспоминать).
Минусы очевидны - логические ошибки таким образом не выловишь, только по обращению клиента. Ну и, само собой, автотесты предусмотрели бы ошибку заранее.
Плюсы - не тратится время на тесты, благодаря чему быстрее пилятся фичи. Всё более стихийно, проект "чаще ошибается", но быстрее развивается и адаптируется под клиента, что очень важно, особенно в условиях жесткой конкуренции.
Это просто такой компромиссный способ разработки продукта с баг-фиксом малой кровью, или у такого подхода есть название и он является в некоторой степени вполне рабочей альтернативой? Хотелось бы узнать больше и почитать на эту тему.
Нашел и прочитал пару статей о статическом и динамическом анализе кода и сначала подумал, что это о моём вопросе. Но как оказалось, сходство только в том, что в динамическом анализе тоже используется рабочая версия программы, а не тестовая, фиктивная.
А может просто поздно, мозг устал и пытается выжать важное из неважного, - просто проект без тестов. Чего я привязался и ищу что-то глубокое? Кто знает...
  • Вопрос задан
  • 962 просмотра
Пригласить эксперта
Ответы на вопрос 3
lxsmkv
@lxsmkv
Test automation engineer
Спонтанное, не систематизированное "протыкивание" программы с целью нахождения дефектов называется ad-hoc testing
Ответ написан
Комментировать
@AnneSmith
самая ленивая
старая тема, но всегда актуальная

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

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

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

QA работает как у всех с тикетами и нашими фиксами, но количество тестирования несравнимо меньше, а качество продашкн удивляет даже меня
Ответ написан
Комментировать
IonDen
@IonDen
JavaScript developer. IonDen.com
Это совершенно нормальный подход к разработке. У нас в компании это называется data-driven development.

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы