тикет тикету - рознь. однако регрессионные тесты именно для того и нужны чтобы отслеживать а не сломалась ли что при внесении очередных изменений в программу и/или структуру БД. По интеграционным тестам на Ваш выбор. Однако если все это достаточно автоматизировано, то не думаю, что прогонка регрессионных тестов будет столь напряжна.

Бока,
авторА если тесты приходится/ отлаживать по ходу дела ?

Ну я надеюсь, что с каждой итерацией это приходится делать все меньше и меньше?
авторТесты и сами функциональности пишут разные люди.
вполне обычная практика
авторВыявление ошибок в самих тестах тормозит процесс.
Ну тестировщик который пишет автоматизированные тесты по сути сам программист. И в своих программах = автоматизированных тестах может допускать ошибки. Решите насколько нужны вам эти тесты в проекте. По своей практике могу сказать, что были проекты в которых трудозатраты на тестирование сравнимы, а то и больше, чем на саму разработку. Также видел проекты где вообще ничего не тестировалось или тестировалось поверхностно.
авторКроме того, для каждого тикета строится отдельная база для тестирования, построение которой занимает в среднем 20-25 мин
см . ответ на предыдущий вопрос.

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

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