Автоматизированные тесты проверяют: «кликается ли эта кнопка, отправляется ли форма, возвращает ли API 200?» Они не замечают что сообщение об ошибке грамматически правильное, но для нетехнического клиента лишено смысла, или что новая фича конфликтует с рабочим процессом за три экрана до неё. Этот разрыв и покрывает ручное тестирование, именно поэтому организации которые внедряют автоматизацию обнаруживают: она расширяет область тестирования, а не заменяет людей которые его делают.
Что такое ручное тестирование на самом деле
Ручное тестирование: живой тестировщик взаимодействует с программным обеспечением чтобы найти дефекты, верифицировать поведение и оценить качество, без использования автоматизированных скриптов для управления взаимодействиями.
Определение звучит просто, но охватывает широкий диапазон активностей: выполнение заранее написанного тест-кейса шаг за шагом, исследование новой фичи без какого-либо скрипта, оценка того насколько интерфейс удобен в использовании, или сравнение готовой фичи с исходным требованием чтобы проверить что они совпадают.
«Ручное» в ручном тестировании не означает медленное или низкокачественное. Оно означает что человеческое суждение делает работу которую не может заменить никакой скрипт.
Почему автоматизация не делает ручное тестирование устаревшим
Автоматизированные тесты проверяют то что им сказано проверять. Они верифицируют: «кликается ли эта кнопка, отправляется ли форма, возвращает ли API 200?» Делают это надёжно и быстро, тысячи раз.
Чего автоматизированные тесты не могут: заметить что кнопка технически кликабельна но расположена так что вводит пользователей в замешательство. Заметить что сообщение об ошибке грамматически корректно но не имеет смысла для нетехнического клиента. Заметить что новая фича, работая правильно, конфликтует с рабочим процессом за три экрана до неё, так как никто этого не предвидел.
Живые тестировщики замечают эти вещи. Не потому что люди лучше компьютеров в проверке ассертов (это не так), а потому что люди привносят контекст, опыт и способность спрашивать «имеет ли это смысл?», которую никакой тестовый скрипт воспроизвести не способен.
По данным Capgemini World Quality Report 2025–2026, 89% организаций внедряют AI и автоматизацию в обеспечение качества. Тот же отчёт отмечает: большинство из них обнаруживает что автоматизация расширяет область тестирования, а не заменяет людей которые его делают.
Типы ручного тестирования
Функциональное тестирование верифицирует что фичи работают согласно спецификации. Вход аутентифицирует пользователей, корзина правильно считает суммы, экспорт генерирует нужный формат файла. Это наиболее часто автоматизируемая категория, но ручное выполнение имеет смысл для новых фич до того как автоматизация написана. Исследовательское тестирование: наиболее человеческая активность в QA. Тестировщик одновременно изучает систему, разрабатывает тесты на основе того что находит, и выполняет эти тесты, всё в реальном времени. Нет никакого скрипта. Тестировщик следует своим инстинктам, опыту и любопытству. Именно здесь опытные тестировщики находят баги которые автоматизация никогда не нашла бы, потому что никто не подумал написать тест для этой конкретной последовательности событий. Юзабилити-тестирование проверяет насколько программное обеспечение интуитивно и эффективно в использовании. Может ли новый пользователь завершить основной флоу без инструкций? Понятны ли сообщения об ошибках? Логична ли компоновка? Автоматизация может верифицировать что элементы существуют, но не скажет приятно ли использовать продукт. Регрессионное тестирование верифицирует что существующие фичи продолжают работать после изменений. Это наиболее подходящая для автоматизации категория: повторяющаяся, хорошо определённая, стабильная. Ручное регрессионное тестирование всё ещё практикуется в организациях без автоматизации, и как выборочная проверка даже в тех где есть полная автоматизация. Приёмочное тестирование подтверждает что поставленное программное обеспечение соответствует требованиям согласованным со стейкхолдерами. Часто проводится вручную продукт-оунером или QA-лидом, сравнивающим реальный продукт с исходной спецификацией или пользовательской историей.Как ручное тестирование вписывается в современные Agile-команды
Старая модель: спринты разработки, затем «фаза тестирования» где QA всё верифицирует вручную перед релизом. Больше это не работает. Фаза тестирования превращается в узкое место и команды не могут выпускать релизы достаточно часто.
Современная модель: QA вовлечён с начала спринта, а не с конца.
При планировании: QA изучает спецификацию фичи и выявляет неоднозначности. «Что происходит если пользователь загружает файл превышающий лимит размера?» Этот вопрос стоит задать до начала разработки, а не после.
Во время разработки: разработчики пишут юнит-тесты для своего кода. QA пишет тест-кейсы и может начинать автоматизированные тесты против API-эндпоинтов как только они появляются, до того как построен UI.
Во время тестирования: новые фичи получают ручное исследовательское тестирование: QA-инженер тратит 30–60 минут пытаясь сломать фичу неожиданными способами. Регрессионное покрытие обеспечивает автоматизированный сьют.
После релиза: мониторинг и тестирование в продакшне чтобы выловить проблемы которые появляются только при масштабе или с реальными пользовательскими данными.
Как выглядит ручное тестирование на практике
Вот как выглядит сессия ручного исследовательского тестирования на lab.becomeqa.com:
Заходишь и переходишь к таблице travel items. Автоматизированные тесты верифицируют что элементы загружаются и отображаются корректно. Задача ручного тестировщика: искать то что автоматизированные тесты пропустили.
Пробуешь: сортировку таблицы по разным колонкам, затем добавляешь новый элемент и проверяешь появляется ли он в правильной отсортированной позиции. Пробуешь редактировать элемент пока таблица отфильтрована. Пробуешь быстро кликнуть кнопку удаления дважды, чтобы проверить обрабатывается ли двойная отправка. Пробуешь уйти со страницы в середине редактирования и вернуться: сохраняются ли несохранённые изменения или выбрасываются. Пробуешь открыть модал добавления, заполнить половину формы, закрыть и открыть снова: сохраняются ли предыдущие данные.
Ничего из этого, скорее всего, нет в автоматизированном регрессионном сьюте. Всё это то что реальный пользователь может сделать.
Навыки которые важны для ручного тестирования
Анализ требований. Можешь ли прочитать пользовательскую историю и выявить что недоспецифицировано? «Как пользователь, я могу фильтровать элементы по статусу.» Это одиночный выбор или множественный? Что происходит если ни один элемент не соответствует фильтру? Проектирование тест-кейсов. Разбиение на классы эквивалентности, анализ граничных значений, таблицы решений, тестирование переходов состояний: эти техники позволяют покрыть больше при меньшем количестве тест-кейсов. Они нужны не только для автоматизации. Составление баг-репортов. Баг-репорт который исправляется сразу против того который возвращается с «не воспроизводится». Это целиком вопрос качества отчёта: воспроизводимые шаги, чёткое ожидаемое и фактическое поведение, правильные детали окружения. Коммуникация. Ручные тестировщики постоянно общаются с разработчиками, продукт-оунерами и стейкхолдерами. Умение объяснить баг, точно оценить его серьёзность и отстоять необходимость исправить его до релиза. Это ключевой навык. Техника исследовательского тестирования. Умение структурировать исследовательскую сессию (чарты, заметки, управление временем) отличает продуктивное исследование от случайного кликания.Частые вопросы
Ручное тестирование: тупиковая карьера?
Нет. Позиций чисто ручного тестировщика становится меньше, но ручное тестирование как навык ценнее чем когда-либо, оно интегрировано в работу QA-инженеров которые ещё и автоматизируют. Инженеры которые понимают как тестировать хорошо, а не просто умеют писать скрипты, строят тестовые сьюты которые реально ловят баги.
Нужно ли учить программирование при ручном тестировании?
Необязательно, но знание достаточного количества SQL чтобы делать запросы к базе данных, достаточного JavaScript чтобы читать вывод тестов, и достаточного HTTP чтобы пользоваться Postman открывает значительно больше дверей. Не нужно быть разработчиком, но техническая грамотность помогает.
Как показать навыки ручного тестирования в портфолио?
Документируй свой процесс тестирования: пиши образцы баг-репортов, создавай тест-планы для фич которые тестировал, записывай сессию исследовательского тестирования и аннотируй что ты искал и почему. Вдумчивый баг-репорт производит большее впечатление чем ожидает большинство нанимающих менеджеров.
В чём разница между QA и тестированием?
Тестирование находит дефекты. QA (Quality Assurance) шире. Охватывает процессы, стандарты и практики которые предотвращают появление дефектов с самого начала. QA-инженер тестирует, но также ревьюит требования, участвует в проектировании и влияет на то как строится программное обеспечение. Это различие важно на практике: тестировщик сосредоточенный только на поиске багов делает меньше чем QA-инженер который помогает их предотвращать.
→ See also: Как писать тест-кейсы: формат, примеры и частые ошибки | Анатомия баг-репорта, который исправят: структура и примеры
