Исследовательское тестирование вполне может провести команда без QA(я знаю реальные примеры, когда это делали разработчики и продакты), это совершенно не аргумент, как и не аргумент про тестирование UI, автоматизированные проверки, а сейчас еще и с AI тулзами справляются иногда даже лучше. Ответы на большинство ваших вопросов есть в очень хорошей книжке «Как тестируют в Google». Что же касается цели поста, она такая же, как и во всем о чем я говорю и пишу, QA - профессией инженеров и это нужно понимать и прокачивать эти навыки. Преувеличивать роль ручного тестирования для гиперболизации значимости своей работы уже становится все сложнее и в хорошо построенных командах этот процесс вполне может быть заменен и заменяется на практике. Кроме этого, я не писал только про автоматизацию и что это ключ к отказу от ручного тестирования. Большинство делят QA на ручное и автотестирование и мыслят бинарно. Однако направление QA по хорошему это на много шире, чем просто тестирование(ручное или автоматизированное). Это могут быть релизные процессы, инцидент менеджемент и тд, тп, где зачастую не хватает экспертизы. Но опять же, из-за низкой квалификации и ответственности команды, QA вынуждены проводить то самое исследовательское тестирование и находить тонны багов, которые не смогла предусмотреть разработка, проседая и не развиваясь в озвученных выше направлениях.

"... тестирование МОЖЕТ провести команда без QA..." "... тест UI с AI тулзами ИНОГДА справляются даже лучше..." "... в книге как тестируют в Гугл.." Никто и не утверждает что девелопер НЕ МОЖЕТ тестировать, может даже лучше какого-то тестировщика. А ещё он может воду в кулере менять не хуже грузчика)))) Вот только платят ему больше чем тестировщику, может тогда вместо +2 девов в команду взять +трех QA?))) а оставшиеся девы пусть быстро и эффективно пишут код) Я что хочу сказать, если некому тестировать, а тестировать надо, то конечно делать нечего пусть хоть кто-то этим займётся. Но при нормальных процессах вы тратите не эффективно деньги компании. Разраб в целом может и функции девопса на себя взять. И с заказчиком общаться. Если у вас например стартап и в штате 5 человек, так и будет. Но если у вас  налажены процессы - это будет не эффективно и выглядит как регресс в разработке к началу 2000х годов, когда не было никаких тестеров, дата инженеров, аналитиков, пм и т.п. Вы просто начали пост с ответственности за качество, которую несёт вся команда а не только QA (и это так), а потом пишете что и без QA можно обойтись и это в целом хорошая практика))) Ясное дело, разработчик может (должен) кликнуть на кнопку которую добавил. Увидеть что она впринципе работает как задумано. Но говорить что он во всех случаях сделает это так же как и QA - преувеличение)

Дополню немного: есть тренд о котором вы пишете, и мне кажется он больше не про то, что QA можно заменить разработчиком, а то что рынку нужен QA который может и бизнес-код писать. И это следствие того, что IT рынок становится менее сытым чем раньше и всем снова нужны универсалы, которые могут всё по чуть-чуть) Впрочем это всего лишь моё мнение)))

Не понимаю смысла спорить и говорить о цене часа разработчика, если выше, в самом посте именно об этом и написано. Я же парировал аргумент в комментарии про исследовательское тестирование и тестирование UI в частности, что звучало так, как-будто кроме QA это никто не может сделать. Что касается скатывания к 2000-м, Вы опять не уловили посыл. А он был такой, что вместе с развитием технологий, должна расти и экспертиза во всех областях, в том числе и QA. И чем вышел качество разработки, ответственность каждого члена команды и уровня автоматизации, тем больше инженерных задач может решаться силами QA. Но ряду организаций это и не нужно, т.к. главное для них не наше IT, а деньги, которые они зарабатывают. Поэтому безусловно ручное тестирование и в частности исследовательское , как и руки, которые будут его проводить нужны сейчас и будут нужны еще долго. Получилось какое-то повторение того, что уже написано.

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

Напомнило "По возможности будьте богаты и умны." 😁

В данном случае это просто речевой оборот, контекст для большинства людей не сильно погруженных в вопросы направления QA и его разнообразных сфер деятельности. Ручное тестирование == QA для большинства, к сожалению.