Чтобы стать QA-инженером с нуля, сначала научитесь проектировать проверки и понятно описывать дефекты, затем добавьте DevTools, HTTP, API, SQL и базовую автоматизацию. Портфолио должно показывать ход мысли: чек-лист, тест-кейсы, баг-репорты, коллекцию API-запросов и небольшой набор автотестов.
Тестирование не сводится к нажатию кнопок. Инженер уточняет требования, оценивает риски, выбирает уровни и типы проверок, готовит данные, воспроизводит проблему и помогает команде принять решение о качестве. ISTQB Foundation Level 4.0 систематизирует фундаментальные понятия, жизненный цикл, статическое тестирование, техники тест-дизайна, управление тестированием и инструменты. Сертификат необязателен, но syllabus удобен как карта тем. Каждую тему закрепляйте наблюдаемым примером и собственным отчётом.
Формы, cookies, сеть, адаптивность и доступность.
Методы HTTP, статусы, JSON, авторизация и контракт.
Проверка данных и подготовка тестового состояния.
Как стать QA-инженером с нуля на одном сценарии
Возьмите публичную учебную форму регистрации и составьте проверки по классам эквивалентности и граничным значениям. Баг-репорт должен позволить другому человеку воспроизвести сбой без догадок. Не пишите «кнопка не работает». Укажите окружение, предусловия, шаги, фактический и ожидаемый результат, вложение и серьёзность.
Заголовок: форма принимает пароль из 7 символов
Окружение:
- Chrome, desktop viewport 1280x800
- тестовый стенд, build 142
Предусловие:
- пользователь вышел из аккаунта
Шаги:
1. открыть форму регистрации
2. ввести валидный email
3. ввести пароль Abc123!
4. нажать Create account
Фактический результат:
- аккаунт создан
Ожидаемый результат:
- показана ошибка «Minimum 8 characters»- Разработчик воспроизводит проблему по точным шагам
- Тест связан с конкретным правилом и границей
Добавьте соседние значения 6, 7, 8 и 9 символов, пустое поле, пробелы и слишком длинный ввод. Затем откройте Network в DevTools и сравните запрос, статус и ответ. Для API повторите сценарий в Postman или curl. SQL используйте для чтения тестовых данных, не изменяя чужую среду без разрешения. Автоматизируйте стабильный повторяемый сценарий после того, как разберётесь в ручной проверке.
Портфолио начинающего QA
| Элемент | Что означает | Что делать |
|---|---|---|
| Чек-лист | 20-30 проверок одной функции | Риски и приоритет |
| Баг-репорты | 3-5 воспроизводимых дефектов | Expected и actual |
| API | Коллекция запросов | Позитивные и негативные ответы |
| SQL | Набор SELECT-запросов | Join, фильтрация, агрегация |
| Автотест | Небольшой smoke-набор | README и одна команда запуска |
Не придумывайте баги реального продукта и не отправляйте отчёты компании без согласования. Используйте учебный стенд, open-source проект или собственное приложение. В README опишите цель, область, окружение и ограничения. Скриншот подтверждает внешний вид, но сетевую ошибку лучше подкрепить запросом и ответом. Для динамических данных указывайте время и тестовый аккаунт без секретов.
Практика: проверьте границу пароля и напишите воспроизводимый баг-репорт
Возьмите публичную учебную форму регистрации и проверьте одно правило: пароль не короче 8 символов. Успехом считайте чек-лист по значениям вокруг границы, один баг-репорт по шаблону из статьи и запрос из вкладки Network, подтверждающий ответ сервера. Работайте на учебном стенде, open-source проекте или своём приложении.
- Требование и границы. Выпишите правило про минимум 8 символов и составьте набор значений: 6, 7, 8, 9 символов, пустое поле, строка из пробелов и слишком длинный ввод. Получится чек-лист, где в каждой строке записано ожидаемое поведение, а не расплывчатое «проверить пароль».
- Прогон в браузере. Введите валидный email и пароль Abc123! из 7 символов, нажмите Create account. Зафиксируйте фактический результат: аккаунт создан вместо ошибки Minimum 8 characters.
- Запрос во вкладке Network. Откройте DevTools, вкладку Network, повторите отправку и посмотрите на запрос регистрации: метод, тело и статус ответа. Скриншот формы показывает внешний вид, а успешный статус на коротком пароле показывает суть дефекта.
- Баг-репорт по шаблону. Оформите отчёт с заголовком, окружением (Chrome, viewport 1280x800, стенд build 142), предусловием, четырьмя шагами, фактическим и ожидаемым результатом. Критерий: другой человек воспроизводит дефект по вашему тексту, ничего не уточняя.
- Повтор через API. Отправьте тот же пароль из 7 символов напрямую в endpoint регистрации через Postman или curl. Если API тоже отвечает успехом, значит проверки нет на сервере, и дефект глубже формы, о чём стоит написать в отчёте.
Сломайте собственный баг-репорт: уберите из него шаги и окружение, оставьте один заголовок про короткий пароль. Отдайте текст другому человеку и попросите воспроизвести. Он не поймёт, какой пароль вводить, в каком браузере и на каком стенде, и вернёт отчёт с вопросами. Верните шаги, окружение, фактический и ожидаемый результат и убедитесь, что вопросов больше нет.
Повторите то же самое для поля email и для разных ролей, чтобы в портфолио набралось 20-30 проверок одной функции и 3-5 дефектов. Добавьте коллекцию API-запросов с позитивными и негативными ответами и несколько SELECT, подтверждающих, что аккаунт с коротким паролем в базе не появился. Автотест пишите последним и только на стабильный повторяемый сценарий, с README и одной командой запуска.
Частые ошибки и почему они появляются
Новичок часто начинает с Selenium, не умея выбрать полезный сценарий. Вторая ошибка связана с огромными тест-кейсами на каждую кнопку без оценки риска. Третья появляется в резюме, где перечислены инструменты, но нет примера исследования. Сильнее выглядит один небольшой проект с ясной логикой и честными ограничениями.
Серьёзность описывает влияние дефекта, приоритет зависит от бизнес-контекста.
Добавляйте границы, ошибки, роли, сеть и состояние данных.
Выбирайте стабильные повторяемые проверки с понятной ценностью.
Самопроверка
С чего начать путь в QA с нуля?
Начинают не с Selenium, а с требований, рисков и техник тест-дизайна. Сначала научитесь проектировать проверки по классам эквивалентности и границам и описывать дефект так, чтобы его воспроизвели без вас, потом добавляйте DevTools, HTTP, API, SQL и базовую автоматизацию.
Что должно быть в баг-репорте, чтобы его приняли?
В баг-репорте нужны заголовок, окружение, предусловия, пронумерованные шаги, фактический и ожидаемый результат, вложение и серьёзность. Фраза «кнопка не работает» отчётом не считается: по ней разработчик не воспроизведёт сбой и вернёт задачу с вопросами.
Что писать в severity и priority в баг-репорте?
Severity описывает влияние дефекта на работу системы, а priority показывает, насколько срочно его чинить с точки зрения бизнеса. Поэтому мелкая на вид опечатка может иметь низкую серьёзность и высокий приоритет, а редкий сбой в экзотическом сценарии наоборот.
Нужен ли сертификат ISTQB начинающему тестировщику?
Сертификат ISTQB необязателен, но syllabus Foundation Level 4.0 удобен как карта тем: фундаментальные понятия, жизненный цикл, статическое тестирование, техники тест-дизайна, управление тестированием и инструменты. Каждую тему полезнее закрыть своим примером и отчётом, чем выучить определение.
Когда начинающему QA браться за автоматизацию?
За автоматизацию берутся после того, как ручной сценарий понятен и стабилен. Автотест на плавающую или редко нужную проверку приносит только поддержку, поэтому в портфолио достаточно небольшого smoke-набора с README и одной командой запуска.
Что положить в портфолио начинающего QA?
В портфолио кладут чек-лист на 20-30 проверок одной функции, 3-5 воспроизводимых баг-репортов, коллекцию API-запросов с позитивными и негативными ответами, набор SELECT-запросов и небольшой smoke-набор автотестов. Материал берите с учебного стенда, open-source проекта или своего приложения, а чужой продакшен не трогайте.
Что делать дальше
Проверьте одну форму, оформите чек-лист и два баг-репорта, затем повторите ключевой сценарий через API. Автоматизацию проверок и путь дальше разбирает профессия QA-инженер / Тестировщик. Для подготовки откройте вопросы QA и оцените срок по статье про путь до junior.