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

• Определение
• Характеристика
• Когда используют
• Подходы
• Преимущества
• Минусы
• На что опираются при проведении
  • Догадки
  • Диаграммы и use-кейсы
  • Ранее замеченные дефекты
  • Сообщения об ошибках
  • Обсуждения
  • Чеклисты
• Типы исследовательского тестирования
  • Свободное
  • По сценариям
  • На основе стратегии
• Когда команда работает по Agile
  • Чем удобно
• Чем исследовательское отличается от стандартного
• Чем отличается от ad-hoc
• Сферы применения
• Что могут спросить на собеседовании об exploratory testing

Определение 

Суть такого тестирования заключается в исследовании программы, то есть в изучении ее поведения. Тестировщик сам решает, что делать, когда, в каком объеме, и в каком порядке. Обычно проводится при нехватке времени, а также когда требования заказчика недостаточно ясно и полно сформулированы. Исследовательское тестирование часто сочетают с другими методиками, дополняя их.

Характеристика

• Ориентированный на практику метод тестирования: больше интуиции — меньше подготовки; больше опоры на опыт — меньше документов/артефактов
• При этом применение формализированных документов не исключается; может быть создан план исследовательского тестирования — короткое описание действий во время предстоящей 1-2-часовой тестовой сессии, описываются цели, подходы и методики
• Обычно же планирование действий и сами действия идут параллельно; все происходит интуитивно, «по ситуации». Не создаются тест-кейсы и сценарии. К примеру, тестировщик может вручную, «на лету» проверить несколько критически важных граничных значений, не фиксируя свои действия, просто чтобы оценить результаты. Обычно фиксируются только замечания «на будущее», возникающие в процессе, и баги-критикалы.
• После завершения тестовой сессии может быть создан отчет с описанием проверенных частей/функций приложения, какие дефекты замечены, и соображения насчет улучшения продукта сейчас или в будущем
• Исследовательское дополняет формализованные формы тестирования. В руках опытных тестировщиков является еще одним, достаточно мощным способом проверки полноты и точности формальных методик, особенно что касается критических точек приложения.
• В «библиях тестирования» (авторитетных учебниках Канера, Коупленда, Уитекера) исследовательскому тестированию уделено большое внимание; описываются специальные формы такого тестирования, «атаки на приложение».

Когда используют

• Полезно на начальных этапах цикла разработки, когда в код часто вносятся изменения
• Достаточно часто применяется в юнит-тестировании; а также чтобы «вкратце ознакомить» QA-команду/лида с приложением
• Для подготовки к созданию тестовых сценариев и тест-кейсов
• В Agile-разработке, при коротких скрам-циклах, когда особо нет времени на создание «больших хороших» тестовых сценариев и сьютов. Хорошо подходит для Agile поскольку может дать вполне приемлемый уровень проверки за очень короткое время
• Идеи сценариев создаются в процессе, при неформальном, «почти пользовательском» подходе к приложению
• Исследовательское тестирование критически важных узлов приложения часто проводится в конце каждого скрам-цикла и служит источником совершенствований в следующих циклах

Подходы

• Тестировщик действует, полагаясь на свой опыт, накопленный за годы работы, свою интуицию, свое понимание проблем, которые бывают/могут быть в подобных приложениях.
• Планирование тестовых операций идет в процессе их проведения (параллельно).
• Количество ручных интуитивных тест-кейсов растет по ходу сеанса, и на основе первых полученных впечатлений.
• Тестировщик подытоживает увиденное и проверенное, в виде более стандартизованного репорта или менее формального отчета, даже устного
• В процессе вовсе не исключается применение формальных методик — эквивалентных классов и граничных значений, предугадывания ошибок, таблицы решений, попарного тестирования и других.
• Тестировщик включает свой опыт, интуицию и здравый смысл, пытаясь найти дефекты, в ситуациях когда бессильно самое лучшее современное AI-enhanced автоматизированное тестирование
• Подобное исследование программы может включать и автоматизированные действия
• Короткие тестовые сессии (1-2 часа), поскольку исследовательское тестирование — занятие трудное (хотя и интересное)

Преимущества

• Минимальная подготовка к проведению и быстро находятся баги
• Развивает «исследовательское мышление» и быстроту операций, прокачивает опыт
• В результате чего в будущих более стандартных проектах тестировщик работает эффективнее
• Контроль качества работы других тестировщиков в команде
• Контроль качества стандартных, формальных тест-кейсов
• Быстрая оценка новой функциональности

Минусы

• Произвольный порядок проверки не позволяет действовать продумано и спланировано
• Упор на опыт и знания о продукте, что применимо не ко всем участникам команды
• Внимательное изучение продукта в любом случае занимает какое-то время

На что опираются при проведении

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

• Надеется купить карту по приезде
• Кружит по окрестностям, пытаясь найти нужный дом наудачу
• Спросит у прохожего
• Поедет в центр города, где много людей, и спросит там

Так же и exploratory testing. Допустим, QA-команде дали задачу протестировать компьютерную систему управления больницей. Скорее всего будут применяться следующие техники:

Догадки

Да, догадки. Можно угадать области продукта, в которых, скорее всего, будет много дефектов. Имея опыт с подобными продуктами, это бывает не так уж сложно. 

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

Диаграммы и use-кейсы

Могут помочь схемы архитектуры (диаграммы или просто рисунки), наглядно изображающие связи между компонентами системы. А use-кейсы помогут «пройти по пути» с точки зрения пользователя.

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

Ранее замеченные дефекты

Опыт решения проблем, замеченных в других продуктах и прошлых версиях этого продукта, поможет предугадать модули, в которых, скорее всего, будет много дефектов.

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

Сообщения об ошибках

Главный источник информации о причинах ошибок. 

Также особое внимание при исследовательском тестировании уделяется проверке правильности обработки ошибок, как одной из базовых функций ИТ-системы.

Например модуль регистрации пациентов не только подвисает и выдает ошибки, но эти сообщения зачастую неполны или не соответствуют случившемуся; такую ситуацию исправляют.

Обсуждения

Примерный план действий можно сформулировать по крайней мере в устной форме, почерпнув кое-что из обсуждений с коллегами на митингах и созвонах.

Чеклисты

Вопросы «Что, когда, как, кто и зачем» — задает себе тестировщик, приступая к исследованию, и готовит чек-лист важных проверок.

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

Свободное

Продукт исследуется спонтанно, не стараясь соблюдать стандарты. Проводится обычно:

• Когда нужно очень быстро войти в курс дела в проекте
• Когда нужно быстро проверить качество работы других (или подчиненных) тестировщиков
• Когда другими методами никак не удается найти проблему
• Когда нужно вручную быстро завершить дымовое тестирование

По сценариям

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

По стратегии

Дополнительно к собственно исследованию продукта — применяют техники таблицы решений, причин/следствий, и предугадывания ошибок. 

Когда команда работает по Agile

В Agile используются короткие спринты (около месяца или меньше), и из-за нехватки времени, и требования быстрых результатов «уже сейчас», тестировщики вынуждены выполнять исследовательское тестирование, часто сразу после получения критериев приемки. Далее, изучив функциональность и слабые места приложения, можно создавать формальные тест-кейсы. 

Хотя такое тестирование изначально имеет «свободную природу» и это Agile, тестировщикам все равно приходится создавать формальные репорты по проверенным объектам, обнаруженным дефектам и проблемам, в том числе для того чтобы упростить операции в будущем.

Чем удобно

• Немедленный фидбек в процессе
• Опытный тестировщик может найти множество дефектов
• Тестированием могут заниматься разработчики, дизайнеры и бизнес-аналитики
• Быстрая оценка обновленных требований

Чем исследовательское отличается от стандартного

Чем отличается от ad-hoc

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

Сферы применения

Достаточно часто опытным участникам QA-команды ставят задачу проверить ИТ-систему исследовательским тестированием, особенно в таких сферах как медицина, телекоммуникации и финансы.

Что могут спросить на собеседовании об exploratory testing

• Описать суть методики и применение
• Привести пример, как можно протестировать условную систему, названную интервьюером
• План действий
• Какие плюсы и минусы методики
• Чем отличается от других похожих методик
• Отличия от стандартного (автоматизированного) тестирования

***

Источник