Ох уж это «всё», которое сводится к «веб приложения».

Но да, на JS можно с переменным успехом писать под несколько платформ.
Это, правда, не значит, что для тех же мобил оно нормально заменяет нативные инструменты. :)

На реакт нейтиве и его аналогах кучу всего сделали уже

-- Завели даже термин "тестирование требований" -- какие есть вопросы, чего может не хватать

-- Была пара команд где аналитика не было, а команда "оценивала" предложение на разработку. Просматривал это я, находя проблемные места, в результате команда могла вообще отказаться от проекта. Иногда в том "чего хотят" можно сразу увидеть проблемы.

-- Если аналитик или ПМ или кто пишет спецификацию на проекте недавно, или пишет под участок который не очень хорошо знает, "нужен глаз да глаз" чтобы вовремя сказать "это так не работает". Один новый продакт менеджер смотрел на меня с недоверием когда я говорил что на спецификацию в конфлюэнсе я могу написать ~40 замечаний, но он понял как это когда на его "первый блин" я написал ~30.

-- Иногда проблемы могут появиться по поводу разработки, а ты знаешь как этого избежать, -- если включился пораньше, а не на собранное ближе к концу. Пример: разработчик решил что он "знает как надо" и стал пилить графику сам. Но графика у разработчика получается грубая и некрасивая. Чтобы такой проблемы не возникло надо свести разработчика с дизайнерами и договориться (как бы это должен делать ПМ, но не всегда сделает). От подобных вещей (в том числе) зависит зарелизится ли фича вовремя, или, от количества и качества найденных проблем, займёт ещё спринт.

-- Я не раз сталкивался с тем что аналитики и тестировщики видят требования несколько по-разному.

Аналитик:  зашёл на страницу сущности, что-то изменил, появилась кнопка сохранения. Всё просто.

Тестировщик: зайти на страницу сущности можно четырьмя способами, изменить можно A, B, C и D. Ооооо, это подольше тестировать.

И что ещё будет если я изменил а потом опять поставил как было?

-- Бывают ситуации когда тестировщик а) работал по разным командам или задачам, б) общался-общается с другими тестировщиками, и знает больше чем команда: 1) какой может быть импакт (что новый функционал может зацепить)  2) какие фичи разрабатывает другая команда, и как они могут пересекаться с новыми для этой команды (соответственно тестирование может занять больше времени). 3) или наоборот, чего "мы от другой команды не получим"

Чтобы тестировщик и аналитик не расходились во взглядах, нужен тест-аналитик. ))

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

Тогда расходится во взглядах будут тестировщик, аналитик и тест-аналитик

И тестаналитик не может расходиться во взглядах ни с тестировщиком, ни с аналитиком?)

ISTQB тоже советует привлекать тест-аналитика как можно раньше, но с оглядкой на потребности проекта. (Advanced Level Syllabus - Test Analyst - 1.2 Testing in the Software Development Lifecycle)

может, конечно. Разве существует какая-то незыблемая истина? Возможно всё.

Я просто к тому что раз дело не в названии должности, то может проблему разногласий имеет смысл решать как то иначе?

И как это противоречит тому, что я написал?

Всем привет! Расскажите кто как обучался и сколько, до момента трудоустройства на джуна...?

Всем привет! Расскажите кто как обучался и сколько, до момента трудоустройства на джуна...?