Что посоветуете? Брать тестера? Менять разработчиков? Менять процессы?
На мой взгляд (личный опыт, могу ошибаться) полезно поговорить с разработчиками и объяснить им, что есть задачи бизнеса. Они не в вакууме код пишут. Есть пользователи программного продукта, которым нужно дать возможность решать какие-то свои задачи с его помощью. Это - их главная работа, а не формальное выполнение тасков из джиры. Пока мышление у них не перестроится вы можете нанимать тестеров, менять процессы, но подход "и так сойдет" не искоренится.
А как придет понимание, что есть пользователи и нужно о них заботиться, уже можно говорить о внедрении планок качества или об автоматизации тестирования. Можно начать не с хардкорного TDD, а с более мягкого подхода, соответствующего этой идее: взять что-нибудь вроде codecept.js и по-быстрому описывать сценарии взаимодействия пользователя с системой. Сначала основные, которые обязательно должны работать, потом альтернативные, где обработка ошибок происходит. Собственно и изначальное ТЗ формулировать в виде сценария взаимодействия. Можно отвести под тесты отдельный сервер (ненужное железо всегда можно где-нибудь найти). Потом, как привыкнут, попробовать покрывать все юнит тестами или еще что-то внедрять, своим примером показывая, что это и правда может экономить время на поиск багов или давать какие-то еще полезности. Иными словами стоит сначала перестраивать мышление, а потом уже улучшать технические моменты.