Что это простыми словами
QA Engineer Manual (он же ручной тестировщик) — человек, который проверяет программу или сайт, чтобы найти баги до того, как их увидят пользователи. Представьте, что приложение — это новый дом. QA Engineer — это инспектор, который обходит каждую комнату, проверяет двери, окна, электричество и сантехнику, чтобы убедиться, что всё работает, прежде чем заселить жильцов.
Слово «manual» означает «ручной» — тестировщик проверяет программу сам, нажимая кнопки, заполняя формы, воспроизводя сценарии использования. Он не пишет автоматические скрипты — этим занимаются другие специалисты, автоматизаторы.
Официальное определение
Теперь, когда суть понятна, вот как эту роль описывают в вакансиях и документации. Такую формулировку вы будете получать от заказчика и видеть в резюме.
«QA Engineer — специалист, выполняющий ручное тестирование программного обеспечения по тестовой документации, выявление и документирование дефектов, проверка соответствия функциональных требований».
Разберём по словам. «Ручное тестирование» — человек сам кликает и проверяет, а не запускает автоматический скрипт. «Тестовая документация» — это заранее подготовленные сценарии: пошаговые инструкции «что нажимать и что ожидать». «Дефект» — это баг, ошибка в программе.
Что делает за обычный день
Берёт список задач, которые разработчики недавно изменили или добавили, и проверяет, что всё работает правильно. Например, разработчик поменял кнопку «Купить» — тестировщик нажимает её десятки раз: с пустой корзиной, с товаром, без оплаты, с ошибкой карты, и записывает результаты.
Если находит проблему — оформляет баг-репорт: пишет чётко, что было, что ожидалось и что получилось на самом деле, чтобы разработчик понял, где копать. Потом проверяет исправление: разработчик починил — тестировщик убедился, что всё заработало.
Из чего состоит направление
За день тестировщик обычно выполняет несколько видов проверок:
Функциональное тестирование — проверяет, что программа делает то, что должна. Кнопка работает? Форма отправляется? Данные сохраняются?
Регрессионное тестирование — после каждого обновления перепроверяет старое, чтобы случайно ничего не сломать. Как проверка, что починив кран на кухне, ты не затопил ванную.
Кроссбраузерное и кроссплатформенное тестирование — проверяет, что сайт работает одинаково в Chrome, Safari, Firefox и на разных устройствах.
Тестирование API — проверяет обмен данными между сервером и интерфейсом напрямую, без браузера. Как проверить, правильно ли кухня передаёт заказы официантам, не дожидаясь, пока они донесут еду.
Документирование и баг-трекинг — ведёт отчётность в специальных системах, заводит и отслеживает баги.
Инструменты простыми словами
Инструменты тестировщика удобно разложить по слоям — от самых важных при отборе к менее критичным.
Слой 1. Работа с данными — без этого невозможно проверить, что данные правильно сохраняются и загружаются.
SQL — язык для запросов к базе данных. Представьте, что база данных — огромный склад, а SQL — способ сказать кладовщику: «Дай мне все товары категории „электроника“, которые стоят дешевле 10 тысяч». Тестировщик проверяет, что данные в базе совпадают с тем, что показывает интерфейс.
Слой 2. Работа с API — проверка обмена данными между интерфейсом и сервером.
Postman — самый популярный инструмент для проверки API. Позволяет отправить запрос к серверу и посмотреть ответ. Представьте, что это телеграф: вы отправляете сообщение серверу и смотрите, что он в ответ.
Insomnia — аналог Postman для API, чуть проще и легче. Кто знает один, быстро освоит другой.
Слой 3. Анализ трафика — позволяет увидеть, какие данные уходят от приложения к серверу и обратно.
Charles Proxy, Fiddler — программы, которые перехватывают и показывают всю сетевую активность. Как микроскоп для сети: видите каждый пакет данных, который уходит из приложения.
Слой 4. Управление тестами и багами — системы, где ведут отчётность.
TestRail, Qase, Allure TestOps — сервисы, где хранятся тест-кейсы, результаты прогонов и отчёты. Как электронный журнал для тестировщика.
Что взаимозаменяемо, а что путать нельзя
Postman и Insomnia взаимозаменяемы — кто работал с одним, освоит другой за пару часов. TestRail и Qase тоже — это системы управления тестами, принцип работы одинаковый.
Но не путайте: SQL — это язык для работы с данными, а Postman — инструмент для проверки API. Это не альтернативы друг другу, а разные инструменты для разных задач.
Уровни: junior / middle / senior
Уровень (его ещё называют грейд) — это не столько годы опыта, сколько самостоятельность.
Junior (джуниор, «джун») — проверяет по готовым чек-листам, пишет простые баг-репорты, нуждается в контроле и подсказках от старших.
Middle (мидл) — самостоятельно составляет тест-кейсы, понимает архитектуру продукта, пишет подробные баг-репорты, может тестировать API и работать с SQL. Основная рабочая сила команды.
Senior (сеньор) — строит процесс тестирования: определяет стратегию, автоматизирует рутину, менторит младших, участвует в проектировании продукта. Видит проблемы до того, как они стали багами.
Это общий ориентир. В разных компаниях требования отличаются, поэтому всегда сверяйтесь с текстом конкретной вакансии.
Как узнать роль в резюме
Ищите в резюме слова: «ручной тестировщик», «manual QA», «тестировщик», «QA Engineer». В разделе «стек» обычно перечислены инструменты: Postman, SQL, Jira, TestRail, Charles Proxy и тому подобное. Хороший признак — описание опыта: человек говорит о конкретных проектах, типах тестирования (функциональное, регрессионное, API), количестве найденных и закрытых багов.
Обратите внимание: если человек написал просто «QA Engineer» без уточнения — это неполная информация. Нужно уточнить, занимался он ручным тестированием или автоматизацией.
Что спросить на первичном скрининге
С каким типом тестирования работали (ручное, API, функциональное, регрессионное)?
Нормальный ответ: человек подробно рассказывает, что тестировал — например, «веб-интерфейс интернет-магазина, регресс после каждого релиза, API по Postman». Насторожить должно, если всё звучит очень общо: «просто тестировал».
Работали ли с SQL?
Нормальный ответ: «Да, писал запросы для проверки данных в бэкенде» или «Умею делать SELECT с JOIN». Для middle и senior это уже стандарт. Если junior — нормально, что пока не уверенно.
Опишите типичный баг-репорт, который вы заводили.
Нормальный ответ: человек называет структуру — «описание, шаги воспроизведения, ожидаемый и фактический результат, скриншот». Если говорит размыто — «просто фиксил баги» — повод насторожиться.
Какие инструменты использовали для управления тестами и багами?
Нормальный ответ: «TestRail для тест-кейсов, Jira для багов». Главное — чтобы человек понимал, зачем ему эти инструменты, а не просто перечислял названия.
Это общий ориентир. В разных компаниях требования отличаются, поэтому всегда сверяйтесь с текстом конкретной вакансии.
Частые путаницы и красные флаги
QA Engineer Manual ≠ QA Automation. Ручной тестировщик проверяет сам, автоматизатор пишет код, который тестирует программу. Это разные роли.
QA ≠ Quality Assurance. Качество — это широкое понятие, включающее процессы, культуру и менеджмент. QA Engineer — конкретная роль тестировщика. Но в вакансиях слово «QA» почти всегда означает тестировщика.
Тестировщик ≠ разработчик. Тестировщик ищет ошибки, разработчик их создаёт (и чинит). Хотя хороший тестировщик разбирается в коде — это плюс, но не то же самое.
Красный флаг: «500+ багов за месяц» — слишком много для ручного тестировщика. Скорее всего, это либо баг-репорты без проверки, либо некачественные отчеты.
Красный флаг: «100% покрытие тестами» — такой показатель невозможен в ручном тестировании. Покрытие измеряется в процентах, и даже автоматизаторы редко достигают 100%.