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

Мануальное тестирование хорошо помогает закрепить теорию тестирования на практике, а реализовывать тестирование лучше с помощью кода.

Чтобы ворваться в ИТ нужно портфолио и его проще создать сразу автоматизированное.

Изучите 4 инструмента: docker, pytest, playwright и allure.

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

9 месяцев назад дёрнулся переквалифицироваться из тестировшика в полноценного разработчика, под это даже уволился, теперь вот, как и многие столкнулся с проблемой в найме.

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

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

Добрый день!

Мой карьерный путь состоит из двух вех: 1. Тестирование "железа" (2011 - 2023). 2. Тестирование ПО (2023 - н.в.).

И в первой и во второй вехе "прошёл" игру до конца. Начинал с джуна и миддла соответственно и заканчивал лидом.

Если классифицировать по специализации, то мой карьерный путь бесшовно перешёл из полностью ручного тестирования в полностью автоматизированный.

Это было связано с тем, что в "железе" полная автоматизация невозможна (если не подключать робототехнику для подключения различных проводков), а в тестировании ПО таких проблем нет.

Если классифицировать по предметной области, то на своём пути я побывал в разных продуктовых доменах: 1. Программно-аппаратные комплексы. 2. Финтех. 3. Инфобезопасность.

Если классифицировать по способу организации труда, то в основном работал в scrum и kanban методолгиях, где-то в канонической реализации, где-то с большими отклонениями (без спринтов и планирования).

За весь свой путь мне удалось посмотреть как устроены процессы в разных компаниях, что их объединяет и что отличает, трижды выстроить процессы "с нуля".

Всегда нужно подходить от потребностей, от контекста, от возможностей компании. Например, когда я работал на МосБиржу, там нельзя было даже #docker и #locust нормально поставить. Поэтому приходилось обходиться чисто своими скриптами и "поднимать" самописные сервисы без изоляции.

Однажды я даже положил тестовый сервер, запустив самописный сервис по нагрузочному тестированию (любопытно, что объект тестирования не упал :))

Как минимум есть два подхода: 1. Посмотреть как у других (бест-практис) и сделать также. 2. Сделать всё своё (например, на python).

Лично я опираюсь на python, pytest, allure, redis, celery, docker...