AlexIsakau

Сложилось впечатление, что рынок очень сильно переполнен

Верное впечатление.

А как при таком раскладе, ищут работу люди ниже уровня сеньора?

В целом, страшно только в сфере веба, нормальные программисты ищут работу относительно легко.

Может уже прошли те золотые it времена

Да. Теперь это бизнес.

весь хайп о "молочных реках и кисельных берегах" выгоден только вайтишным курсам?

Да.

Вот как это выглядит с т.з. работодателя

Джун
- собеседование
изъясняется исключительно на сленге (большую часть которого не может внятно объяснить), готов в одиночку за неделю написать новую ОС, или две - за полторы, если только для этого не придется учить ассемблер, несмотря на юный возраст уже обладатель прав на обе версии и один бэкап личного сайта с фотографией кошки в розовой рамке и знает, что синглтон - это абсолютное зло, хотя и не может написать его без ошибок.
- испытательный срок
долго мудохается с настройками рабочего места, которые регулярно слетают под тяжестью многотысячных плагинов, шелов и скринсейверов, донимает админов, находит две (орфографические) ошибки в документации проекта и один быстрый альтернативный способ сделать форк из SVN, после которого проект, к сожалению, не билдится не только у него, но и у всей команды. Берется все немедленно исправить с помощью другого чудотворного плагина, (неожиданный баг в котором приходится фиксить двум миддлам), после чего насильственно лишается рута, плагинов и шелов и начинает изучать проект под чутким контролем матерящихся миддлов.
- работа
научился билдить проект, писать тесты и коммитить, не роняя этим билд, понял смысл многих сленговых выражений, подружился с миддлами и админами, не путается в названиях ключевых технологий, радикально сократил число плагинов, удалил сайт с кошкой, работает.

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

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

Понятие еnd-to-end обозначает всего-навсего классификацию тестов по уровню, на котором тестируется система, и, само по себе, ничего не говорит ни о том, какие конкретно должны быть эти тесты, ни о том, какую роль они играют в общей стратегии обеспечения/проверки качества и, также, не является методикой тестирования. (Методика - это совсем другое понятие.)

Для понимания сути этого понятия хорошо сравнить его с модульным ("нижний" уровень) и интеграционным ("средний") тестированием на каком-нибудь конкретном примере. Давайте рассмотрим некий сферический webshop в вакууме. Предположим, в нем есть 50 классов и для большинства из них написаны модульные тесты. Они проверяют исключительно функционал конкретного модуля (чаще всего, класса), т.е. тот, что зависит только от самого модуля и ни от чего чего более. Потом есть интеграционные тесты. Они проверяют корректность работы отдельных "модулей", если их собрать вместе согласно архитектурe. Например, работает ли правильно "Корзина", состоящая, в свою очередь, из 10 классов (предварительно проверенных модульными тестами), или "Корзина", подключенная к "Вебморде" и т.д. Где-то повыше в этой иерархии есть такие интеграционные тесты, которые проверяют конкретный функционал всей системы. Например, отправляется ли юзеру мейлом копия оплаченного заказа...

И вот тут начинается самое интересное для понимания того, что такое end-to-end тестирование! Можно представить себе тест, проверяющий, что соответствующий мейл генерируется и сбрасывается SMTP серверу. Если SMTP сервер не рассматривать, как часть разрабатываемой системы, то этот тест вполне можно назвать end-to-end тестом (послали кучку HTTP запросов через "Вебморду" и проверили сброс мыла на SMTP - все зашибись!). Однако, если настройки и эксплуатация SMTP сервера - часть проекта (например, заказана разработка webshop "под ключ"), может оказаться, что это мыло будет отфильтровано каким-нибудь спам-фильтром, превысит лимит почтового ящика пользователя... короче, не дойдет до него. Тогда этот же самый тест уже нельзя считать end-to-end, а нужно бы было написать тест, проверяющий приход мыла в POP3/IMAP ящик. (Опять же, если это действительно нужно! Ибо, в зависимости от конкретных функциональных и нефункциональных требований, архитектор и QA инженер вполне могут найти возможность обеспечить адекватный контроль качества и без такого теста.)

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

Инста привязана жёстко на первую почту при потере всегда можно ее восстановить если есть доступ к первой почте