Skip to content

Latest commit

 

History

History
66 lines (45 loc) · 14.4 KB

issledovatelskoe-testirovanie-exploratory-testing.md

File metadata and controls

66 lines (45 loc) · 14.4 KB
Raw

Исследовательское тестирование (Exploratory testing)

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

Исследовательское тестирование (exploratory testing): Тестирование, основанное на опыте, при котором тестер спонтанно разрабатывает и выполняет тестирования на основе существующих соответствующих знаний тестера, предшествующих исследований элемента тестирования (включая и результаты предыдущих тестирований) и эвристических "эмпирических правил" для общего поведения программного обеспечения и типов отказа. Примечание - Исследовательское тестирование направлено на выявление скрытых свойств (включая и скрытое поведение), которые сами по себе, с одной стороны, вполне возможно, безобидны, но, с другой стороны, могут повлиять на другие свойства тестируемого программного обеспечения и тем увеличить риск того, что программное обеспечение перестанет работать. (ГОСТ 56920)

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

Джеймс Бах указал на важную характеристику исследовательского тестирования - тестировщик участвует когнитивно. Он активно, целенаправленно, с любопытством исследует тестируемое программное обеспечение, всегда принимая на себя ответственность каждую минуту решать, какой путь к тому, что он выбрал для исследования, является наиболее многообещающим. Нет никаких искусственных ограничений на разведку. Тестировщик может свободно использовать любые доступные источники информации, включая спецификации, записи службы технической поддержки, реализации сопоставимого программного обеспечения конкурентами и (конечно) эксперименты (тесты), которые эмпирически раскрывают информацию. Нет никаких ограничений на методы тестирования, которые могут использовать исследователи - например, любая степень автоматизации подойдет. Однако исследователь не просто перезапускает старые тесты, а тестирует чтобы учиться. Вероятно, он будет внимательно изучать поведение программы во время ее тестирования, ища новые идеи о том, как она может выйти из строя, как ее можно было бы в дальнейшем протестировать или измерить, и насколько полезны эти тесты на данном этапе разработки. Выполнение тестов можно автоматизировать, а мышление - нет. Антитезой исследования является тестирование по сценарию, в котором тестировщик (или машина) следует набору процедур, изложенных давно, сравнивая наблюдаемое поведение с любыми результатами, которые разработчик тестов считал актуальными или интересными в то время. Познание произошло тогда, а не сейчас. Объем исследования такой же, как и объем самого тестирования. Разница в том, что исследователь выполняет их в любой полезной последовательности, смешивая исследование, дизайн, выполнение, интерпретацию и общение, чтобы постоянно открывать новую информацию и идти в ногу с текущими изменениями на рынке, платформе, дизайне и реализации тестируемого программного обеспечения.

Подход к тестированию:

  • Используйте эвристики для управления тестированием;
  • Выполнение и создание тест-кейсов идут рука об руку;
  • Тест-кейсы продолжают развиваться на основе наблюдений и обучения тестировщиков;
  • К ET могут применяться различные методы тестирования, такие как анализ граничных значений, классы эквивалентности и т. д.;
  • ET можно использовать сессионно , чтобы сделать его более структурированным и сфокусированным;
  • Тестировщики могут развивать свои идеи, но никогда не отклоняться от своей миссии;
  • Тестирование ET не использует сценарии, а зависит от интуиции, навыков и опыта тестировщика;

Туры в исследовательском тестировании: Чтобы систематизировать исследовательское тестирование можно использовать идею туров. Туры - это идеи и инструкции по исследованию программного продукта, объединенные определенной общей темой или целью. Туры, как правило, ограничены по времени - длительность тестовой сессии не должна превышать 4 часа. Идею туров развивали в своих работах Канер, Бах, Хендриксон, Болтон, Кохл и другие. Джеймс Виттакер (James A. Whittaker), хоть и не придумал саму идею туров, но предложил свой подход к исследовательскому тестированию с использованием туров и в своей книге “Exploratory Software Testing” в доступной форме озвучил идею туров и описал сами туры.

Тур - это своего рода план тестирования, он отражает основные цели и задачи, на которых будет сконцентрировано внимание тестировщика во время сессии исследовательского тестирования. При этом Виттакер использует метафору, что тестировщик - это турист, а тестируемое приложение - это город. Обычно у туриста (тестировщика) мало времени, поэтому он выполняет конкретную задачу в рамках выбранного тура, ни на что другое не отвлекаясь. Город (ПО) разбит на районы: деловой центр, исторический район, район развлечений, туристический район, район отелей, неблагополучный район.

https://www.software-testing.by/wp-content/uploads/2015/09/328.png

Помимо туров существуют:

  • Session-Based Test Management (SBTM) или тестирование на основе сеансов (сессий) — метод контроля исследовательского тестирования, при котором процесс разбивается на периоды определенной длины (например, 90 минут). Ставим цель, включаем таймер и тестируем;

  • Thread-Based Test Management (TBTM) или тестирование на основе цепочек — метод контроля исследовательского тестирования, при котором возможности системы разбиваются на цепочки активностей, существующие для решения какой-либо задачи пользователя. Ограничений по времени нет, в этом случае цепочка - и есть само ограничение

Т.е. фактически при помощи SBTM и TBTM (или их сочетании) мы можем строить свои "туры", которые будут исходить в первую очередь из контекста тестируемой системы.

Источники:

Доп. материал: