Тренинг: Exploratory Testing


Целевая аудитория

Тестировщики, менеджеры по тестированию, лидеры команд.

Описание тренинга

Путем многих проб и ошибок мы пришли к гибким методологиям разработки, основная цель которых – выпускать работающую версию продукта как можно чаще. Это потребовало пересмотреть все аспекты разработки программного обеспечения. Инженерные практики играют первостепенную роль в этой трансформации. Это и TDD, и парное программирование, и самое основное – Continuous Integration.
Но что мы знаем о тестировании? Да, это модульные тесты и остальные типы низкоуровневых тестов. Да, это приемочные тесты, которые выполняются на уровне UI и являются зеркальным отражением скриптов мануальных тестировщиков. Это также набор регрессионных тестов, которые могут быть частично или полностью автоматизированы. А что делать с теми тестами, которые нельзя автоматизировать? Или разработка которых очень затратна по времени? Или пока что не понятно, нужно ли вообще это автоматизировать? Как можно быть уверенным что все работает в этом случае?
Ответ очевиден – нужно тестировать вручную. И что дальше?
Услышав это, происходит два варианта:
  • Мы возвращаемся к нашему прошлому опыту, который подсказывает: «бери шаблон, пиши тест план, проводи тест дизайн, пиши тест кейсы, жди пока разработчики напишут новую версию, тестируй». После первой итерации становится понятным, что так дело не пойдет и это напоминает старый добрыйWaterfall. Такая манера тестирования не сходится сразу с двумя из заповедей «Working software over comprehensive documentation» и «People and individuals over the processes and tools».
  • Происходят попытки перестроиться на «гибкое тестирование», но обычно все сводится к «я протестировал это, кажется работает, но вот нашел две баги». Этот подход не противоречит Agile манифесту, но не дает четкого понимания и полной картины тестирования на проекте.
Из двух примеров явно вырисовывается Scripted Testing (скриптовое тестирование) и Ad hoc(неформальное тестирование). Оба подхода проблемные и часто не дают от тестирования ожидаемого результата. Тестировщики на таких проектах обычно живут в хаосе, так как не успевают закончить тестирование, или же не могут четко озвучить статус работы.
Истина, как обычно, где-то посередине. Exploratory Testing (исследовательское тестирование) возникло не просто так. Первым об этом писал Cem Kaner в его библии для тестировщика. Далее эта тема обрела развитие в лицах Майкла Болтона, Джеймса Баха и других, которые создали основу для Context-Driven School, целью которой было популяризация нового подхода к тестированию.
На своем пути они столкнулись с многими проблемами. В большинстве случаев, когда люди слышали об Exploratory Testing, воспринимали как «понятно, ну не будем писать тест-кейсы, будем работать по чеклисту». И скриптовый подход к тестированию начинает превращаться все в тот же Ad hoc хаос, где нет четкого понимания, что и как должно быть протестировано, нет целей, нет плана. Основные заблуждения, относящиеся к исследовательскому тестированию исходят от непонимания того, что такое тестирование в целом. Exploratory Testing – это не просто Ad hoc тестирование, а отдельный подход к тестированию, который требует дополнительного изучения.
Тренинг создан для того, чтобы помочь тестировщикам разного уровня освоить этот подход к тестированию и успешно применить его в своей практике.

Цели тренинга

  • Показать участникам альтернативную точку зрения на тестирование ПО
  • Научить правильно понимать концепцию, лежащую в основе исследовательского тестирования
  • Научить организовать работу таким образом, чтобы она не просто нравилась, а еще и приносила пользу проекту
  • Научить работать по принципам Exploratory Testing на практике
  • Поделиться опытом использования подхода на успешных проектах

Детальная программа

День 1:
  • Скриптовый подход к тестированию
    • В традиционных проектах
    • В Agile проектах
    • Плюсы и основные заблуждения подхода
    • Минусы подхода
  • Дискуссия: Что такое Exploratory Testing?
  • Что не есть Exploratory Testing?
    • Туры
    • Тестирование в конце итерации
    • Инструменты?
    • Быстрые проверки
    • Документация
  • Что такое Exploratory Testing?
  • Практика: Задание по обучению динамике exploratory testing
  • Практика: Определения стиля тестировщика (LISA)
  • Фокусирование/расфокусирование
  • Тестовые оракулы
  • Практика: Задание на отработку принципа фокусирования
  • Вспомогательная модель Exploratory Testing
    • Модели покрытия
    • Информационные источники
    • Вспомогательные материалы
    • Техники
    • Навыки
    • Отчетность
  • Туры
  • Практика: Тестирование с использованием туров
  • Эвристики
  • Практика: Создание собственной эвристики
  • Мыльные оперы
  • Практика: Применение мыльной оперы в тестировании
  • Серия практических заданий на оттачивание работы в паре
  • Обсуждение ситуаций во время парного тестирования
  • Отчетность
    • Правила дебрифинга – PROOF
    • Полезные эвристики для составления отчетов
  • Подведение итогов первого дня
День 2:
  • Практика: Подготовка функциональной карты приложения
  • Практика: Подготовка Testing Dashboard и распределение задач на тестирование
  • Практика: Подготовка отчета и подсчет метрик
  • Практика: Debrief сессия
  • Что такое Sessions based тестирование?
  • Что такое Thread based тестирование?
  • Уроки из опыта
    • Что это и какие проблемы решает подход Exploratory Testing?
    • Когда стоит применять, а когда не стоит?
    • Как совмещать Exploratory и Scripted подходы?
  • Какими навыками должен обладать тестировщик?
  • Какие инструменты призваны помочь тестировщику?
  • Истории из опыта по применению Exploratory Testing на проектах
  • Подведения итогов второго дня
  • Рекомендации для дальнейшего освоения материала

Продолжительность

16 часов (2 дня).