- На каких технологиях приложение?
- Какая длина спринта?
- Как у вас построен процесс написания кода и интеграции?
- Сколько разработчиков?
- Какие роли кроме разработчиков и тестировщиков еще есть на проекте?
Как у вас дела с архитектурой, если не получается добавлять функции не задев при этом значительную часть всей системы?
По идее код перед мерджем должен проверяться на тестировочной сборке. Возможно вам нужен девопсер, если у вас его нет.
Во время проверки (тестирования) можно написать на этот сценарий приемочный тест. Так у вас потихоньку появятся автоматизированные тесты.
Я бы приоритизировал приемочные тесты перед юнит-тестами в данном случае. Автоматизированные приемочные тесты напрямую разгружают тестировщиков, которых у вас, судя по размеру проекта, недостаточно. Польза юнит тестов видна только в долгосрочной перспективе.
Разработчики тоже должны тестировать. Тот кто пишет фичу Х проверят фичу Y и наоборот. Нельзя давать проверять свою собственную работу. Нужна культура качества и открытой коммуникации - чтобы разработчики не замалчивали замеченые проблемы, а открыто писали на них тикет.
Переходить в следующий спринт с багами из предыдущего - вообще не айс. Можно сделать один спринт - добавление функционала, второй спринт стабилизация.
Простой
Простой
