azShoo

Я бы сказал, что для начала вам стоит поглубже почитать про теорию тестирования как такового.
Если уж совсем лень и не хочется собирать информацию из интернета по кускам, то берете любую книжку по тестированию ПО и читаете.
Напр. https://www.amazon.com/gp/product/158053791X/ref=p... или https://www.amazon.com/gp/product/0471469122/ref=p...

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

Что представляет из себя автотест:
Автотесты это код, который с помощью специальных инструментов и библиотек (напр. Selenium и WebDriver для веба) симулирует определенный сценарий поведения пользователя и проверяет результат этих действий по какому-либо критерию.
Задача автотестера - написать этот код, описать сценарий поведения и условия проверки результата.
Для нужны базовые навыки программирование, некоторое время мучительно разбираться с особенностями работы инструментов автотестирования, а так же четкое понимание что и зачем вы хотите автоматизировать.
Соотв. как только вы понимаете, как работает система и что конкретно вам нужно проверить - берете любой из миллиона гайдов в поисковой выдаче "Test Automation Tutorial from Scratch" и приступаете.

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

ТДД про то, что бы писать тесты до кода.
Зачем это надо? Потому что такой подход помогает лучше структурировать в голове необходимую функциональность перед написанием непосредственно кода.
Такой подход позволяет избегать избыточного усложнения кода, потому что подход "tests first" не позволяет написать полотнище сложного кода, не проверив правильность его работы.
Плюсов достаточно.

Теперь по поводу того, нужно ли ТДД всегда.
ТДД нужно не всегда, как и красивый, производительный и правильно работающий код.
Иногда, нужно закостылить MVP, проверить бизнес-идею и продолжить жить. В таком подходе 20% времени, потраченные на юниты - непозволительная роскошь.
Иногда, вы пишете систему, сложность которой такова, что держать в голове матрицу состояний даже одного модуля не представляется возможным. И тут уже без юнит-тестов никак. Тут ТДД будет полезно.

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

Пример лень гуглить, проще ответить на ваш вопрос.
Page Object разделяет автотесты на три уровня:
1 - Локаторы. Это, фактически, набор констант.
Выделять их в отдельные файлы и классы нужно по двум, основным, причинам:
- Так их проще поддерживать и актуализировать. А борьба с "устаревшими" локаторами - это чуть ли не половина всей работы по поддержке автотестов в рабочем состоянии.
- Для того, что бы можно было ссылаться на один и тот же элемент в рамках разных страниц.

2 - Страницы и их объекты:
На этом уровне абстракции содержится бизнес логика приложения и её интерфейсное воплощение.
Такой подход, опять же, позволяет упрощать поддержку. Структура автотестов соответствует структуре интерфейса.

3 - Логика тестов.
Здесь уже содержатся конкретные степы и assertы для оных.

Такое деление позволяет чётко понимать, что и где тебе надо менять в зависимости от ситуации.
Поменялся элемент, но логика приложения осталась прежняя - заменил локатор. Поменялась логика и структура приложения - актуализируешь Page. Нужно актуализировать\дополнить сам тест (т.е. последовательность степов и Expected Result) -> меняешь сам тест.

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

Нет, без написания тестов на каком-либо языке программирования автоматизировать толком ничего не получится.
В остальном - инструментов автоматизации куча, начиная с Selenium. Ничего космически сложного там нет.

Вы сформулируйте, что конкретно не нравится в Behave.
В целом поисковый запрос Python BDD framework вернет вам довольно много вариантов.
Другое дело, что тот же Бехэйв из них - самый популярный, на мой взгляд.

А ещё учитывайте, что в большинстве случаев использовать BDD-семантику тестов (которую вы описали) - долго, мучительно и для большинства продуктов неистовый overhead.
Проще написать свой микрофреймворк на базе селениума + пресловутый pytest.

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

По браузерам - оптимальное решение это виртуалки, нет - browserstack и альтернативы (или упомянутый уже сауслабс).
Использовать девтулс и эмуляторы предыдущих версий (например для IE, как выше советовали) - только для "очень грубой" проверки. Точных результатов там не ждите.

Первое, что стоит сказать: на такой вопрос нельзя ответить правильно, т.к. слишком размытая формулировка. Это как "как правильно писать код?".

Касательно самих оценок.
Как уже выше озвучивали, есть вариант с оценкой на тестирование исходя из времени на разработку. Хотя с формулой:

QATime = (DevTime*0.35)*0.3;

Я категорически не согласен. Более реальной оценкой выглядит 0.3 от времени на разработку.

Второй вариант - отталкиваться от количества тестовых сценариев.
Я предпочитаю рассчитывать именно так.
1) Оцениваем объемы задачи.
2) Прикидываем примерное количество тест-кейсов (проверок) на данную задачу.
3) Умножаем кол-во на примерное среднее время прохождение кейсов (для веба это в районе 4х минут, дальше зависит от специфики отрасли).
4) Закладываем риски в 0.66 от оценки

Ну, в целом как-то так.

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

С ходу могу предложить только аддон к жире zephyr, который несколько упрощает и облагораживает процесс написания и прохождения тестов, выделяет их в отдельную сущность и добавляет пару других ништяков.
+ стоит посмотреть в сторону различных test management system типа TestRail, TestLink, HPQC и прочие.
Их довольно много, есть как платные, так и бесплатные.

И так.
1) Забейте на курсы. Первое к чему вам надо привыкнуть - самообучение.
Искать нужную информацию, усваивать, применять на практике.
Это касается как ручного тестирования, так и автотестов.

2) Вам посоветуют много книг, вроде "Тестирование dot com". Книжка, конечно, неплохая и дает общее представление, но лучше почитать тематические материалы в интернете. Воды меньше, профита больше.

3) Для того, что бы пойти Junior тестером нужно:
- Понимание платформы хотя бы на базовом уровне.
(Если веб-приложение, то основы клиент-серверного взаимодействия, и вообще, как всё это чудо работает. Если мобильные - почитать про платформы).
Все это описывается в статьях типа "Тестирование %имя_платформы% приложений for dummies"
- Общее представление о процессе разработки.
- Общее представление о тестировании.
(Что есть баг(как описывать, что есть приорити и северити, т.д. т.п., что такое тест-кейсы, тест-сьюты, тест-степы, зачем нужно тестирование вообще + базовые практики тест-дизайна хотя бы на уровне общего представления).
- Работа с БД ( всякие примитивные селекты, джоины и прочее).

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

Ну и да, стандартный совет:
Открываете hh.ru, ищете вакансии, наиболее часто встречающиеся требования - постигаете в первую очередь, дальше - всё остальное.