Так мы всегда в это упираемся :) Потому что критерии оценки вообще слабо связаны с конкретными реализациями, наоборот, реализации подстраиваются под критерии.
По-моему, внедрение любых решений нужно обкладывать метриками и смотреть на результаты.

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

Если разраб вообще не будет себя тестить - бизнес заплатит три раза, потому что в таком случае на тест прилетает совсем сырой результат, и возвращается на доработку с кучей багов.

Зависит от,  если допустим ценность для бизнеса наступает на этапе эксплуатации продукта, то разрабы смотрящие на задачу не только с точки зрения написания кода, но и с точки зрения как его развернуть, как его протестировать,  как его зарелизить, как его эксплуатировать и прочие этапы, обычно прилично снижают общее время выполнения задачи, как минимум тем, что она реже возвращается на предыдущий этап.
А для этого им нужно хоть иногда участвовать на каждом этапе.

То же можно сказать и про тестеров

Могу предложить подход, который мы реализовали: я вместе с автором спринта проектирую спринт, описываю с технического языка инструкции для разрабов, и тестирую после того, как спринт вываливается на dev. Если мне что-то не нравится или нужно что-то добавить, мы это обсуждаем с разрабом за кем закреплён спринт, но конечный ответ всегда за ПМ или автором спринта.

А если разраб будет тестить себя полностью и хорошо - то тестировщики не нужны.

Я говорил про двойную работу, а не про "вообще не будет". Критерием приемки в тестирование вполне можно назначить работу sunny day scenario, и при его невыполнении задачу заворачивать.

Естественно когда смежные задачи полностью вытесняют основные это перегиб

Вот на счет инициативы согласен! Таким образом тестировщик растёт и в плане профессиональном и в проект лучше вникает, а чем лучше вникаешь, тем больше зависимостей находишь, что полезно для поиска багов :)

А тестировщики и не нужны, нужно тестирование и то не всегда

>обычно прилично снижают
Вот бы конечно на цифры посмотреть, но где ж их взять.
Еще раз, Я не утверждаю, что разработчик не должен делать X, или тестировщик не должен делать Y. Я говорю о том, что X или Y надо делать один раз, для редких важных случаев (смоуки, приемка и прочий регресс) - 2 раза. Но не делать так, что разраб делает X, потом тестер делает X, потом девопс делает X.

А оценивают всех по Z

Меряешь до того как это начинается, вводишь такую практику, меряешь после, дальше уже математика

В конкретном случае "тестировщик должен предлагать решение" - in general не должен, поэтому если предлагает - не может считаться "хорошим" на этом основании. Может? конечно, но на общественных началах. Должен? конечно, если это есть в процессе, и от этого всем профит, но это - редкость.

То как Х (тестирование) делают разработчик, тестировщик, другой тестировщик, пользователь и прочее это разные иксы

спасибо :) у меня тут логист под боком, он же со вчера пм, и разрабов мучаю, я всех мучаю. До слез сегодня разраба доведу чую

Если разные - тогда это не X, а разные сущности. Но часто - одинаковые

Четкое разделение обязанностей приводит к тому, что разработчик оценил задачу к примеру в 8 часов работы. Сделал ее не спеша за 8 часов работы, отправил в тестирование. По результатам тестирования оказалось, что выполненный результат задачи не учитывает целую гору разных ситуаций, задача отправляется на доработку и уже в спешке дорабатывается еще 8 часов. Потом снова проходит цикл тестирования и дорабатывается еще 4 часа.

При этом, если бы разработчик хотя бы частично сам проверял выполнение своей работы - итоговое время разработки вышло бы меньше.

На истину не претендую, но по моему опыту результат именно такой.

Мерить можно каждый этап отдельно,  но принимать решение о хорошая тенденция или нет стоит по общему времени

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

То есть озвученные проблемы — не в разделении обязанностей, а в процессах.

Впрочем, никто не говорит, что люди не должны тестировать, потому что они не тестировщики, или не думать про архитектуру, если они тестировщики.