Junior QA нужно не «всё подряд из дорожной карты на 40 пунктов», а четыре блока в строгом приоритете. Первый и незаменимый — теория тестирования и тест-дизайн: виды тестирования, техники придумывания проверок, умение писать тест-кейсы и баг-репорты. Это спрашивают на каждом собесе, и без этого остальное — мёртвый груз. Второй — рабочие инструменты: баг-трекер, Postman для API, базовый SQL, DevTools браузера. Третий — soft skills, на которых валится половина новичков. Четвёртый — автоматизация, которая для manual-старта вообще не обязательна.
Запомните этот порядок, потому что именно в нём ошибаются чаще всего. Кто начинает с установки Selenium и Python — теряет полгода на то, что на junior-собесе даже не спросят. Кто начинает с тест-дизайна — собирает портфолио за три-шесть месяцев. Дальше — карта навыков с приоритетами: что в первую очередь, что следом, что можно отложить без вины. Чтобы вы учили нужное в нужном порядке, а не хватались за всё сразу и не умели ничего.
Игорь, 31 год, логист. Скачал из интернета «дорожную карту QA» на 47 пунктов и начал по-честному, сверху вниз. Первым в списке почему-то стояла автоматизация — он поставил Python, поставил Selenium, упёрся в непонятный код на втором уроке. Бросил, перешёл к SQL. Выучил пять запросов, забыл, зачем они. Взялся за HTTP, прочитал статью про статус-коды, закрыл. Через два месяца Игорь знал по верхам про всё и не умел ничего.
А потом его позвали на собеседование, и первый же вопрос был: «Составьте тест-кейсы на поле ввода пароля». Игорь завис.
Этого пункта в его карте ещё не было. Он стоял где-то в середине, между Selenium и SQL, до которых Игорь так и не дошёл.
Вот блок, с которого нужно начинать, а не которым нужно заканчивать. Теория тестирования — это фундамент, и без него три остальных блока бесполезны, потому что нельзя проверять то, для чего ты не умеешь придумать сценарий.
Что сюда входит. Виды тестирования — чтобы говорить с командой на одном языке: функциональное и нефункциональное, позитивное и негативное, smoke и регрессионное. Техники тест-дизайна — это способы придумывать проверки не наугад, а системно. Классы эквивалентности: если поле принимает возраст от 18 до 65, не нужно проверять каждое число — достаточно одного из середины, потому что они равноценны. Граничные значения: а вот границы — 17, 18, 65, 66 — проверять обязательно, потому что именно на них ломается чаще всего. Попарное тестирование, чтобы не перебирать миллион комбинаций вручную. И главное умение, ради которого всё остальное, — раскладывать любую функцию на тест-кейсы и описывать найденную поломку баг-репортом так, чтобы разработчик её воспроизвёл.
Почему это первое, а не пятое. Потому что это спрашивают на каждом собеседовании junior — не «знаете ли вы Selenium», а «вот форма, дайте сценарии проверки». Поле ввода пароля, которое завалило Игоря, раскладывается на два десятка кейсов: пустое поле, один символ, максимальная длина, на символ больше максимума, пробел в начале, спецсимволы, кириллица, копипаст. Кто видит эти двадцать сценариев сразу — тот думает как тестировщик. Кто видит «ну, ввести пароль и проверить» — тот ещё нет, сколько бы инструментов ни установил.
Если из всей статьи вы выучите только один блок — учите этот.
Теперь то, чем эти проверки выполняются. И здесь хорошая новость для тех, кто утонул в списках на сорок строк.
Рабочих инструментов для junior — четыре. Не сорок.
Первый — баг-трекер. На практике почти всегда Jira. Это система, куда команда заводит задачи и баги: тестировщик описывает поломку в тикете, разработчик берёт его в работу, потом тикет проходит ретест и закрывается. Уметь нужно немного — завести баг по шаблону, выставить приоритет, прикрепить шаги воспроизведения. Это вопрос пары дней практики, а не недель.
Второй — Postman. Программа, которая шлёт запросы к серверу напрямую, минуя кнопки и формы. Зачем это тестировщику: половина багов живёт не в красивом интерфейсе, а в обмене данными под ним. Форма показала «успешно», а на сервер ушёл пустой запрос — пользователь думает, что заявка отправлена, а её нет. Через интерфейс это не поймаешь, через Postman — за минуту.
Третий — базовый SQL. Именно базовый: SELECT, WHERE, простой JOIN. Никто не ждёт от junior, что он напишет сложную выборку с подзапросами. Ждут, что он сможет залезть в базу и проверить — записалось ли то, что он ввёл в форму, и записалось ли правильно. Зарегистрировал пользователя — а в базе его телефон сохранился без первой цифры. Один запрос, и баг пойман.
Четвёртый — DevTools, встроенные инструменты разработчика в браузере. Открываются по F12. В них видно, какие запросы уходят на сервер, что отвечает сервер, какие ошибки красным горят в консоли. Это бесплатно, стоит на каждом компьютере и показывает изнанку любого сайта.
Глубина для junior по всем четырём — поверхностная и этого достаточно. Не «знать SQL», а достать данные простым запросом. Не «мастер Postman», а отправить запрос и прочитать ответ. Эти четыре инструмента закрывают процентов девяносто junior-задач. Остальное добирается уже на работе, под конкретный проект, и заранее это учить — снова распыляться.
Между теорией и инструментами есть прослойка, которую новички пропускают, а зря. Понимание, как вообще устроено то, что они тестируют.
Картинка простая. Есть клиент — браузер или приложение на вашем устройстве. Есть сервер — компьютер где-то далеко, где живёт логика и данные. Когда вы нажимаете «Отправить», клиент шлёт серверу запрос, сервер думает и возвращает ответ. У ответа есть код состояния: 200 — всё хорошо, 404 — страница не найдена, 500 — сервер упал. Данные при этом хранятся в базе, до которой вы достучитесь тем самым SQL из предыдущего блока.
Зачем junior это знать на уровне теории, а не практики веб-разработки. Затем, что тестировщик, который не понимает, где произошла поломка — на стороне клиента, на стороне сервера или в базе, — не сможет внятно завести баг. Он напишет «кнопка не работает», а разработчик спросит: запрос вообще ушёл? какой код вернулся? — и junior поплывёт. На собеседовании это вскрывается за минуту: «что происходит, когда вы нажимаете кнопку входа?». Кто отвечает «клиент отправляет запрос на сервер, сервер проверяет пароль и возвращает ответ» — прошёл. Кто отвечает «ну, появляется страница» — нет.
Связка с инструментами тут прямая. DevTools показывает вам запрос и код ответа. Postman этот запрос отправляет руками. Понимание HTTP объясняет, что вы в них видите. Три вещи работают вместе, и поэтому учить их стоит рядом.
А вот блок, который в дорожных картах либо стоит последним мелким шрифтом, либо отсутствует. И именно на нём валится половина новичков — не на теории, на нём.
Въедливость. Не та «я внимательная, я нахожу опечатки», которую пишут в резюме поголовно и которая не значит ничего. Системная: способность держать в голове, что одну форму надо проверить по тридцати сценариям, и проверить все тридцать, а не первые три и «дальше понятно». Это образ мышления, а не строчка из гороскопа.
Коммуникация. Половина работы тестировщика — не найти баг, а доказать, что это баг. Разработчик в девяти случаях из десяти ответит «так задумано» или «у меня всё работает». И тут junior либо отступает — «ну, наверное, и правда задумано», и баг едет к пользователю, — либо спокойно показывает: вот требование, вот поведение, они не совпадают. Без скандала, с фактами. Кто не умеет отстоять найденное, тот бесполезен, даже если находит всё.
Терпимость к монотонности. Тридцать сценариев на одну форму — это нудно. Регрессионное тестирование, где после каждой новой функции перепроверяешь, что не отвалилось старое, — ещё нуднее. Кого это бесит, тот уйдёт через полгода, как бы хорошо ни знал теорию.
Умение задавать вопросы. Требования всегда дырявые. Хороший junior не додумывает, как должна работать функция, а идёт к аналитику и спрашивает. Плохой — придумывает сам и тестирует свою фантазию вместо продукта.
Почему это отдельный полноценный блок, а не сноска. На собеседовании теорию проверяют за двадцать минут — пара вопросов про тест-дизайн, и понятно, учил человек или нет. А весь остальной разговор — это проверка склада ума. Как реагирует на «а вы уверены, что это баг?». Сдаётся или аргументирует. Эти двадцать минут против целого часа — вот реальный вес soft skills. Их нельзя выучить за выходные, но можно тренировать с первого дня: спорить по делу, доводить нудное до конца, не бояться переспросить.
И вот тут — главное, ради чего стоило выстраивать приоритеты. Автоматизация. Тот самый Selenium с Python, на которые Игорь убил первый месяц.
Для manual-старта она не нужна. Точка.
Автоматизация — это Python или Java плюс Selenium плюс фреймворк автотестов плюс система сборки. Это отдельные девять-восемнадцать месяцев, если язык с нуля. И это надстройка над ручным тестированием, а не его замена: автотест — это код, который прогоняет проверку, придуманную человеком. Сначала надо уметь придумать проверку руками — то есть владеть всем первым блоком, — и только потом автоматизировать. Нельзя автоматизировать то, что не умеешь делать вручную. Робот будет быстро и тысячу раз выполнять бессмысленное.
Есть честный нюанс, и он спасёт вас на собеседовании. Знать, ЧТО такое автоматизация и зачем она — нужно. «Чем manual отличается от automation» спрашивают почти всегда, и плавать тут нельзя. Но знать на словах и уметь писать автотесты — разные вещи. Junior manual обязан понимать идею. Писать код автотестов он не обязан.
Исключение одно: если вы уже умеете программировать — учились на разработчика, писали на Python в прошлой жизни, — тогда manual-этап для вас короткий, и можно целиться выше сразу. Но это тема отдельного разговора, и большинства входящих в QA она не касается.
Вывод холодный и простой. Хватаешься за Selenium до тест-дизайна — учишь то, что на junior-собесе не спросят, вместо того, что спросят первым. Игорь так и сделал, и потерял два месяца. Автоматизация — четвёртый этаж. Нельзя строить его на пустом фундаменте.
Соберём четыре блока в один маршрут. Не по срокам — по приоритету, потому что распыляются именно на порядке.
Сначала — теория тестирования. Виды, техники тест-дизайна, тест-кейсы, баг-репорты. Пока не научились раскладывать форму на сценарии — не трогайте остальное.
Следом, можно параллельно, — инструменты и понимание системы. Баг-трекер, Postman, базовый SQL, DevTools, основы HTTP и клиент-сервера. Поверхностно, без фанатизма: уметь пользоваться, а не сдавать экзамен.
С первого дня и всё время — soft skills. Их не проходят отдельным уроком. Их тренируют: доводить нудное до конца, аргументировать, переспрашивать.
В последнюю очередь и по желанию — автоматизация. Если есть силы и интерес, после того как первые три блока твёрдые. Не раньше.
Маркер, что вы junior-ready по технике: даёте простую форму — вы за десять минут пишете на неё внятные тест-кейсы и оформляете баг-репорт по шаблону. Можете — значит, фундамент есть, дальше дело за инструментами и практикой. Не можете — никакой Selenium это не закроет.
И вот здесь стоит сделать шаг, который Игорь не сделал в начале. Прежде чем качать очередную карту на 47 пунктов, проверьте, ваша ли это профессия по складу ума, и какая программа закроет именно нужные навыки в нужном порядке. Профтест на нашем портале занимает пятнадцать минут: отвечаете на вопросы — получаете не абстрактный список, а подобранную под вас траекторию, где теория идёт перед автоматизацией, а не наоборот. Пятнадцать минут против двух месяцев, потраченных не на то.
Игорь, к слову, в итоге переставил список. Вычеркнул Selenium из начала, дописал в конец. Поднял наверх тест-дизайн. За следующий месяц он научился составлять тест-кейсы, разобрался с Postman и SQL по верхам, сходил на собес и ответил на «составьте кейсы на поле пароля» двумя десятками сценариев. Он не выучил больше. Он выучил в правильном порядке. Разница между его провалом и его оффером — не объём знаний. Это порядок.
