Что такое SBTM?

Session-Based Test Management (SBTM) был разработан Джонатаном и Джеймсом Бахами для решения фундаментальной проблемы: как управлять, измерять и отчитываться об исследовательском тестировании?

Скриптовое тестирование легко управляемо — есть тест-кейсы, отслеживается их статус. Но исследовательское тестирование не имеет заранее написанных тест-кейсов. Без фреймворка управления оно невидимо для менеджеров и стейкхолдеров.

SBTM решает это, разделяя исследовательское тестирование на сессии — непрерывные блоки сфокусированного тестирования с определённым чартером, фиксированной длительностью и задокументированными результатами.

Структура сессии

Чартер

Каждая сессия начинается с чартера — формулировки миссии, определяющей что исследовать и какие риски изучать.

Тайм-бокс

Сессии имеют фиксированную длительность: Короткая: 45-60 минут, Обычная: 90 минут, Длинная: 120 минут.

Тайм-бокс создаёт срочность и фокус. Сессии должны быть непрерывными.

Лист сессии

ЛИСТ СЕССИИ
===========
Чартер: Исследовать оплату с истёкшими и отклонёнными
        картами для обнаружения пробелов в обработке ошибок.

Тестировщик: Иванова М.С.
Дата: 2026-03-19
Длительность: 90 мин (план), 85 мин (факт)

ЗАМЕТКИ:
- Истёкшая Visa: Показывает "Карта отклонена" корректно
- Истёкшая Mastercard: Общая ошибка — несогласованность
- Отклонённая карта: Нет конкретного сообщения, только "Попробуйте снова"
- После 3 неудачных попыток заказ отменяется без уведомления

БАГИ:
1. BUG-1234 (Высокий): Тихая отмена заказа после 3 сбоев оплаты
2. BUG-1235 (Средний): Несогласованные сообщения об ошибках
3. BUG-1236 (Средний): Сброс корзины при смене способа оплаты

ВОПРОСЫ:
- Лимит в 3 попытки — это по дизайну или баг?
- Должно ли приложение предлагать альтернативные способы оплаты?

% НА ЧАРТЕР: 75%
НЕПОКРЫТЫЕ ОБЛАСТИ: PayPal, Apple Pay, таймауты оплаты

Дебриф

После каждой сессии тестировщик встречается с лидом (10-15 минут) для обзора: что протестировано, что найдено, что не покрыто, что исследовать дальше.

Метрики SBTM

МетрикаОпределениеПрименение
Сессий завершеноКоличество проведённых сессийОтслеживание объёма
Багов на сессиюСреднее количество баговИзмерение эффективности
% on charterВремя на миссию чартераФокус vs. открытия
% на настройкуВремя на подготовкуВыявление проблем среды
Области покрытияИсследованные feature/областиЧто было протестировано
Оставшиеся рискиНевыполненные чартерыПробелы в тестировании

Интерпретация % On Charter

  • 90-100%: Очень сфокусированная сессия. Область хорошо понятна.
  • 60-80%: Нормально. Часть времени потрачена на неожиданные находки.
  • Ниже 50%: Либо в области много проблем, либо чартер слишком широкий.

SBTM на практике

Отчётность для стейкхолдеров

«В этом спринте мы завершили 5 исследовательских сессий, покрывающих оплату, поиск и мобильную вёрстку. Общее время: 6.5 часов. Найдено 8 багов (2 высоких, 4 средних, 2 низких). Покрытие: 3 из 5 запланированных областей. Риск: таймауты оплаты и интеграции с третьими сторонами остаются непротестированными.»

SBTM vs. Другие подходы

ПодходСтруктураПодотчётностьЛучше для
Ad hocНетНетБыстрые проверки
ИсследовательскоеТолько чартерНизкаяИндивидуальное исследование
SBTMЧартер + тайм-бокс + дебриф + метрикиВысокаяКомандное управление
СкриптовоеПолные тест-кейсыОчень высокаяРегрессия, compliance

Упражнение: Проведите сессию SBTM

Часть 1: Вы — лид тестирования приложения управления проектами. Спланируйте 3 сессии SBTM: чартер, тестировщик, длительность, приоритет, исследуемый риск.

Часть 2: Выберите один чартер и смоделируйте проведение сессии. Заполните полный лист сессии: минимум 10 наблюдений, минимум 2 бага, минимум 2 вопроса, % on charter, непокрытые области.

Часть 3: Напишите резюме дебрифа: ключевые находки, рекомендуемый чартер для следующей сессии, оценка риска функции.

ПодсказкаДля Части 1 подумайте о самых рискованных аспектах обновления доски задач: drag-and-drop, сохранение данных при перемещении, конкурентное редактирование, тач-жесты на мобильных, обновления в реальном времени.
Решение

Часть 1: План сессий

Сессия 1 (Высокий приоритет):

  • Чартер: Исследовать drag-and-drop задач между колонками с помощью быстрых перемещений, множественного выбора и одновременных редактирований чтобы обнаружить потерю данных, неверное состояние и race conditions.
  • Тестировщик: Иванова, 90 мин, Риск: Целостность данных

Сессия 2 (Высокий приоритет):

  • Чартер: Исследовать обновления доски в реальном времени с помощью двух браузеров на одной доске чтобы обнаружить сбои синхронизации и устаревшие данные.
  • Тестировщик: Петров, 90 мин, Риск: Консистентность между клиентами

Сессия 3 (Средний приоритет):

  • Чартер: Исследовать доску на мобильных устройствах с помощью тач-жестов и ротации чтобы обнаружить проблемы тач-таргетов и адаптивной вёрстки.
  • Тестировщик: Сидорова, 60 мин, Риск: Мобильная юзабилити

Часть 2: Лист сессии (Сессия 1)

Чартер: Drag-and-drop задач между колонками
Длительность: 90 мин (план) / 88 мин (факт)

ЗАМЕТКИ:
1. Drag одной задачи — работает корректно
2. Перестановка в одной колонке — сохраняется после обновления
3. Быстрый последовательный drag: второй иногда не срабатывает
4. Множественный выбор теряет относительный порядок
5. Drag во время редактирования другим пользователем — редактирование теряется
6. Drag в удалённую колонку — задача исчезает без ошибки
7. Undo работает однократно, двойной undo не восстанавливает
8. Drag 50 задач: UI зависает на 3 секунды
9. Длинное название задачи выходит за рамки при перетаскивании
10. Drag при задержке сети: задача возвращается без обратной связи

БАГИ:
1. BUG-501 (Критический): Задача исчезает при перетаскивании в одновременно удалённую колонку
2. BUG-502 (Высокий): Race condition — редактирование + drag вызывает потерю данных

% НА ЧАРТЕР: 80%
НЕПОКРЫТЫЕ ОБЛАСТИ: Drag клавиатурой, между досками

Часть 3: Резюме дебрифа

«Сессия drag-and-drop выявила критический баг потери данных: при перетаскивании задачи в одновременно удалённую другим пользователем колонку задача исчезает без ошибки и возможности восстановления. Базовый drag-and-drop для одного пользователя работает хорошо, но многопользовательские сценарии имеют значительные риски целостности данных. Рекомендация: исследовать операции удаления и разрешение конфликтов. Функция не готова к продакшну с открытым BUG-501.»

Ключевые выводы

  • SBTM делает исследовательское тестирование подотчётным через управляемые сессии
  • Листы сессий документируют что протестировано, что найдено и что осталось
  • Дебриф — важнейшая встреча, передающая знания и формирующая следующую сессию
  • Метрики (сессий завершено, багов на сессию, % on charter) обеспечивают отчётность
  • SBTM занимает оптимальную позицию между гибкостью исследования и подотчётностью скриптов
  • Планируйте сессии на основе риска — высокорисковые области в первую очередь