Николай

Проблема системная, и заключается она в том, что на вашем проекте нету нормального Product Owner / Project Manager с опытом в управлении продуктом и командой. Если те люди, которые должны выполнять задачи вышеназванных ролей, являются со-основателями компании или приближенными, то скорее всего изменить что-то будет сложно. Ну разве что они адекватные и до них можно достучаться - тут вам виднее.

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

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

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

-- выучится на тестировщика гораздо проще;

-- довольно часто на это место берут даже людей с улицы, достаточно знать лишь общие теоретические вопросы в сфере IT (как в том анекдоте про цвет учебника на экзамене), обучают прям на месте, а бывшего программиста вообще оторвут с руками;

Порог вхождения в тестирование ниже, чем в программирование - это правда. Но ближе к Senior-уровню ситуация меняется: хорошим тестером быть дано не каждому. И я даже не говорю по Automation. И не буду говорить что есть три уровня тестеров: Tester, QC, QA (последних вообще мало).

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

Тестирование - во многом:
1) Про умение писать техническую документацию: тест-планы, тест-кейсы, баг-репорты. Писать нужно очень много - это 70 процентов работы.
2) Про коммуникацию. Необходимо общаться и эффективно получать информацию от BA, Dev, Customers, Stakeholders
3) Про способность докапываться до сути и понимать потребности бизнеса. Dev может делать только свой кусочек работы, а QA должен понимать как это работает в целом.
4) Технические навыки и хотя бы общее понимание того, как пишется код - тоже обязательны.

И, в целом, в QA много рутинной работы, с которой не все справляются.

-- знание ООП, алгоритмов, синтаксиса ЯП является бонусом, но не всегда это обязательно;

Чем больше вы знаете, тем больше вы стоите. Конечно ООП нужно знать.

-- тестировщики постоянно востребованы, почти так же как и программисты;

Безусловно

-- почему тогда все не идут в тестировщики, вместо программистов? Из-за любви к программированию? Или лишь потому что программистам платят немного больше?

Читайте выше - работа QA не для всех в виду ее специфики.

-- можно ли устроится тестировщиком после 34 лет (в вакансиях конечно требования к возрасту не пишут, по понятным причинам)? Слышал, что это в основном для молодёжи..

Можно, но сложнее, кто бы вам не говорил иначе. В странах СНГ средний возраст айтишника пока около 28-30 лет, хотя в штатах уже давно значительно выше.

-- правда ли то что тестировщики с опытом работы так же востребованы за рубежом как и программисты?

Да

-- если кандидат пройдёт онлайн курсы тестировщиков, это повысит его шансы при приёме на работу в IT компанию?

Сомнительно. Лучше почитайте Коупланда (Copeland)

-- и верно ли то что раньше (лет 10 тому назад) тестировщиком легче было устроится без опыта, "с улицы"?

Скорее всего да, хотя тех, кто шел в тестирование было меньше, но и IT-компаний было тоже в разы меньше.

Я последнее время часто провожу собеседования тестеров. Начал вам подробно отвечать, получилось столько текста, что решил написать на эту тему полноценную статью. Правда там больше информации по найму manual junior. Но на некоторых вопросах посыпется половина и более опытных QA. Разместил ее на спарке в блоге нашего проекта: https://spark.ru/startup/neaktor/blog/31094/nanyat...

Краткое содержание вопросов по самому собеседованию:

• Что такое вообще тестирование?
  
• Что такое blackbox / whitebox / graybox?
  
• Жизненный цикл бага / ПО?
  
• Чем отличается чек-лист от тест-кейса? Когда стоит их использовать?
  
• Виды / типы / уровни тестирования
  
• Техники тест-дизайна. Минимальный набор: Boundary Values, Equivalence Partition, Decision Tables, State Transition. Более продвинутые: Pairwise например. Решите практическое задание по составлению тест-кейсов с применением техник тест-дизайна, которые знаете. Explorative - не в счет
  
• Логические задачи
  
• Вопросы на адекватность. Что делать, если вам возвращают тикет в Reject? Не знаете как тестировать какой-то функционал. Что делать?
  

Отдельно тестовым заданием проверяется оформление дефектов.

Большинство вопросов "открытые", то есть можно остановить соискателя в любой момент и попросить уточнить какие-то делали. Например, "Тестирование производительности? Давайте остановимся подробнее. Какие подтипы знаете? Чем отличается Load от Stress тестинга? Как вы будете проводить тестирование производительности?"

Или вот например еще задача на подумать. Когда тестирование интерфейса является функциональным тестированием, а когда нет? Приведите пример.

Если говорить про собеседования senior, то более технические вопросы обязательны. Артем выше привел неплохие примеры. Но тут можно вообще про много что спрашивать. От как вы будете тестировать API до запросов в noSQL базы. Также у тестеров с опытом спрашивать про матрицы покрытия тестов, тест-планирование, цикл разработки тестовой документации и так далее.

Надеюсь вам поможет.