По моему мнения вертикаль взаимодействия совсем не так выглядит.
Правильно:
Продаткт -> Прогрраммисты -> Тестировщики -> Пользователи.
<<< а тут обратная связь <<
В своем списке вы забыли про самого главного тут - Пользователя. Пользователь важнее чем начальник, если не будет пользователей и начальника не станет.
В некоторых маленьких компаниях в этой схеме действительно нет отдела тестирования, тоесть все баги находят пользователи и комплейнят о них через саппорт.
Но такая система работает только для маленьких бесплатных проектов, которые ничего не продают. В случае же продаж, после первого критического бага потребуют деньги назад.
Вот тут и начинает окупатся отдел тестирования. С ростом компании появляется репутация, имидж, конкуренты, оставьте дыру в безопансоти и завтра база ваших клиентов будет разослана по интернету.
Отдел тестирования становится актуальным в компаниях где работает больше 10 человек.
Ну, я предполагал что наличие отрицательной обратной связи и то, кто ее обеспечивает в данных кейсах - факт сам собой разумеющийся. И я ни в коем случае не отрицаю необходимость тестирования, как дисциплины. Я ставлю под вопрос необходимость в каждом конкретном случае отдельной группы людей, которые занимаются контролем качества и ничем другим. Судя по всему, существует не высказанная, но крепко укорененная в головах большинства IT-специалистов мысль, что отдел тестирования совершенно необходим в каждом серьезном проекте. По мне так этот вопрос открытый, и он должен решаться исходя из конкретной ситуации.
Для начала, качество кода и баги. Разработчик обязан тестировать свой код. Это - такая же часть процесса разработки, как и написание кода. И как-то, кроме вырожденных случаев, он это делает. Хотя бы запускает программу разок и смотрит в дебаггере, что написанный им код делает примерно то, что написано в задаче. К сожалению, полноценно тестировать свой код разработчик часто не умеет или не желает. То есть, по-честноку делает половину своей работы.
Помнится, у Баранцева была замечательная лекция(смотрел на ютубе, но сейчас сходу ссылку вряд ли дам), где он приводил в пример три модели команд разработчиков(А, B и C), пилящих примерно одинаковые задачи и их взаимодействие с командой тестирования, которой для полноценной проверки(понятно, что такой быть не может, это просто модель) требуется пройти N тест-кейсов(допустим, 60). При этом А - сверхчеловеки, которые не ошибаются, B - почти сверхчеловеки, которые баги делают изредка, и C - команда туда-сюда, которая делает багов существенно больше B, но все еще с виду ок. Даже в такой модели после нескольких итераций производительность команды тестирования, которые работали с С, очень серьезно деградировала.
Моя мысль проста - никакой отдел тестирования не поможет, если работает с командой С. Дыры будут находиться, бизнес все равно будет страдать. А команда B(команды А в принципе существовать не может) и так будет допускать очень мало дефектов, особенно критических(они, очевидно, так или иначе свой код тестируют). И в случае с командой B надо считать, нужен ли отдел тестирования.