Тестировщик — кто это и как стать с нуля

Тестировщик – это специалист, который проверяет продукт и помогает команде находить ошибки до релиза. Если коротко, тестировщик снижает риски для пользователей, бизнеса и команды разработки.
Тестировщик работает в продуктовой команде. Он проверяет сайты, приложения, сервисы, интерфейсы, API и данные. Его цель — не «сломать продукт», а найти проблемы, описать их понятно и помочь команде принять решение.

Чем занимается тестировщик ежедневно

В ИТ часто используют термин QA (Quality Assurance), который означает обеспечение качества. Рядом есть термин QC (Quality Control) — контроль качества. На практике тестировщик часто занимается и проверками, и документированием, и анализом требований. В небольших командах границы ролей могут смешиваться.

Тестировщик отличается от разработчика. Разработчик пишет код. Тестировщик проверяет, как продукт работает для пользователя и бизнеса.

Он отличается и от аналитика. Аналитик описывает требования. Тестировщик проверяет, можно ли по этим требованиям создать понятные проверки.

Работа тестировщиком строится вокруг продукта и требований. День может выглядеть спокойно, но задачи требуют внимания.

Обычно процесс такой:

1. Тестировщик получает задачу и уточняет спорные места. 

2. Он проектирует проверки. 

3. Затем запускает тесты. 

4. Если находит дефект, оформляет баг-репорт. 

5. Разработчик исправляет проблему. 

6. Тестировщик делает новую проверку. 

7. Перед релизом команда проводит регрессию.

Требования описывают как должна работать функция. Например: «Пользователь может восстановить пароль через имейл».

Хороший тестировщик сразу задаст вопросы: что делать, если имейл не найден? Сколько действует ссылка? Можно ли запросить письмо несколько раз? Что увидит пользователь при ошибке?

Например, поле пароля принимает от 8 до 64 символов. Значит, нужно проверить 7, 8, 64 и 65 символов. Так команда быстрее найдет ошибки на границах.

Еще тестировщик проверяет позитивные и негативные сценарии. Позитивный сценарий показывает, что функция работает при правильных данных. Негативный — что система корректно реагирует на ошибку.

Направления и специализации в тестировании

Проверка качества (QA) — широкая область. Тестировщик-новичок обычно начинает с ручного тестирования. Затем можно выбрать специализацию.

Ручной тестировщик проверяет продукт руками. Он кликает, вводит данные, анализирует поведение системы и сравнивает результат с ожиданием.

Автоматизированный тестировщик пишет автотесты. Для этого нужны Python, Java или JavaScript. Также нужны фреймворки (готовые программные основы, набор инструментов, библиотек и правил, используемых разработчиками для быстрого создания приложений): Selenium, Selenide, Playwright или Cypress. Автотесты помогают быстро проверять повторяющиеся сценарии.

API-тестирование проверяет обмен данными между системами. Часто используют Postman или Insomnia. Тестировщик отправляет запросы, смотрит статус ответа, JSON-структуру и ошибки.

Нагрузочное тестирование показывает, выдержит ли сервис рост пользователей. Для этого применяют JMeter или Grafana k6.

Навыки и инструменты

Обучение тестировщик должен строить от базы к инструментам. Не стоит начинать с автотестов, если нет понимания тест-кейсов, дефектов и требований.

Для старта нужны следующие жесткие навыки:

• основы жизненного цикла разработки и тестирования (SDLC и STLC); 

• уровни и типы тестирования; 

• тест-дизайн; 

• чек-листы и тест-кейсы; 

• баг-репортинг; 

• основы HTTP и REST; 

• знание JSON; 

• знание Postman или Insomnia; 

• браузерные инструменты разработчика (DevTools); 

• базовый SQL; 

• система управления проектами; 

• Git и GitHub или GitLab на базовом уровне.

Жизненный цикл разработки и жизненный цикл тестирования (SDLC и STLC) помогают понять, когда команда пишет требования, проектирует проверки, запускает тесты и закрывает дефекты.

Инструменты разработчика (DevTools) нужны для проверки ошибок в браузере. Через них смотрят консоль, сеть, статусы запросов, сессии и верстку. SQL помогает проверить данные в базе. На старте хватит ключевых операторов языка SQL: SELECT, WHERE, JOIN, ORDER BY и простых агрегатов.

Для автотестов понадобятся язык программирования, структура тестов, работа с моками (тестовый объект, дублер, имитирующий поведение реального компонента системы) и заглушками, понимание трех уровней пирамиды тестирования, различающихся по охвату и цели (unit, integration и e2e-проверки). Также пригодятся CI/CD (набор практик в разработке ПО, автоматизирующий этапы сборки, тестирования и развертывания) и логирование (процесс автоматической фиксации событий, происходящих в компьютерной системе, приложении или на сервере, с записью информации в специальный файл, лог-файл или базу данных).

Тестировщик много общается. Ему нужно задавать вопросы и не превращать проверку в спор. И поэтому ему нужны следующие гибкие навыки:

• внимательность; 

• логика; 

• критическое мышление; 

• спокойная коммуникация; 

• умение документировать; 

• привычка уточнять допущения; 

• аккуратность в формулировках.

Хороший баг-репорт не обвиняет разработчика, а показывает проблему, шаги и ожидаемый результат. Команда должна быстро понять, что сломалось и как это повторить.

Учебная дорожная карта с нуля на 10–12 недель

Как стать тестировщиком без опыта? Начните с базы и небольших проектов. Сроки зависят от времени на практику, уровня английского, технического опыта и качества обратной связи.

* CRUD — это базовый набор действий с данными в приложении:

• Create — создать запись → Например, пользователь добавил новый адрес доставки. 

• Read — прочитать или посмотреть запись → Пользователь открыл список своих адресов. 

• Update — изменить запись → Пользователь изменил номер квартиры. 

• Delete — удалить запись → Пользователь удалил старый адрес.

В тестировании CRUD часто проверяют через интерфейс или API. Например, тестировщик смотрит, можно ли создать товар, открыть его карточку, изменить цену и удалить товар из каталога.

Обучение тестировщиков с нуля должно включать практику. Конспекта мало. Нужно проверять реальные сайты, учебные API и простые приложения.

Пример мини-проекта: протестировать форму регистрации. Проверьте пустые поля, неверный имейл, короткий пароль, длинный пароль, повторную регистрацию, успешную регистрацию, текст ошибок и поведение кнопки.

Примеры артефактов тестировщика

Артефакты показывают ход работы. Они нужны и в команде, и в портфолио.

Разберем один из таких артефактов, тест-кейс — это пошаговая инструкция для проверки функции, страницы или сценария. Он описывает:

• что нужно проверить; 

• какие условия нужны перед проверкой; 

• какие шаги выполнить; 

• какой результат должен получиться.

Тест-кейс помогает проверить продукт одинаково и не забыть важные шаги.

Пример тест-кейса

Баг-репорт — это описание ошибки в продукте. Его пишут так, чтобы разработчик смог быстро понять проблему, повторить ее и исправить. Обычно баг-репорт включает:

• заголовок — что сломалось; 

• окружение — устройство, браузер, ОС, версия приложения; 

• шаги воспроизведения — что нужно сделать, чтобы увидеть ошибку; 

• фактический результат — что произошло; 

• ожидаемый результат — что должно было произойти; 

• приоритет и серьезность — насколько ошибка мешает пользователю и как быстро ее нужно исправить; 

• вложения — скриншот, видео, лог или ссылка.

Баг-репорт — это карточка ошибки с понятными шагами и ожидаемым результатом.

Шаблон баг-репорта

Пример заголовка: «Форма регистрации принимает пароль из 7 символов при минимуме 8». Такой заголовок понятнее, чем «Пароль работает неправильно».

Чек-лист тестировщика — это список проверок, которые нужно выполнить для функции, страницы или всего продукта. Он не описывает каждый шаг подробно, как тест-кейс. Он фиксирует, что именно нужно проверить, чтобы тестировщик ничего не пропустил.

Чек-лист используют для быстрых проверок, дымового тестирования, регрессии и исследовательского тестирования. Он удобен, когда команда уже понимает продукт и не нуждается в детальной инструкции для каждого действия.

Пример чек-листа для формы регистрации

Чек-лист помогает быстро пройти важные проверки и не забыть основные сценарии.

Как искать первую работу тестировщиком с нуля

Первая работа тестировщиком редко приходит только после курса. Работодатель хочет видеть, как человек думает и оформляет результаты. Где искать работу:

• стажировки; 

• вакансии для новичков; 

• учебные проекты; 

• проекты с открытым исходным кодом; 

• тестовые задания; 

• сообщества тестировщиков; 

• карьерные разделы ИТ-компаний.

Резюме должно быть коротким. Не пишите «быстро обучаюсь» без примеров. Лучше укажите проекты и артефакты.

Что добавить в портфолио:

• чек-лист для веб-формы; 

• 10–20 тест-кейсов; 

• 3–5 баг-репортов; 

• Postman-коллекцию; 

• SQL-запросы; 

• один простой автотест по желанию; 

• описание выводов по проекту.

На собеседовании могут спросить:

• чем отличается серьёзность дефекта от приоритета исправления; 

• что такое дымовое тестирование и санитарное тестирование, чем они отличаются; 

• как проверить поле имейл; 

• как оформить баг-репорт; 

• что такое REST; 

• какие коды HTTP вы знаете; 

• как проверить API в Postman; 

• зачем нужны тестовые данные; 

• как тестировать без полных требований.

Ответы должны быть прикладными. Лучше привести пример, чем дать сухое определение.

Сколько зарабатывает тестировщик и как растет в профессии

Зарплата зависит от региона, компании, формата работы, уровня, английского языка и опыта. Универсальной суммы нет.

Карьерный путь может быть таким:

1. Младший тестировщик 

2. Опытный тестировщик

3. Старший тестировщик

4. Инженер по автоматизации тестирования

5. Инженер по разработке ПО в тестировании (SDET)

6. Ведущий тестировщик (Lead) 

7. Руководитель отдела тестирования

Можно расти в ручном тестировании. Можно перейти в автоматизацию. Можно углубиться в API, мобильное тестирование, нагрузку, безопасность или данные.

Автоматизированное тестирование ближе к разработке. Инженер по разработке ПО в тестировании часто пишет инструменты для тестирования, работает с фреймворками и CI/CD. Ведущий тестировщик отвечает за процессы, команду, стратегию и метрики качества.

Типичные ошибки новичков

Новички часто пытаются выучить все сразу. Это мешает. Лучше пройти путь от простых проверок к API и только потом к автотестам.

Частые ошибки:

• нет портфолио; 

• баг-репорты размытые; 

• шаги воспроизведения неполные; 

• непонятно описан ожидаемый результат; 

• нет понимания требований; 

• SQL полностью игнорируется; 

• API кажется слишком сложным; 

• автотесты начинают раньше тест-дизайна; 

• нет Git-аккаунта; 

• кандидат не может рассказать о своих проверках.

Еще одна ошибка — писать в резюме инструменты без практики. Если указан Postman, будьте готовы показать коллекцию. Если указан SQL, будьте готовы написать простой запрос. Если указан GitHub, добавьте туда понятные материалы.

Чек-лист перед откликом

Перед откликом проверьте себя:

• резюме занимает 1–2 страницы; 

• портфолио открывается по ссылке; 

• есть чек-лист; 

• есть тест-кейсы; 

• есть баг-репорты; 

• есть Postman-коллекция; 

• есть базовые SQL-запросы; 

• вы умеете открывать инструменты разработчика; 

• вы знаете разницу между базовой проверкой сборки, точечной проверкой изменений и регрессионным тестированием; 

• вы можете объяснить разницу между приоритетом исправления и серьезностью дефекта; 

• есть GitHub или GitLab; 

• есть 2–3 проекта, о которых можно рассказать подробно.

Если какого-то пункта нет, не нужно ждать идеального момента. Доработайте слабые места и откликайтесь на стажировки. Рынок, требования и вакансии меняются. Перед откликом проверяйте актуальные описания вакансий.

Тестировщик помогает продукту стать надежнее. Он проверяет требования, проектирует тесты, находит дефекты, оформляет артефакты и общается с командой. Для старта нужна ручная база: тест-дизайн, баг-репорты, чек-листы, инструменты разработчика, Postman и SQL.

Начинайте с простого проекта. Протестируйте форму регистрации, напишите тест-кейсы, оформите баг-репорты и соберите Postman-коллекцию, затем добавьте чек-лист. Так тестировщик с нуля получает не только знания, но и первые доказательства навыков.