1FinTech

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

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

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

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

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

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

1. Да, может. Это полноценный браузер на базе webkit.
2. Любое headless ПО способное работать с DOM. CasperJs, Slimer, FireFox, Chrome.
3. Зависит от контекста задачи. Но на вскидку можно сразу предупредить, что PhantonJS базируется на старой версии движка которая может отработать JS некорректно. И в этом случае какой-нибудь FireFox или Chome последних версий в headless режиме будут предпочтительнее. Выясниться это в момент "о, блин, а фантом не умеет это js кушать".
4. Как готовый продукт нет, не существует. Как платфома - любой.

Во первых, что такое "хороший" программист, это сложно определить. У нас тоже есть программисты, они вроде работают и деньги получают, и с образованием, а когда в продукте обнаруживаются проблемы, выясняется что логгирования в компонентах нет, о юнит-тестах никто не подумал при написании, а теперь придется рефакторить чтобы их туда прикрутить, да и если бы заранее подумали о тестировании и написали юнит тесты, то этих проблем бы не возникло сейчас. А теперь чтобы исправить проблему, нужно перекраивать код целыми слоями, а продукт уже в фазе стабилизации и просто так туда изменения не зальешь. Ну ладно можно сказать это джуниоры напортачили. Но у нас и сениоры есть, под чьим руководством они работают. И сениоры прекрасно знают как делать правильно но не требуют этого от остальных.
Я все это к чему - можно фигачить код со скоростью электровеника, а можно писать его медленно. Скорость написания кода не говорит о том хороший программист или плохой ничего. Совсем ничего. Можно быстро писать плохой код.
Гораздо важнее правильно мыслить. Для этого нужно читать книжки типа Clean Code. Юнит тестирование тоже. Нужно приобрести понимание хорошо и плохо. Если вы читаете код и в нем черт ногу сломит. Может это плохой код?
Чтобы набить руку в программировании нужно им заниматься. У меня постоянно открыт repl.it где я набиваю мелкие куски кода для развлечения. Нужно постоянно тренироваться, "ни дня без строчки", только тогда мозг перейдет из режима отторжения в режим обучения. Заставляйте себя, заставляйте себя разобраться. Разберите как работют лямбды, list comprehension. разберитесь в *args, **kwargs. Выясните разницу между __new__ и __init__. Для новичка это приличная нагрузка, но вы должны поверить в то что осилите это. Иначе будете всегда пасовать.
Почитайте гайдлайны по питону docs.python-guide.org/en/latest/writing/style
Питон очень стройный язык, он вам не сломает мозг как какая нибудь ява. Читайте хаб по питону на тостере, на хабре. Я например пытаюсь решить задачки которые пролетают тут по хабу, и улучшил свои знания питона за счет этого.
Удачи, надеюсь смог хоть как-то помочь.

Сделайте ветку dev
пусть облако веток задач будет вокруг дева: каждая ветка тестируется по отдельности, а после тестируется их совместимость между собой (я так понял, это и есть причина, по которой нельзя тестировать ветку без подтягивания изменений из мастера).
После фидбека QA по dev-ветке сливать dev в мастер.
А еще лучше сделать dev->stage->master.
На деве тестить слитые ветки, на stage - целые релизы.

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

Например, ваше представление: "ООП удобен для бизнеса, можно разделять программу на модули" - неверно.
Модульность появилась задолго до ООП. Бизнес появился задолго до программирования, и ООП и бизнес не слишком и связаны.

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

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

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

И напоследок - полиморфизм и все другие фичи ООП - это уже следствие того, что парадигму стараются сделать максимально гибкой.
Самая главная суть ООП заключается в следующем:

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

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

Как мне сделать такое ценообразование, чтобы и мне хорошо было и заказчика устраивало?

Какую бы цену вы не поставили, она не будет устраивать всех в мире клиентов. Фокусируйтесь на такой, чтобы она вас устраивала, а при должном уровне работы, будут находиться клиенты на любую цену.

Также очень интересует, как быть в случае появления каких то багов..

Брать деньги за их исправление, разработки без исправления багов/рефакторинга не бывает.

Делаете ли вы какие то скидки может или акции для заказчиков и т.д.

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

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

Регрессии это нормальное явление. Почему такое происходит в принципе - интересный сам по себе вопрос.
Регресс появляется когда добавление нового кода или изменение старого не учитывает всех задействованных частей программы.
Отсюда можно сделать вывод, чтобы минимизировать эффект от регрессии, нужно огранизовывать код так, чтобы при его изменении, можно было легко понять, на какие другие части логики это изменение влияет. Именно это является целью создания идеальной архитектуры приложения. Чтобы все было по полочкам. Чтобы доставая из шкафа полотенце, вам на голову не падала матрешка которая стоит на шкафу сверху (кто ее туда поставил, и почему - неясно, записку с комментариями никто не оставил)
Чтобы бороться с наваливанием кода в кучу - нужно чтобы кто-то следил за тем чтобы его не наваливали в кучу. Архитектор например. Архитектор это такой ландшафтный дизайнер для кода. Но нужен и садовник. Чтобы лужайки были зеленые, а огурцы не расли на грядке в перемешку с морковкой. Фреймворки конечно тоже отчасти справляются с этой задачей. Фреймворк для того в принципе и служит, чтобы для каждой части приложения была своя песочница. Мол, складывай вещи как хочешь но в коробки 40х50х30. Текстиль сюда, кухонную утварь сюда. Коробку подписать, занести в реестр. Как на складе.
Но ничто не защитит вас от того, что в коробки накидают не того что там должно быть. Надо проверять (тестирование). Выстраивать процесс таким образом чтобы ошибиться по халатности было трудно (архитектура). Чтобы было легко локализовать источник ошибки (логгирование). Систематично избавляться от сложности во всем (здравый смысл).