Из разработчиков в предприниматели: учимся правильно управлять продуктом и конструктивно разговаривать с заказчиками
Рассказываю, почему коммуникация становится важнее технических деталей и что отвечать клиенту, который просит отчётность по каждому шагу.
Мысли верные.
Я бы еще добавил, что в зависимости от выбранной методологии приходит и метод разработки.
Если это каскадная модель и ее вариации, то TDD - вполне рабочая история.
Она дольше и требует х2 кода, но дает много плюсов.
В этом случае как таковой тестировщик не нужен - достаточно менеджера кликера, который проверит ПО со стороны пользователя.
Интеграционные и нагрузочные тесты на разработчиках.
Если это Agile (справедливости ради в коммерческой разработке иначе нельзя), то тут без тестера никак.
Вообще никак.
Каждая фича пытается завалить проект и самое гадкое, что ее не видит разработчик :)
Ну и опять же, все выше справедливо, только если в команде есть хороший DevSecOps, иначе нужен хороший тестер в любом из вариантов, чтоб искать незадокументированные дыры в ПО, которые могут очень неприятно аукнуться.