Ручное тестирование (QA manual) — это проверка программы, которую тестировщик выполняет сам, руками, повторяя действия пользователя и сверяя поведение продукта с ожидаемым, без скриптов автоматизации. Проще говоря, человек открывает приложение, проходит по сценариям и смотрит, работает ли все так, как задумано.
Содержание
Ниже разберу, чем именно занимается ручной тестировщик, какие виды проверок делают вручную, чем отличаются тест-кейс, чек-лист и баг-репорт, где проходит граница между ручным и автоматизированным тестированием и как из ручного QA перейти в автоматизацию.
QA, QC и тестирование: как не путать термины
Три близких понятия часто смешивают, хотя они про разное:
- QA (quality assurance, обеспечение качества) — это про процесс. Задача — выстроить работу так, чтобы дефектов появлялось меньше: требования, процессы, ревью, договоренности в команде.
- QC (quality control, контроль качества) — это про продукт. Задача — найти дефекты в том, что уже сделано.
- Тестирование — конкретная проверка продукта, часть QC. Именно ее и выполняет тестировщик.
Ручное тестирование — это способ выполнять проверку: тестировщик делает ее сам, в отличие от автоматизированного, где проверку выполняет заранее написанный скрипт. Так что «QA manual» в вакансиях — это чаще всего именно ручной тестировщик, а не отдельная наука.
Чем занимается ручной тестировщик
Работа не сводится к тому, чтобы «покликать и найти баги». Типичные задачи:
- разбирает требования, макеты и пользовательские сценарии, задает вопросы аналитику и продакту, если что-то описано неоднозначно;
- проектирует проверки: составляет тест-кейсы и чек-листы под новую функциональность;
- выполняет проверки руками: новые фичи, регресс после доработок, поведение в разных браузерах и на разных устройствах;
- проводит исследовательское тестирование, когда сценарии заранее не заданы и нужно найти проблемы там, где их не ждут;
- заводит баг-репорты на найденные дефекты и повторно проверяет исправления (ре-тест);
- обсуждает с командой, как воспроизвести и починить ошибку.
Тестирование сопровождает весь жизненный цикл разработки ПО: чем раньше тестировщик подключается к требованиям, тем дешевле обходится найденная проблема.
Виды тестирования и что из них делают вручную
Видов тестирования много, и делят их по разным признакам: по уровню (модульное, интеграционное, системное), по цели (функциональное, нефункциональное) и по знанию внутренней структуры (черный и белый ящик). Ручного тестировщика чаще касаются виды, где важен взгляд пользователя.
Ниже — ориентир, что удобнее делать руками, а что обычно автоматизируют. Это не жесткое правило: выбор зависит от проекта и стабильности сценариев.
| Вид проверки | Что проверяет | Обычно вручную или автоматизируют |
|---|---|---|
| Функциональное | работает ли функция по требованиям | и так, и так; новое — чаще руками |
| Исследовательское (exploratory) | проблемы вне заранее описанных сценариев | вручную |
| Юзабилити | удобство и понятность интерфейса | вручную |
| UI и верстка | внешний вид, расположение элементов | чаще вручную; часть — авто-скриншотами |
| Кросс-браузерное и кросс-девайсное | поведение в разных браузерах и на устройствах | и так, и так |
| Локализационное | перевод, форматы дат, валют | чаще вручную |
| Дымовое (smoke) | запускается ли основное после сборки | и так, и так |
| Регрессионное | не сломалось ли старое после правок | выгодно автоматизировать |
| Нагрузочное и производительность | поведение под нагрузкой | инструментами, не руками |
Отдельно стоит поправить частое заблуждение: нагрузочное тестирование и тестирование безопасности — это специализированные направления. Их ведут отдельными инструментами и не относят к классическому «покликать руками», хотя тестировщик может участвовать в подготовке сценариев.
Тест-кейсы, чек-листы и баг-репорты
Это основные рабочие документы ручного тестировщика. Их легко перепутать, поэтому развожу явно.
Чек-лист — это список того, что нужно проверить, без подробных шагов. Пример пункта: «форма входа: вход по верному логину и паролю». Быстро составлять и проходить, удобно для знакомого функционала.
Тест-кейс — это подробный сценарий одной проверки. В нем есть предусловия, пронумерованные шаги, тестовые данные и ожидаемый результат. Его пишут там, где важна воспроизводимость и точность: сложные или критичные сценарии, оплата, регистрация.
Баг-репорт — это описание найденного дефекта так, чтобы разработчик смог его воспроизвести и починить. Хороший баг-репорт содержит:
- заголовок — коротко и по сути;
- шаги воспроизведения — что нажимать по порядку;
- ожидаемый результат и фактический результат;
- severity (важность дефекта для системы) и priority (срочность исправления);
- окружение — браузер, устройство, версия сборки;
- вложения — скриншот, видео, лог.
Severity и priority — не одно и то же. Опечатка в тексте на видной странице может быть низкой severity (система работает), но высокой priority (видит каждый, чинить срочно). А редкий сбой при экзотических данных — наоборот, высокой severity и низкой priority. Разбираться в видах ошибок и дефектов полезно как раз для того, чтобы точно оценивать severity.
Ручное vs автоматизированное тестирование
Это не спор «что лучше»: подходы решают разные задачи и дополняют друг друга.
| Признак | Ручное | Автоматизированное |
|---|---|---|
| Кто выполняет проверку | человек | скрипт или инструмент |
| Порог входа | ниже, код не обязателен на старте | нужен код и его поддержка |
| Скорость на повторных прогонах | медленнее | быстрее |
| Гибкость к изменениям | высокая | тесты надо переписывать под изменения |
| Оценка удобства и внешнего вида | подходит | плохо подходит |
| Стоимость на старте | ниже | выше (написать тесты) |
| Стабильность результата | зависит от человека | стабильнее |
Автоматизируют то, что повторяется и редко меняется: регресс, проверки API, нагрузку, сценарии на большом объеме данных. Вручную оставляют то, что меняется или требует человеческого суждения: новые функции, юзабилити, исследовательское тестирование, редкие сценарии.
Важный нюанс: автоматизация не отменяет ручное тестирование и не заменяет тестировщика. Кто-то должен решить, что вообще проверять, какие сценарии стоит автоматизировать и как оценить результат там, где важна оценка человека.
Перспективы и переход в автоматизацию
Ручное тестирование — распространенная точка входа в IT: порог по программированию на старте невысокий, а разобраться в том, как устроена работа с требованиями и дефектами, можно за обозримое время. Дальше путей несколько.
Развитие внутри ручного тестирования: от джуна к более самостоятельным задачам, участие в проектировании тест-стратегии, специализация (например, тестирование мобильных приложений или API). Рядом — роли QA lead и аналитик по качеству. Какие вообще бывают должности в IT и чем они отличаются, удобно посмотреть отдельно.
Переход в автоматизацию (AQA) — частый и логичный шаг. Для него постепенно осваивают:
- язык программирования — обычно Python, Java или JavaScript;
- инструменты автотестов UI — например, Selenium или Playwright;
- работу с API и запросами — Postman и понимание REST;
- SQL для проверки данных и Git для командной работы;
- основы CI, чтобы тесты запускались автоматически.
Честно про сроки: это не «за пару недель». Переход требует практики на реальных задачах, и ручной опыт тут помогает — автоматизатор пишет тесты для сценариев, которые уже понимает как тестировщик.
FAQ
Нужно ли уметь программировать, чтобы работать ручным тестировщиком?
На старте писать код не обязательно. Но базовое понимание SQL, устройства веба и работы с консолью браузера заметно облегчает работу и открывает путь в автоматизацию.
Обязателен ли английский?
На старте это не блокер, но английский полезен: документация, названия инструментов и термины чаще на английском. Технический английский подтягивают уже в процессе.
Чем тестировщик отличается от разработчика?
Задачи разные: разработчик пишет код, тестировщик проверяет, что продукт работает по требованиям. Граница гибкая — разработчик может писать автотесты, а тестировщик со временем перейти в автоматизацию.
Заменит ли автоматизация ручных тестировщиков?
Автоматизация забирает рутинные повторяемые проверки, но не отменяет ручную работу: юзабилити, исследовательское тестирование и оценку новых фич человеку по-прежнему делать самому. Скорее меняется набор задач, чем исчезает профессия.
Выводы
- Ручное тестирование (QA manual) — это проверка продукта человеком по сценариям пользователя, без скриптов автоматизации.
- QA — про процесс и предотвращение дефектов, QC — про поиск дефектов в продукте, тестирование — конкретная проверка внутри QC.
- Основные документы тестировщика — чек-лист (список проверок), тест-кейс (подробный сценарий) и баг-репорт (воспроизводимое описание дефекта с severity и priority).
- Ручное и автоматизированное тестирование не конкурируют: авто берет повторяемое и стабильное, ручное — новое, меняющееся и требующее оценки человека.
- Ручное тестирование — удобная точка входа в IT и логичный старт для перехода в автоматизацию.
Освойте тему на практике
Разобраться в процессе тестирования системно, от требований до баг-репортов, и довести навыки до уровня, с которым берут на работу, помогает курс Инженер по тестированию ПО: программа как раз про ручное тестирование с нуля.
Освойте тему на практике
Если пока хотите просто присмотреться к профессии, загляните на открытые уроки и мероприятия Otus по тестированию — это бесплатный способ понять, ваше это или нет, до старта обучения.
