Lesson 16 of 26

Урок 16 — Ad Hoc Testing

Название: Ad Hoc Testing — тестирование без правил и плана
Описание: Разбираем, что такое Ad Hoc тестирование, чем оно отличается от исследовательского, когда оно полезно, а когда — нет, и как его применять осознанно.
Почему это важно для QA: Ad Hoc Testing — это инструмент, который при правильном применении позволяет быстро найти критические баги. Без понимания его ограничений он превращается в хаотичное «нажимание кнопок».


1. Что такое Ad Hoc Testing

Ad Hoc Testing — это вид тестирования без предварительного планирования, документации и формальных тест-кейсов. «Ad hoc» — латинское выражение, означающее «к этому случаю» или «без подготовки».

Тестировщик просто открывает приложение и тестирует так, как считает нужным, опираясь на опыт и интуицию.

Аналогия

Представь, что ты тестируешь новый смартфон, который тебе подарили. Ты не следуешь инструкции — просто начинаешь тыкать, пробовать, смотреть что будет. Это и есть Ad Hoc тестирование.


2. Характеристики Ad Hoc Testing

ХарактеристикаЗначение
ПланированиеОтсутствует
ДокументацияМинимальная или отсутствует
Тест-кейсыНе пишутся
СтруктураНеструктурированное
ВоспроизводимостьСложно воспроизвести
Зависит отОпыта тестировщика
ЦельБыстро найти баги

3. Ad Hoc vs Exploratory Testing

Эти понятия часто путают. Вот чёткая разница:

КритерийAd HocExploratory
СтруктураПолностью неструктурированноеСтруктурированное (чартеры, сессии)
ДокументацияНетЗаметки, результаты сессий
ПовторяемостьНетДа (через чартеры)
ЦельБыстрые случайные багиСистематическое исследование
Кто делаетЛюбой QAОпытный QA
АнализируемостьСложно оценить покрытиеПокрытие отслеживается

Простая формула:

Ad Hoc = Exploratory без структуры
Exploratory = Ad Hoc + чартеры + timebox + заметки

4. Когда Ad Hoc тестирование полезно

СитуацияПочему Ad Hoc подходит
Нет времени на планированиеБыстрая проверка за 30 минут
Новая функция только что появиласьПервичное знакомство с кодом
Нужно проверить конкретную идею«А что если попробовать вот это?»
После завершения формального тестированияДополнительная проверка «на всякий случай»
Воспроизведение бага от пользователяПопробовать нестандартные шаги

5. Виды Ad Hoc Testing

5.1 Buddy Testing

Два человека работают над одним модулем одновременно: разработчик и тестировщик. QA даёт мгновенную обратную связь ещё в процессе разработки.

Разработчик: «Я только что добавил форму регистрации»
QA: [немедленно открывает и пробует] «Попробовал emoji в поле — вылетает ошибка»

5.2 Pair Testing

Два QA-инженера тестируют вместе: один управляет (тестирует), другой наблюдает и предлагает идеи.

QA 1: [тестирует оформление заказа]
QA 2: «А попробуй оставить поле телефона с пробелами»
QA 1: [пробует] «О, принимает! Нужно создать баг»

5.3 Monkey Testing

Крайняя форма Ad Hoc: случайные, хаотичные действия без какой-либо логики. Может быть автоматизировано.

Примеры:
- Нажимать кнопки в случайном порядке
- Вводить случайные строки в поля
- Случайные клики по странице
- Автоматизированный «обезьяний» тест через инструменты

6. Как проводить Ad Hoc тестирование осознанно

Даже без плана можно тестировать умно:

Принципы опытного Ad Hoc тестировщика

1. Тестируй то, что кажется рискованным
   «Это поле принимает числа — а что с отрицательными?»

2. Думай как злоумышленник
   «Что если ввести SQL-команду в поле поиска?»

3. Следуй за интуицией
   «Что-то в этом модуле кажется ненадёжным»

4. Проверяй границы
   «Максимальное значение, пустота, ноль, отрицательные»

5. Пробуй нестандартные последовательности
   «Что если оплатить до добавления адреса?»

Минимальная фиксация находок

Даже при Ad Hoc важно записывать баги немедленно:

[Нашёл баг] → немедленно:
1. Сделать скриншот / записать видео
2. Записать шаги воспроизведения (пока помнишь!)
3. Открыть баг в трекере

Не откладывай — через 10 минут забудешь детали.

7. Пример: Ad Hoc сессия

Задача: Только что задеплоили новую функцию «Избранное» в интернет-магазине. Времени на полноценное планирование нет. Нужно быстро проверить.

Что тестировщик делает (30 минут, без плана):

09:00 Открываю страницу товара → вижу иконку ❤️
09:02 Кликаю на иконку → товар добавлен в Избранное ✓
09:03 Перехожу в раздел "Избранное" → товар там ✓
09:05 Удаляю товар из Избранного → исчезает ✓
09:07 А что если добавить один и тот же товар дважды? → дублируется! БАГ #1
09:10 А что если добавить 100 товаров? → добавляю... на 52-м ошибка 500 БАГ #2
09:15 Добавляю без авторизации → просит войти ✓
09:17 После входа — исчезли ли несохранённые товары? → да, теряются. Ожидаемо? Нужно уточнить.
09:22 Открываю в двух вкладках, добавляю в одной → вторая не обновляется автоматически. Нормально?
09:28 Что если удалить товар из каталога, который в Избранном? → в Избранном остаётся, но ведёт на 404. БАГ #3
09:30 Конец сессии. Найдено 3 бага.

8. Ограничения Ad Hoc Testing

ОграничениеПочему это проблема
Нет воспроизводимостиСложно повторить те же шаги в следующий раз
Нет покрытияНеизвестно, что было проверено
Зависит от опытаНовичок найдёт меньше багов
Нет приоритизацииМожно упустить критические риски
Нельзя регрессироватьНет тест-кейсов для повторного прогона

9. Когда Ad Hoc НЕ подходит

❌ Как замена формального тестирования
❌ Для регрессионного тестирования (нет воспроизводимости)
❌ Когда важна документация (compliance, certification)
❌ При нулевом опыте тестировщика в этой области


10. Частые ошибки

Путают Ad Hoc с ленью
→ Ad Hoc — это инструмент, а не отговорка для отказа от планирования.

Не фиксируют баги сразу
→ Без немедленной фиксации половина находок теряется.

Считают Ad Hoc Testing заменой Regression
→ Ad Hoc дополняет формальное тестирование, но не заменяет.


Итог

AD HOC TESTING
├── Что: тестирование без плана и тест-кейсов
├── Когда: быстрая проверка, нет времени, новая фича
├── Сила: быстро, гибко, иногда находит неожиданные баги
├── Слабость: нет воспроизводимости, нет покрытия
├── Виды: Buddy Testing, Pair Testing, Monkey Testing
└── Правило: даже при Ad Hoc — фиксируй баги немедленно