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

Три степени формализации

Тестирование по тест-кейсам (scripted testing) — самый формализованный подход: проверки описаны заранее, вы выполняете их по шагам. Сильные стороны — полнота и повторяемость: ничего не забудется, прогон может выполнить любой член команды, по результатам легко считать метрики. Слабая — кейсы проверяют только то, что в них написано: баг, живущий в шаге в сторону от сценария, останется незамеченным.

Исследовательское тестирование (exploratory testing) — частично формализованный подход: вы изучаете продукт и придумываете проверки на ходу, опираясь на то, что только что увидели. Каждый результат подсказывает следующий шаг: заметили странность при вводе длинного имени — копнули глубже, нашли закономерность — проверили её в соседних местах. Ключевое: это не бессистемное тыканье, а управляемое исследование — у вас есть цель и вы двигаетесь к ней, просто маршрут строится по ситуации.

Свободное тестирование (ad hoc) — полностью неформализованный подход: ни кейсов, ни чек-листов, ни цели-сценария — только интуиция и опыт. Применяется редко и только как дополнение: например, за десять минут «пройтись свежим взглядом» по новой сборке, пока кейсы ещё не написаны.

Частая ошибка — путать исследовательское и свободное тестирование. Разница принципиальна: в исследовательском есть цель, рамки и фиксация результатов; в свободном — нет ничего. Первое — метод; второе — разминка.

Как проводить исследовательское тестирование: сессии и чартеры

Чтобы исследование не расползалось, его упаковывают в сессии — ограниченные по времени заходы (обычно 60-120 минут) с явной целью. Цель записывают заранее одной-двумя фразами — такую запись называют чартером: «исследовать оформление заказа с промокодами: скидки, сочетания, истёкшие коды». Такой подход называют сессионным тестированием (session-based testing).

Во время сессии вы ведёте короткие заметки: что проверили, что показалось странным, какие баги завели. После сессии по заметкам видно, что покрыто, а что осталось — и можно честно отчитаться, а не «ну я потыкал».

Облегчённый вариант — тестирование по чек-листу: список того, что проверить, без расписывания как. Полпути между кейсами и свободным исследованием: направление задано, маршрут ваш.

Предугадывание ошибок

Опытный тестировщик часто идёт сразу туда, где «обычно ломается», — это техника предугадывания ошибок (error guessing). Она опирается на знание типичных слабых мест: границы значений, пустые и слишком длинные вводы, спецсимволы, действия в неожиданном порядке, двойные нажатия, обрыв связи посередине операции.

У новичка такой копилки ещё нет — но она быстро накапливается, если после каждого найденного бага спрашивать себя: «а где ещё может быть такая же ошибка?». Найденный баг — это не только запись в трекере, но и подсказка для следующих проверок.

В каком порядке проверять: от простого позитивного к сложному негативному

Практический принцип, который экономит массу времени. Начинайте с простых позитивных проверок: всё вводим правильно, идём по основному пути. Затем — простые негативные: очевидно неверные данные, пустые поля. Потом — сложные позитивные: корректные, но замысловатые сценарии. И только в конце — сложные негативные: экзотические комбинации ошибок.

Почему так: если сразу закопаться в экзотику, можно получить продукт, который стойко переносит хитрые атаки, но не работает в элементарном повседневном сценарии. Сначала убедитесь, что работает главное, — потом усложняйте. Это не догма, но отступать от неё стоит осознанно.

Что с чем сочетать

Подходы не конкурируют — они дополняют друг друга:

  • Кейсы — для регрессии, критичных сценариев и всего, что должно проверяться повторяемо от релиза к релизу.
  • Исследовательские сессии — для новых функций (кейсов ещё нет), областей после больших переделок и «подозрительных» мест. И как регулярная добавка к кейсам: то, что не покрыто сценариями, находят именно сессии.
  • Ad hoc — короткая разведка, когда нужно быстро составить первое впечатление о сборке.

Где это применяется

В обычном спринте это выглядит так: по новой задаче вы сначала проводите исследовательскую сессию (заодно накидывая идеи для будущих кейсов), затем оформляете стабильные проверки в кейсы для регрессии. Умение проводить управляемое исследование — а не просто «потыкать» — это то, что отличает тестировщика от случайного человека с мышкой.

Где спотыкаются начинающие:

  • Подменяют исследование хаосом. Без чартера и заметок сессия превращается в бесцельное блуждание, о котором нечего рассказать команде.
  • Считают кейсы «скучными», а исследование «настоящим» — и наоборот. Нужны оба: кейсы держат фундамент, исследование находит неожиданное.
  • Начинают с экзотики. Полчаса на проверку ввода эмодзи в поле имени — при том, что обычное сохранение формы ещё ни разу не пройдено.

Что учить дальше. Идеи для исследовательских сессий берутся из техник тест-дизайна — границы и классы эквивалентности работают и без формальных кейсов. А как фиксировать найденное — в статье про баг-репорты.