Алексей

пожалуйста используйте юзер агент как у браузера например

options.add_argument("user-agent=Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36")

Попробуйте MyTetra
Также посмотрите интересную статью автора Самая нужная программа на свете на хабре.

Получается, что я связующее звено между всеми отделами (Производство, Бухгалтерия, Логистика) - придумываю решение а индус все это дело кодит.

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

Для начала давайте разберемся, что же такое QA? Понятие это довольно абстрактное, и в СНГ применяется зачастую в ином понимании, нежели в краях более отдаленных.
QA - это обеспечение качества продукта, причем, в идеальном случае, на всех этапах разработки.
Самое первое, с чем придется в большинстве случаев столкнуться QA Engineer`у это функциональное тестирование.
Написание тестов по задачам и прохождение этих тестов., прохождение уже написанных, апдейт, заведение багов и прочее. В этом случае QA Engineer = Тестировщик. Для этого самое важное - хорошо работающая голова, умение читать задачи и задавать правильные вопросы: "А что если так? А если этак?".
В зависимости от продукта требуются дополнительные скиллы -> в вебе своя специфика, в мобильных своя, в по - своя, в железе - своя. Ну и соответственно базовое понимание кода, работа с базой данных и прочее - тоже периодически понадобятся.

Но, процесс обеспечения качества не заканчивается на функциональном тестировании, поэтому понятие QA шире, чем тестирование. Здесь мы уходим от банальных тестов по функциональным требованиям и переходим к анализу требований и документации (поиск узких мест в требованиях и реализации), юзабилити тестирование (поиск "косяков" в интерфейсах и функциональности), тестирование производительности и прочее.

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

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

Что в итоге?
Мне кажется, что QA-инженер это тестировщик, который вышел в своей работе за рамки тестирования. Который работает над качеством продукта не только в плане "Требования выполнены - к продакшену готовы", а старается делать продукт лучше во всех отношениях, в первую очередь - для бизнеса, во вторую - для пользователя, в третью - для тех, кто этот продукт делает.
Следовательно, я считаю что путь QA лучше всего начинать именно с тестирования (кстати говоря, в России понятия QA и тестирования почти всегда тождественны в умах не-тестировщиков).
Что важно для тестировщика?
Способность и желание разбираться в том, как это [продукт\фича\пр] работает сейчас, и как это должно работать.
Так же стоит приготовиться много говорить "нет, так не пойдет" менеджерам и разработчикам.
Ну и вообще, смириться с тем, что другие стороны процесса очень часто готовы действовать в ущерб качеству.

Что хотят, что бы знал джуниор?
1) представление о процессе разработки. Этапы, когда пора тестировать и все такое.
2) представление о написании тестов: что представляет из себя тест-план, тест-сьют, тест-кейс, тест-степ, Definition of Done, Ожидаемый результат и тд.
3) представление о том, что такое дефект: Severity и Priority дефектов, какие бывают; из чего состоит описание дефекта, и все такое.
4) хотя бы общее представление о тест-дизайне: что такое, зачем нужен, какие есть практики.
5) Базовые навыки SQL - селект, упдейт, работа с несколькими таблицами и все такое.
А ещё хотят, что бы человек умел думать. Будь готов к задачкам на логику (которые туфта и ненужны) и к задачкам типа "Есть окно с кнопкой, посылает запрос: напиши тесткейсы" или "Протестируй карандаш".

Как-то так.
К сожалению, больше рассказал именно о тестировании, чем о QA в целом. :)

Везде есть как интересные, так и скучные задачи. Вам выбирать, на первых порах вам скучно не будет, в любом случае узнаете много нового, а потом уже можете пойти и искать другие задачи, места работы. Что-то слабо верится, что в СПБ мало вакансий и они все унылые. Можете расти как в ту, так и в другую сторону. Всё действительно зависит от ваших предпочтений и получаемого удовольствия. Вообще, далеко не везде спешат внедрять самое новое и это не зависит от языка и платформы - никто не хочет неоправданно рисковать переходом на новьё без особой на то выгоды. Я бы посоветовал в web. Может станете fullstack. Изучите клиентскую часть и, если уж так не понравится в Java-мире, потихоньку переплывете во front или js-мир. Уж его то прям колбасит от новых технологий, не соскучаетесь.)

Проверять данные в каждом методе - это вполне отличная практика, по сути это соблюдение интерфейса метода.
Но возвращать при этом null/false - практика хреновая, если ваш метод на вход требует int, а получил array - надо бросать исключение. Так вы будете знать, что внешний код, который использует ваш метод работает не корректно.

Для объектов настоятельно рекомендую использовать type hinting:

public function test(MyObject $object, $id)
{
    if (!is_int($id)) {
        throw new \InvalidArgumentException('Argument "id" must be int');
    } elseif ($id < 0) {
        throw new \InvalidArgumentException('Argument "id" must be positive');
    }
...

Если пишете на семерке, то и для скаляров и на вывод - тоже стоит указывать type hinting. Правда с выводом не всегда это можно делать, например возврата null, или что-то еще.

public function checkPositive(int $intData): bool

Для сокращения проверок можете мой пакет заюзать https://packagist.org/packages/ko-ko-ko/assert, он спроектирован под максимальную производительность и использование в каждом методе.

Стоит ли продолжать заморачиваться с проверкой передаваемых данных в каждой функции?

Да. За счет этого вы выигрываете в безопасности, надежности и времени поиска багов.

Есть несколько вариантов вашего дальнейшего развития:

1. Если вы готовы "тренироваться на кошках", смело идите (вернее, записывайтесь) на курсы Software Testing (у них еще полезный форум). Там есть разные варианты, основы вам дадут и это будет крепкая база по небольшой цене (только не выбирайте ускоренный курс, лучше возьмите простой базовый). Перед этим можно заправиться онлайн-курсом Савина и курсом от Mail.ru (про него писали выше). Есть еще бесплатный вводный курс на Udacity.

2. Пойти на стажировку/обучение при крупной IT-компании (так училась я сама). Эти тренинги проводят Epam, ITransition, Veeam и другие. Ищите на хэдхантере по словам "QA/тестировщик/специалист по тестированию", затем выбирайте графу "без опыта". В Питере, кажется, есть несколько открытых позиций. Требуется знание логики и базовое понимание SQL. Кое-где - ООП (это уже зависит от компании и направления). Если указано, что ищут выпускников, а вы уже давно не выпускник, всё равно пишите: мотивацию ценят в первую очередь.

То, что очень сложно понять, не имея опыта, но можно предположить, зная себя и свои способности: решите, каким тестированием вы хотите заниматься.
- Веб-приложения, сайты и т.п.? Продолжайте зубрить Html/CSS/SQL, попробуйте поверстать. Без этих знаний попасть на джуниорскую должность тяжело - конкуренция высока.
- Функциональное - тот же SQL, администрирование (учите запросы в комстроке), язык (лучше Python или Java).
- Плюс, спросите себя, в какой сфере хотите работать. Если игровым тестировщиком, будет проще: на позицию джуна попасть легче, но нужен большой игровой опыт. Кроме того, есть мобильное тестирование, тестирование графического контента и артов и т.д. Подумайте, в чем вы сильны.

Главное, как заметили коллеги, - это заинтересованность, предельная внимательность, умение очень быстро учиться и быть гибким. Не бояться стрессовых ситуаций. Ах, да. И знание английского языка (как минимум) на уровне чтения спецификаций, а лучше - на уровне написания отчетов и баг-репортов.

Подумайте над своим резюме и сопроводительным письмом - в 80% именно они решают, позвонят вам или нет.
Удачи)