TL;DR

  • Ручное тестирование использует человеческое суждение для поиска багов, которые пропускает автоматизация — проблемы юзабилити, визуальные дефекты, неожиданное поведение
  • Ключевые навыки: дизайн тест-кейсов, исследовательское тестирование, баг-репорты, анализ требований
  • Структура тест-кейса: ID, название, предусловия, шаги, ожидаемый результат, фактический результат
  • Баг-репорты должны содержать: описание, шаги воспроизведения, ожидаемое vs фактическое, severity, скриншоты
  • Ручное тестирование дополняет автоматизацию — оба подхода необходимы для качества

Идеально для: Начинающих QA-инженеров, людей, меняющих карьеру, разработчиков, изучающих основы QA Пропусти, если: Работаешь только с автоматизированными пайплайнами и не касаешься UI Время чтения: 18 минут

Твой автоматизированный набор тестов проходит. Пользователи сообщают, что кнопка оформления заказа не видна на мобильных. Форма логина принимает пустые пароли. Сообщение об ошибке говорит “Error: null.”

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

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

Что такое ручное тестирование?

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

Что включает ручное тестирование:

  • Чтение и понимание требований
  • Проектирование тест-кейсов и тестовых сценариев
  • Пошаговое выполнение тестов
  • Сравнение фактических результатов с ожидаемыми
  • Написание и отслеживание багов
  • Повторное тестирование исправленных проблем

Почему ручное тестирование важно:

  • Находит проблемы юзабилити — автоматизация не может судить, запутанный ли UI
  • Обнаруживает edge cases — человеческая интуиция ловит неожиданные сценарии
  • Валидирует пользовательский опыт — реальные пользователи не следуют скриптам
  • Быстро адаптируется — нет кода для обновления при изменении требований
  • Экономично для малых проектов — настройка автоматизации занимает время

Типы ручного тестирования

Функциональное тестирование

Проверяет, что функции работают согласно требованиям.

Требование: Пользователь может сбросить пароль через email

Тест:
1. Нажать "Забыли пароль"
2. Ввести зарегистрированный email
3. Нажать Отправить
4. Проверить email на наличие ссылки сброса
5. Перейти по ссылке, ввести новый пароль
6. Войти с новым паролем

Ожидаемо: Пользователь успешно входит с новым паролем

Исследовательское тестирование

Тестирование без скрипта, где тестировщики свободно исследуют приложение.

Цель сессии: Исследовать flow оформления заказа на edge cases

Время: 30 минут

Заметки:
- Что происходит при 100 товарах в корзине?
- Можно ли оформить заказ с истёкшей картой?
- Что если изменить количество во время оплаты?
- Ломает ли кнопка "назад" flow?
- Что происходит при таймауте сети?

Smoke-тестирование

Быстрые тесты для проверки базовой функциональности после нового билда.

Smoke Test Checklist:
□ Приложение запускается
□ Логин работает
□ Основная навигация доступна
□ Ключевая функция (поиск) работает
□ Нет ошибок в консоли на ключевых страницах
□ Логаут работает

Регрессионное тестирование

Повторное тестирование существующей функциональности после изменений кода.

Изменено: Редизайн страницы профиля

Области регрессии:
- Редактирование профиля всё ещё работает
- Загрузка аватара функционирует
- Смена пароля работает
- Email-уведомления отправляются
- API endpoints возвращают те же данные
- Другие страницы со ссылками на профиль работают

Написание тест-кейсов

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

Структура тест-кейса

ID тест-кейса: TC-LOGIN-001
Название: Успешный вход с валидными credentials

Модуль: Аутентификация
Приоритет: Высокий
Предусловия:
- Аккаунт пользователя существует
- Пользователь на странице логина

Шаги теста:
1. Ввести валидный username "testuser@example.com"
2. Ввести валидный пароль "SecurePass123"
3. Нажать кнопку "Войти"

Ожидаемый результат:
- Пользователь перенаправлен на дашборд
- Приветственное сообщение показывает username
- Сессия создана (видно в dev tools)

Фактический результат: [Заполняется при выполнении]
Статус: [Pass/Fail]
Тестировал: [Имя]
Дата: [Дата]

Лучшие практики тест-кейсов

1. Одна вещь на тест-кейс

# Плохо - тестирует несколько вещей
Название: Функциональность логина

# Хорошо - специфично и сфокусировано
Название: Логин не проходит с неправильным паролем
Название: Логин не проходит с несуществующим email
Название: Логин проходит с валидными credentials

2. Чёткие, выполнимые шаги

# Плохо - размыто
1. Попробовать залогиниться
2. Проверить, работает ли

# Хорошо - конкретно
1. Ввести email "user@test.com" в поле email
2. Ввести пароль "wrong123" в поле пароля
3. Нажать кнопку "Войти"
4. Наблюдать сообщение об ошибке

3. Измеримые ожидаемые результаты

# Плохо - субъективно
Ожидаемо: Страница загружается быстро

# Хорошо - измеримо
Ожидаемо: Страница загружается за 3 секунды, все изображения видны

Исследовательское тестирование

Исследовательское тестирование объединяет дизайн и выполнение тестов одновременно. Ты учишься, тестируешь и адаптируешься в реальном времени.

Сессионное исследовательское тестирование

Чартер сессии:
Исследовать: Обработка платежей
Длительность: 45 минут
Фокус: Edge cases и обработка ошибок

Заметки сессии:
[10:00] Начал с валидного платежа - работает
[10:05] Попробовал платёж на $0.01 - принят (это правильно?)
[10:12] Тестировал отрицательную сумму - сообщение об ошибке неясное
[10:18] Платёж со спецсимволами в имени - крашится
[10:25] Таймаут во время обработки - нет опции восстановления
[10:35] Множественные быстрые отправки - дублирующиеся списания!

Найдено багов: 3
Вопросов: 2
Области для дальнейшего тестирования: Обработка таймаутов, валидация ввода

Техники исследовательского тестирования

Граничное тестирование

Поле: Возраст (принимает 18-100)

Тестовые значения:
- 17 (ниже минимума)
- 18 (на минимуме)
- 19 (выше минимума)
- 99 (ниже максимума)
- 100 (на максимуме)
- 101 (выше максимума)
- 0, -1, 999, пусто, текст

Тестирование переходов состояний

Состояния корзины:
Пустая → Есть товары → Оформление → Оплата → Подтверждение

Тестируем переходы:
- Пустая → сразу в Оформление (должно не пройти)
- Есть товары → обратно в Пустую → Оформление (должно не пройти)
- Оплата → назад в браузере → снова Оплата (дубликат?)
- Подтверждение → обновить (что происходит?)

Написание баг-репортов

Баг-репорт должен позволить любому воспроизвести проблему.

Структура баг-репорта

Bug ID: BUG-2026-0142
Название: Оформление заказа не работает при более чем 50 товарах в корзине

Severity: High
Priority: High
Статус: New
Окружение: Production, Chrome 120, macOS 14.2

Шаги воспроизведения:
1. Войти как любой пользователь
2. Добавить 51 товар в корзину
3. Нажать "Оформить заказ"
4. Ввести валидный адрес доставки
5. Нажать "Продолжить к оплате"

Ожидаемый результат:
Страница оплаты загружается с суммой заказа

Фактический результат:
Страница показывает "Error 500: Internal Server Error"
Консоль: "TypeError: Cannot read property 'length' of undefined"

Вложения:
- screenshot_error.png
- console_log.txt
- network_har.har

Дополнительно:
- Работает нормально с 50 или менее товарами
- Проблема началась после деплоя 25 января
- Затрагивает все протестированные браузеры

Severity vs Priority

SeverityОписаниеПример
CriticalСистема неработоспособнаПриложение крашится при запуске
HighОсновная функция сломанаНевозможно завершить покупку
MediumФункция работает с ограничениямиФильтры поиска не работают
LowНезначительная проблемаОпечатка в футере

Тестирование с помощью ИИ

ИИ-инструменты могут помочь с задачами ручного тестирования при правильном использовании.

Что ИИ делает хорошо:

  • Генерирует идеи тест-кейсов из требований
  • Предлагает edge cases и граничные значения
  • Создаёт шаблоны баг-репортов
  • Создаёт вариации тестовых данных

Что всё ещё требует людей:

  • Оценка юзабилити и пользовательского опыта
  • Интуиция исследовательского тестирования
  • Понимание бизнес-контекста
  • Определение severity и priority

FAQ

Что такое ручное тестирование?

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

Актуально ли ручное тестирование в 2026?

Да. Ручное тестирование остаётся необходимым для исследовательского тестирования, оценки юзабилити, ad-hoc тестирования и сценариев, требующих человеческого суждения. Хотя автоматизация эффективно справляется с повторяющимися регрессионными тестами, ручное тестирование отлично находит неожиданные баги, оценивает пользовательский опыт и тестирует новые функции до создания автоматизации.

Какие навыки нужны ручным тестировщикам?

Ключевые навыки включают критическое мышление, внимание к деталям, чёткую коммуникацию, анализ требований, дизайн тест-кейсов и написание баг-репортов. Знание предметной области помогает понять потребности пользователей. Технические навыки — SQL, API-тестирование, инструменты разработчика браузера — становятся всё более ценными.

Как писать хорошие тест-кейсы?

Хорошие тест-кейсы специфичны, воспроизводимы и отслеживаемы. У них чёткие названия, явные предусловия, пошаговые действия, измеримые ожидаемые результаты и поля для фактических результатов. Каждый тест-кейс должен проверять одну вещь. Включай значения тестовых данных, а не просто “валидные данные”.

Смотрите также