Тут нужно учитывать short term vs long term benefits.
В краткой перспективе, конечно, намного быстрее просто протестировать мануально. И действительно есть такие короткосрочные или маленькие проекты, где нет смысла инвестировать в автоматизацию.
Но в долгой перспективе, особенно если проект долго живёт, намного эффективнее писать сразу автоматы. Это займет дольше времени во время девелопмента, но в будущем это окупится не один раз. И это типичная ошибка которую допускают и я не советую ее повторять. Выглядит это так — проекты тестируют мануально, приводя похожие аргументы что это быстрее и легко, потом настпуает момент когда регрессия занимает слишком много времени, и тогда начинают вовлекать автоматизаторов. Но проект уже накопил очень много технического долга, а можно было сразу выбрать правильный подход с расчётом на будущее

Понимаю, у меня не было опыта в embedded, может там действительно это немного иначе выглядит. Насчёт тех книжек, то интересно, учитывали ли они другие пользы от автоматизации кроме сокращения времени на регрессию.
Например то что намного легче делать рефакторинг, т.к. есть «safety net» из тестов, которые быстро найдут баги. Также то что автотесты запускаются регулярно, и фидбек будет намного раньше перед релизом, и нет такого что во время мануальной регрессии вдруг находятся десятки багов и срочно их все нужно успеть пофиксить. Мануальные тестеры физически не смогут постоянно делать всю регрессию вручную.
Но я конечно соглашусь, что чем чаще релизы в проекте тем автоматизация приносит еще больше пользы

Это правда, но всё равно есть польза от участия AQA/QA (приготовление тест кейсов, ревью тестов), т.к. у тестеров другое мышление чем у девелоперов.
У нас в нынешнем проекте когда девелопер сам пишет тесты, то обязательно должно быть ревью от AQA

Или до/после автоматизации
Часто именно так и бывает, в проект внедряют автоматизацию и сразу меняются метрики в лучшую сторону.

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

1. Конечно меняются, таких проектов не бывает
2. Неправда, автоматизация всегда влияет на capacity, но это учитывается. Это инвестиция в будущее, вместо того чтобы сделать как можно быстрее в короткосрочной перспективе и накапливать технический долг
3. Регрессия в любом случае будет увеличиваться если проект не стоит на месте, и постоянно добавляются новые фичи. Идеальное решение — девелоперы пишут прогрессивные тесты, AQA — занимаются регрессией. Тогда и тех долг не увеличивается и регрессия сокращается
4. Пункт выше — не обязательно чтобы вся регрессия уже была автоматизирована

Прогрессивные тесты полезны и в таких проектах, конечно это требует больше усилий если у проекта большой технический долг. Но в любом случае подход «работаем только над регрессей» не решает эту проблему, т.к он будет постоянно увеличиваться от новых фич без автоматизации

Спасибо)
А вы вовлекли девелоперов в автоматизацию? Так обычно случается когда AQA не успевают за девами, их обычно меньше

Тоже согласен с первым пунктом, со вторым есть риск — всё таки есть ценность в том что у QA другая перспектива чем у девелопера. Девелопер будет пробовать доказать что его код работает, а QA наоборот — ищет ошибки

Мануальные QA могут помогать создавать тест кейсы вместе с AQA, или заниматься exploratory тестированием. Но в общем должен быть тренд — как можно меньше мануальной работы и максимум автоматизации.
Да, протестировать мануальнее вроде как быстрее, но это только в короткой перспективе. Не лучше ли сразу автоматизировать чтобы потом не повторять ту же работу?