Когда человек впервые заходит в тестирование, у него обычно в голове не профессия, а туман.
Открываешь вакансии - и там начинается:
SQL, Postman, DevTools, Jira, Git, API, JSON, Swagger, автотесты, Selenium, Playwright, Scrum, тест-дизайн…
И ты сидишь такой:
“Я вообще на junior иду или сразу в NASA?”
Особенно тяжело в начале. Кажется, что нужно знать всё. Сразу. Желательно вчера. Иначе даже на собеседование не позовут.
Но правда в другом.
Junior тестировщику не нужно знать всё.
Ему нужно понимать базу, уметь думать как тестировщик и не бояться разбираться.
Главная ошибка новичка — начинать с инструментов
Многие начинают так:
“Сейчас выучу Postman, потом SQL, потом Git, потом Selenium, потом Python…”
И через пару недель мозг превращается в кашу.
Потому что инструменты без понимания тестирования - это просто кнопки.
Можно открыть DevTools, но не понимать, зачем смотреть Network.
Можно отправить запрос в Postman, но не понимать, что именно проверять.
Можно найти баг, но описать его так, что разработчик закроет задачу со словами: “Не воспроизводится”.
Поэтому начинать нужно не с вопроса “какие программы поставить”, а с вопроса:
Что я как тестировщик вообще должен делать?
Ответ простой: помогать команде находить проблемы до того, как их найдёт пользователь.
Не просто кликать.
Не просто “ломать приложение”.
А проверять продукт осознанно: что должно работать, что может сломаться, где риск, где пользователь пострадает.
Теория, без которой junior будет плавать
Теория нужна. Но не вся подряд.
Новичку не нужно с первого дня знать все термины наизусть. Но базу понимать надо.
На старте важно разобраться:
- что такое тестирование;
- чем QA отличается от QC;
- что такое баг, дефект и ошибка;
- какие бывают виды тестирования;
- какие бывают уровни тестирования;
- что такое регресс, smoke и sanity;
- что такое тест-кейс и чек-лист;
- что такое тест-дизайн;
- что такое severity и priority;
- как выглядит жизненный цикл бага.
Без этой базы junior быстро начинает плавать на собеседовании и в работе.
И дело не в том, чтобы заучить определения как школьник. Важно понимать смысл.
Тестировщик не “доказывает, что всё работает”.
Он помогает команде понять, где продукт может повести себя неправильно.
Тест-дизайн: тут начинается работа головой
Junior, который просто прокликивает страницы, слабый.
Junior, который умеет придумывать проверки, уже выглядит гораздо интереснее.
На старте стоит знать хотя бы базовые техники:
- классы эквивалентности;
- граничные значения;
- таблицы принятия решений;
- попарное тестирование;
- негативные проверки;
- позитивные проверки.
Это не нужно учить ради красивых слов.
Тест-дизайн помогает не проверять всё подряд хаотично, а выбирать проверки осознанно.
Плохой подход:
“Я просто покликаю и посмотрю.”
Хороший подход:
“Я понимаю, какие зоны риска есть в этой функциональности и что нужно проверить в первую очередь.”
Вот это уже похоже на работу тестировщика.
Документация: важно писать понятно
Тестировщик много пишет.
Не посты в соцсети, а рабочую документацию:
- чек-листы;
- тест-кейсы;
- баг-репорты;
- комментарии в задачах;
- результаты проверок;
- вопросы к аналитикам и разработчикам.
И тут многие новички проваливаются.
Можно найти хороший баг, но описать его так плохо, что команда потратит лишнее время на уточнения.
Хороший баг-репорт должен отвечать на главный вопрос:
Как разработчику быстро повторить проблему и понять, что именно сломано?
Для этого в баге должны быть:
- понятный заголовок;
- шаги воспроизведения;
- фактический результат;
- ожидаемый результат;
- окружение;
- скриншот или видео;
- серьёзность и приоритет.
Умение писать понятно - это не дополнительный бонус. Это часть профессии.
Инструменты, которые реально нужны junior
Не нужно ставить всё подряд. На старте достаточно базового набора.
1. Баг-трекер
Это может быть Jira, YouTrack, Яндекс Трекер, Azure или другой аналог.
Junior должен понимать:
- что такое задача;
- что такое баг;
- что такое статус;
- что такое приоритет;
- как оставить комментарий;
- как приложить скриншот;
- как проверить исправление;
- как переоткрыть задачу, если баг не исправлен.
Важно не название конкретного инструмента, а понимание рабочего процесса.
Задача пришла в тестирование - ты проверил.
Нашёл баг - завёл.
Баг исправили - проверил фикс.
Фикс нормальный - закрыл.
Не нормальный - вернул на доработку.
2. DevTools
Если тестируешь веб - DevTools обязателен.
На старте не нужно знать все вкладки. Достаточно уверенно понимать:
- Elements;
- Console;
- Network.
DevTools помогает смотреть глубже, чем просто “нажал кнопку - ничего не произошло”.
Через него можно увидеть ошибки на странице, сетевые запросы, ответы сервера, статусы и проблемы с загрузкой.
Это один из тех инструментов, который быстро поднимает уровень junior.
3. Postman
Postman нужен для API-тестирования.
Junior должен понимать:
- что такое API;
- чем отличаются GET, POST, PUT, PATCH и DELETE;
- что такое headers;
- что такое body;
- что такое параметры запроса;
- что такое авторизация;
- как читать status code;
- как отправить запрос и посмотреть ответ.
На старте не нужно быть API-гуру.
Но если junior умеет открыть документацию, взять endpoint, отправить запрос и понять ответ - это уже большой плюс.
4. Swagger / OpenAPI
Swagger для тестировщика - это карта API.
Там обычно видно:
- какие есть методы;
- какие параметры нужны;
- какие данные нужно отправить;
- какие ответы ожидаются;
- какие ошибки возможны.
Новичку важно не бояться Swagger.
Это не “что-то для разработчиков”. Это нормальный рабочий инструмент тестировщика, особенно если в команде есть API.
5. SQL
Junior не обязан писать сложные запросы.
Но базовый SQL очень помогает.
На старте достаточно понимать:
- SELECT;
- WHERE;
- ORDER BY;
- LIMIT;
- простые JOIN;
- фильтрацию;
- сортировку;
- базовые условия.
SQL помогает не гадать, а проверять данные глубже.
Интерфейс может показать одно, API может вернуть другое, а в базе может лежать третье. И тестировщику полезно уметь это проверить.
6. Git
Manual junior не всегда работает с Git каждый день, но базу знать полезно.
Минимум:
- репозиторий;
- ветка;
- commit;
- merge;
- pull request;
- develop;
- release.
Это нужно, чтобы понимать командные разговоры:
“Фикс в ветке.”
“Ждём merge.”
“На стенде старая сборка.”
“Проверь после деплоя.”
Когда ты это понимаешь, ты уже не выпадаешь из рабочего процесса.
Клиент-серверная архитектура
Это обязательно.
Junior должен понимать, что приложение - это не магия.
Есть клиент.
Есть сервер.
Есть база данных.
Есть запросы и ответы.
Если что-то сломалось, тестировщик должен примерно понимать, где искать проблему:
- на фронте;
- на бэке;
- в базе;
- в правах;
- в интеграции;
- в окружении;
- в данных.
Junior не обязан чинить проблему. Но он должен уметь собрать нормальную информацию и передать её дальше.
HTTP, JSON и статусы
Без этого сейчас тяжело.
Даже manual QA всё чаще работает не только с интерфейсом, но и с API, логами, запросами и ответами.
На старте нужно понимать:
- что такое HTTP;
- что такое запрос и ответ;
- что такое JSON;
- как устроены ключи и значения;
- что означают основные HTTP-статусы;
- чем ошибка 400 отличается от 500;
- почему 401 и 403 - не одно и то же.
Это база, которая пригодится почти в любой веб-команде.
Agile, Scrum и Kanban
Junior не обязан быть Scrum Master.
Но нужно понимать, как живёт команда:
- что такое backlog;
- что такое sprint;
- что такое daily;
- что такое planning;
- что такое review;
- что такое retrospective;
- чем Kanban отличается от Scrum;
- как задача проходит путь от идеи до релиза.
Это нужно не для красивых слов на собеседовании.
Это нужно, чтобы понимать, почему задача меняет статусы, зачем команда собирается на созвоны и почему иногда тестирование начинается не тогда, когда тебе удобно, а когда сборка наконец-то доехала до стенда.
Автотесты: сразу или потом?
Моё мнение: junior manual не обязан начинать с автотестов.
Сначала лучше выстроить базу:
- Теория тестирования.
- Тест-дизайн.
- Баг-репорты.
- DevTools.
- API и Postman.
- SQL.
- Git.
- Потом уже автотесты.
Почему так?
Потому что автотесты без понимания тестирования превращаются в автоматизированный кликер.
Можно написать скрипт, который нажимает кнопку. Но если ты не понимаешь, что проверяешь и зачем, это не тестирование.
Названия Selenium, Playwright и Cypress знать полезно.
Но бежать туда с первого дня необязательно.
Что показать в портфолио
Если опыта нет, нужно показать практику.
Не “я прошёл курс”, а “я умею делать руками”.
Минимальный набор для портфолио:
- чек-лист;
- несколько тест-кейсов;
- несколько баг-репортов;
- Postman-коллекция;
- простые SQL-запросы;
- README с описанием работы.
Портфолио не должно быть огромным.
Оно должно показать, что ты понимаешь процесс, умеешь оформлять результат и можешь объяснить, что именно проверял.
Что пока можно отложить
На старте не нужно глубоко лезть в:
- сложную автоматизацию;
- Docker;
- Kubernetes;
- CI/CD;
- нагрузочное тестирование;
- безопасность;
- сложные SQL-запросы;
- микросервисы;
- написание фреймворков.
Это всё может пригодиться позже.
Но если пытаться выучить это до первой работы, можно просто перегореть.
Junior выигрывает не тем, что знает всё.
Junior выигрывает тем, что у него крепкая база и нормальная голова.
Что спрашивают на собеседовании junior QA
Обычно могут спросить:
- что такое тестирование;
- чем QA отличается от QC;
- что такое severity и priority;
- чем smoke отличается от sanity;
- что такое regression;
- что такое тест-кейс и чек-лист;
- какие техники тест-дизайна знаешь;
- как протестировать форму логина;
- что такое API;
- чем GET отличается от POST;
- что значит статус 404;
- что значит статус 500;
- как посмотреть ошибку в браузере;
- что такое SQL JOIN;
- как оформить баг-репорт.
И тут сразу видно, кто реально практиковался, а кто просто смотрел курс на фоне.
Главный навык junior - мышление
Инструменты меняются.
Сегодня Jira, завтра YouTrack.
Сегодня Postman, завтра Insomnia.
Сегодня Selenium, завтра Playwright.
Но мышление тестировщика остаётся.
Хороший junior постоянно задаёт вопросы:
- что может пойти не так;
- где пользователь может ошибиться;
- где система может сломаться;
- какие данные могут быть некорректными;
- что будет при отсутствии доступа;
- что будет при ошибке сервера;
- что изменилось после фикса;
- что могло сломаться рядом.
Вот это и есть начало профессии.
Не “я знаю 15 инструментов”.
А “я понимаю, где система может сломаться”.
Итог
Junior тестировщику на старте нужны не сто инструментов, а понятная база.
Из теории:
- виды тестирования;
- тест-дизайн;
- чек-листы;
- тест-кейсы;
- баг-репорты;
- жизненный цикл бага;
- основы Agile.
Из инструментов:
- баг-трекер;
- DevTools;
- Postman;
- Swagger;
- SQL;
- Git.
Из технической базы:
- клиент-серверная архитектура;
- HTTP;
- JSON;
- status codes;
- базы данных;
- браузеры и окружения.
И главное — не пытаться стать senior за месяц.
Junior — это не человек, который знает всё.
Junior — это человек, который понимает базу, умеет задавать вопросы, аккуратно проверяет продукт и не боится разбираться.
В тестировании побеждает не тот, кто скачал больше инструментов.
Побеждает тот, кто умеет видеть риски, понятно описывать проблемы и каждый день становиться чуть сильнее.
Начинай с базы.
Делай маленькие практические шаги.
Собирай портфолио.
Учись объяснять свои проверки.
И тогда тестирование перестанет быть набором страшных слов из вакансий.
Оно станет профессией, в которую можно войти спокойно и по-человечески.