Предисловие: имею высшее образование (Специалист по ПО компьютерных систем), полученное в этом году, знаний в области не имею (так бывает). Работаю два года не по специальности. В планах было поступить на курсы этой осенью, к лету 2026 года уволиться и искать работу по специальности.
Изначально рассматривалось направление QA, поскольку мне это наиболее интересно, но теперь появились сомнения в востребованности специалистов в этой области, тем более без опыта работы. Также важно знать, что я проживаю в Ленинградской области, в двух часах езды от центра Петербурга. То есть преимущественно интересует удалённая работа, что накладывает дополнительные трудности в поиске будущей работы. Работа в офисе крайний вариант, но всё же возможный.
К сути вопроса: нужен совет по выбору направления. Какие сейчас наиболее востребованные, но выполнимые в освоении направления для человека с нулевым опытом? Может быть я ошибаюсь в невостребованности тестировщиков? Какие платформы для курсов порекомендуете на своём опыте? Рассматривала школу 21 (но Питера там нет, так что пролетает) или Яндекс Практикум.
Направление QA рассматривалось не как конечное, а как вступительный этап в профессию IT с дальнейший развитием в другой области (например, разработки).
Буду очень благодарна за развернутые ответы от людей, работающих в этой области.
Рассказываем, какие карьерные маршруты есть у тестировщика: с чего начать и какие навыки прокачивать, чтобы выйти на новый карьерный уровень.
Старт в QA и горизонтальное развитие внутри профессии
Ручное тестирование: старт и перспективы
Большинство будущих QA-специалистов стартуют с ручного тестирования, где не нужно глубоких знаний в программировании. QA-инженеры изучают документацию, проверяют продукт, ищут баги и заносят их в баг-трекер. А еще общаются с разработчиками и аналитиками. На этом карьерном этапе важно научиться системному мышлению, внимательности и тому, как устроены веб-приложения.
«Классический» рост в профессии такой:
от junior- до middle-тестировщика — 1–2 года. На этой ступени специалист уже умеет самостоятельно составлять сценарии, постепенно осваивает автоматизацию и учится читать и анализировать код.
до senior-тестировщика — 3–4 года. Он координирует работу команды, наставляет младших коллег и самостоятельно планирует процесс тестирования.
Teaching / EdTech / менторство — при опыте более 4 лет. В эти направления уходят многие сеньоры.
Внутри QA есть много путей для развития. Например, углубиться в UX и улучшать юзабилити продуктов. Или стать QAOps — это альтернатива DevOps, но без перехода в другую специализацию.
Алена Арапи, старшая наставница на курсах по тестированию:
«Для новичков важно знать, что можно стать экспертом внутри QA, например, по API / интеграциям, а не идти в DevOps, углубиться в юзабилити / UX и быть крутым в этом, остаться в ручном тестировании, но вырасти до уровня эксперта.
Есть много интересных сфер:
- финтех (банки, платежные системы);
- медицина (электронные медкарты, приложения для медицинских работников);
- e-commerce (интернет магазины, системы бронирования);
- GameDev (игры на ПК, консолях, мобильных устройствах);
- Telecom (мобильные операторы, оборудование связи);
- Автомобили (автопилот, приложения для автомобилей);
облачные технологии,
- Edtech — платформы онлайн обучения и курсов;
- GovTech — государственные порталы и системы;
- IoT — умные дома, сенсоры;
- Aerospace & Defense — системы для авиации, космоса и военной техники;
- media — платформы стриминга, онлайн кинотеатры;
- логистика — системы для складов, доставки и перевозок и т. д.
Каждая область имеет свои особенности и в каждой из них может развиваться QA.
Подчеркну, что не все хотят уйти из ручного тестирования. Многие растут внутри QA и становятся менторами или наставниками, выступают на конференциях».
Ниже собрали еще несколько актуальных направлений для роста и развития внутри ручного тестирования:
Mobile QA — для тех, кто хочет сосредоточиться на мобильных приложениях;
Security QA — появляется все чаще, особенно в финтехе.
Вертикальное развитие
Переход в автоматизацию
У большинства QA-инженеров со временем возникает закономерный вопрос: как автоматизировать рутину? Здесь начинается путь горизонтального развития — из ручного тестировщика в автоматизаторы. Например, на Python, Java, JavaScript, C# и других языках программирования.
Что важно уметь автотестеру:
писать автотесты (Selenium, Playwright, PyTest, JUnit и др.);
пользоваться CI/CD-инструментами (например, Jenkins, GitLab CI);
работать с API и Postman.
Алена Арапи, старшая наставница на курсах по тестированию:
«Между ручным тестированием и автоматизацией обычно есть мост в виде написания тест-кейсов под API и ручных API-проверок, создания mind-map, чек-листов, обкатки процессов в команде. Или, например, pet-проекта, где можно потренировать Jenkins, Git и автотесты без риска. Это практичные шаги, которые подходят тем, у кого пока мало опыта».
Выход в смежные роли
Разработка
Часть разработчиков в IT пришли в профессию именно из ручного тестирования. Если вам нравится кодить, разбираться в архитектуре и строить логические цепочки, можно со временем перейти в разработку. Начать стоит с понимания, как пишется код в продакшн, разобраться в архитектуре приложений, командной разработке и code review.
Хорошие автоматизаторы часто пишут сложные фреймворки, работают с тест-контейнерами, моками и хранят кучу логики в тестовом коде. Это неплохая база, чтобы двигаться дальше.
Продукт
Это довольно редкая траектория, но возможная. Если вам интересно изучать боли пользователей и улучшать продукт, а не просто ловить баги, есть вариант расти в продакт-менеджера. Опыт QA помогает видеть, где слабые места в UX и фичах, анализировать данные из метрик или логов и думать над улучшениями.
Для такого перехода понадобятся бизнес-мышление, работу с пользовательским фидбеком и исследованиями, навыки аналитики, понимание рынка и конкурентов, умение писать продуктовые требования и формулировать задачи для команды.
Аналитика
Переход из QA в аналитики — частый карьерный сценарий и хорошая база. Тестировщики регулярно читают ТЗ и сами формируют тест-кейсы, то есть переводят бизнес-задачи в техническую плоскость. А это важный навык для аналитика. QA замечает мелкие несостыковки и логические ошибки и коммуницирует с продуктом и разработкой. В аналитике тоже нужно уметь слышать бизнес и понимать, как реализовать это в продукте.
Для работы аналитиком важно подтянуть знание SQL, BI-инструментов, визуализации процессов. А еще навыки интервьюирования пользователей и заказчиков, написания технической документации.
DevOps
Это менее очевидный, но тоже возможный путь. Многие тестировщики уже взаимодействуют с пайплайнами и знают, как работает продукт в разных окружениях. Навык поиска и анализа ошибок в DevOps тоже важен. Например, при отладке сборок, логировании, мониторинге и аварийном восстановлении.
Тестировщику придется больше погрузиться в основы Linux и командной строки системы контейнеризации, мониторинг, логирование, работу с облаками, безопасность и доступы.
Менеджмент
Это не столько про смену специальности, сколько про расширение зоны ответственности. Работа больше про людей: процессы, найм, оценки, поддержка команды. Тестировщик может стать тимлидом, ведь он часто взаимодействует со всеми участниками разработки, а это важное для лидера знание. Кроме того, QA видит продукт глазами пользователя — это помогает принимать верные управленческие решения.
Если хотите развиваться в этом направлении, прокачивайте лидерские качества, процессное мышление, навыки фасилитации, менторинг, управление метриками и целями команды.
Как выбрать свой путь
Задайте себе несколько вопросов:
Что мне нравится больше: код или люди?
Нравится ли мне разбираться в устройстве продукта?
Комфортно ли мне брать ответственность?
Я хочу вести команду или управлять процессом?
На основе ответов вы можете прикинуть, в какую сторону двигаться и какие навыки прокачивать.
Где учиться и прокачиваться
Профессиональное обучение поможет получить не только комплексные знания и навыки, но и их подтверждение. У Практикума вы найдете курсы для опытных, чтобы расти и осваивать новые навыки в тестировании и других IT-направлениях — и сможете бесплатно попробовать вводную часть.
А если решите продолжить, вас ждет много практики, проверка работ ревьюерами, поддержка наставников и студенческого сообщества, помощь с трудоустройством.
Недавно мой коллега сдавал ISTQB Game Testing — и, мягко говоря, остался в шоке. Не столько от результата (хотя и его тоже), сколько от того, насколько сам экзамен отличался от пробников.
🌀 Вместо привычных вопросов «по цитатке из силабуса» — сложные кейсы, меньше селектов, больше текста и задач на подумать. Времени катастрофически не хватало. А ещё — капкан для тех, кто сдаёт на Английском но не имеет С1 уровень: Вы, например, знаете, как по-английски ржёт лошадь?.. 🐴
Коллега не сдал, и был очень не согласен. Но — и это важно — он не стал молчать. Он написал подробное письмо провайдеру экзамена (в его случае — GASQ), описал:
что именно было не так;
какие вопросы вызывают сомнения;
как это не совпадает с официальным Syllabus;
какие неточности нашёл в пробных тестах.
💸 Апелляция у GASQ вообще-то платная — 80 евро. Но после его письма и обсуждения ему предложили пересдать экзамен бесплатно, без оплаты и без подачи официальной апелляции.
И он пересдал. Успешно.
И вот тут меня это реально зацепило. Я бы, скорее всего, просто затерпел. Потому что слышал байки, что апелляция через GASQ — это бюрократический ад. Но оказалось — если по делу, то вас услышат.
🎯 Вывод?
Не бойтесь отстаивать свою точку зрения.
Экзамены — не всегда идеальны. Мы тратим на них недели подготовки, силы, деньги. И если есть ощущение несправедливости — иногда достаточно просто спокойно и по делу объяснить, в чём проблема.
Ваш голос может быть услышан. А в некоторых случаях — даже бесплатно пересдан 🙂
Бывали ли у вас случаи, когда "за спрос не били в нос" — и это реально помогло?
Когда кажется, что автоматизация достигла потолка Появляется Playwright MCP и такой: "подержите моё пиво" 🍺
Playwright MCP — это штука, которая позволяет управлять браузером через текст в чате. Пишешь что-то вроде: "Открой сайт, найди товар, проверь цену" — и оно само всё делает. Кликает. Проверяет. Даже сохранит в автотест, если попросишь.
📌 Записал новое видео, в котором рассказал: – Что такое Playwright MCP и почему это не шутка – Как его поставить в VS Code или Cursor – Как запускать простые тесты одной текстовой командой – Как на базе существующей автоматизации генерировать новые автотесты – Как делать exploratory testing руками ИИ – и как НЕ передавать логины и пароли нейросетке случайно 🙃
📺 Смотреть обязательно, особенно если хотите понять, куда всё катится (и как на этом кататься с кайфом)
А вы уже пробовали подобные инструменты? Поделитесь опытом👇
QA тестирование, или тестирование обеспечения качества (Quality Assurance testing), - это процесс, направленный на обеспечение соответствия продукта или услуги установленным требованиям и стандартам. Включает в себя широкий спектр мероприятий, целью которых является предотвращение дефектов и обеспечение удовлетворенности клиентов. QA тестирование начинается с самых ранних этапов разработки и продолжается до выпуска продукта, охватывая все аспекты, влияющие на качество.
Кратко итоги Обучения Тестированию на видео: Как выглядел месяц учебы. Блок по Трудоустройству. Резюме учеников. Готовимся к собеседованиям. До скорого! :)
План: Старт бесплатного обучения от SQA Engineer 16.06.2025, конец обучения 28.07.2025
Перевыполнили)
первое что пришло на ум, нравятся советские плакаты и идеи касаемо труда
Сейчас в группе 100 человек, было 200, почистил неактивных, удалил зевак. Самых активных человек 30 наберется, скорей всего среди них и найдут работу ребята первыми.
Update: в конце августа 2025, будет набор на Автоматизацию тестирования
Когда-то Behavior-Driven Development задумывался как классная штука. Предполагалось, что с его помощью бизнес будет описывать, как должен работать продукт, тестировщики — добавлять корнер-кейсы («а что будет, если сделать шаг влево или вправо?»), а разработчики — писать код автотестов и делать продукты, которые эти тесты проходят.
Главный инструмент BDD — Cucumber — позволил автоматизировать тесты, описывая их на языке Gherkin и связывая эти описания с исполняемым кодом. В итоге должен был получаться результат, который устраивает и бизнес, и QA.
Но что-то пошло не так. Сегодня в адрес Cucumber все чаще можно услышать критику. Его создатель Аслак Хэллисей признал, что: «Большинство используют Cucumber не для BDD, а просто как инструмент тестирования. Если так, то он ничем не лучше других фреймворков».
Кто в этом виноват и что делать? Попробуем разобраться.
Что пошло не так
В идеальном Behavior-Driven Development-мире бизнес берет латте, садится рядом с тобой и вы долго и счастливо пишете сценарии вместе. В реальности же он тебя просто отшивает: «У нас нет времени разбираться в этих Given-When-Then. Главное, чтобы работало. А как — это ваши проблемы». В итоге вся фишка BDD — описание требований на общем языке — теряется.
Разработчики тоже не в восторге: Gherkin для них — это лишняя абстракция, которая только мешает. Каждый шаг в Gherkin требует реализации в коде. Вместо упрощения получается дополнительный слой — step definitions нужно писать, поддерживать и постоянно рефакторить. В итоге мы имеем 10 сценариев → 100 шагов → 500 строк кода, где 80% — это повторяющиеся вызовы.
Если команда тупо перекладывает готовые тест-кейсы в Gherkin, это лишняя работа, которая не имеет смысла.
Почему Cucumber не так хорош
Он тормозит. Высокоуровневые сценарии, особенно в UI-тестах, превращают CI/CD в ад. Каждый прогон ты сидишь и ждешь, когда же он доползет до конца.
Это темный лес. В реальных проектах сценарии не более информативны, чем код на незнакомом ЯП.
Это больно. Любое изменение в логике — и приходится переписывать шаги, а потом чинить тесты. А если у тебя несколько команд работают с одними и теми же сценариями — жди конфликтов.
Он хрупкий и жестко завязан на структуру. Нужно привыкать к нему и следить за реализацией «названий» шагов, чтобы правильно вызывать их в feature-файлах. Одно неосторожное движение — и все, тесты посыпались как карточный домик. Перефразировали текст в требованиях? Надо бегом править все фичи. Изменили селектор на фронте? Готовимся к падениям.
Он все усложняет. Он приносит еще один уровень абстракции, с которым нужно считаться при дебаге.
VLM все меняет
Можно ли сохранить удобство написания тест-кейсов в свободной форме, но при этом избавиться от жестких синтаксических правил? Похоже, что да. И ключом к этому решениюдолжны статьvision-language модели (VLM) — мультимодальные нейросети, которые могут одновременно обрабатывать изображения и текстовые описания. Они принимают на вход скриншот интерфейса и описание не в жестко структурированной нотации и подготовленных фразах, а в естественных формулировках, понимают контекст и определяют, какой именно элемент соответствует этой инструкции.
Недавно команда BugBuster внедрила этот подход, запустив ИИ-систему для управления тестированием.
Вот как это работает:
Описываешь действия за 5 минут. Просто пишешь тест-кейс на человеческом языке.
Запускаешь тест в один клик. Больше не нужно каждый день править селекторы из-за того, что фронтендер решил рефакторнуть верстку.
Получаешь результат через минуту. Пока ты идешь за кофе, система сама проверяет, что в корзину все добавилось, кнопки нажались, а формы отправились.
