Home

Авторы: Мария Гуцук (Mariia Hutsuk), Шиваморти Бос (Sivamoorthy Bose)
Оригинал статьи
Перевод: Ольга Алифанова

Исследовательское тестирование – это подход к тестированию, при котором тестировщики динамически проектируют и выполняют тесты на основании своих знаний, исследования тест-объекта и результатов предыдущих тестов (согласно глоссарию ISTQB).

Исследовательское тестирование часто путают с ad-hoc тестированием, которое проводится по запросу без заранее составленных тест-кейсов, и манки-тестированием, которое заключается в рандомных действиях пользователя. Исследовательское тестирование – это изучение продукта путем небольших экспериментов и адаптация новых экспериментов в ходе тест-сессии. Этот тип тестирования отлично подходит для Agile– у него такая же логика, как и у Agile-экспериментов.

Преимущества исследовательского тестирования

Исследовательское тестирование ловит больше дефектов, чем автоматизированное.

Рассмотрим несколько метрик, демонстрирующих важность исследовательского тестирования.

• 33% сложных багов в приложениях найдены исследовательским путем.
• 29% багов интерфейса найдены исследовательским путем, а не через автоматизацию.
• Исследовательское тестирование выявляет на 11% больше дефектов, чем автоматизированное.
• Опишите модуль или функцию, на которой надо сконцентрироваться
• Опишите все инструменты, техники и конфигурацию.
• Цель: что будет исследоваться? (функция, модуль)
• Ресурсы: что нужно использовать? (инструменты, техники, конфигурация)
• Информация: что мы надеемся найти?

Источник : https://www.perforce.com/blog/alm/what-is-exploratory-testing

Исследовательское тестирование помогает создать более качественный продукт с повышенным тест-покрытием.

Исследовательское тестирование помогает делиться доменным знанием.

Исследовательское тестирование можно выполнять в парах, используя принципы парного программирования. Парное тестирование предполагает две роли – пилота и штурмана. Пилот – тот, кто у руля, он концентрируется на приложении, выполняет действия и задает вопросы по ходу их появления. Штурман находится на позиции наблюдателя и задает направление дальнейших проверок, а также делает заметки о шагах или находках. Эти роли могут время от времени меняться. Такой подход помогает не только найти баги, но и исследовать продукт и делиться знаниями с коллегой.

Исследовательское тестирование помогает переключить фокус внимания.

Человеческое внимание – интересный механизм. Фокусируясь на чем-то специфическом, мы не замечаем ничего находящегося вне фокуса. Даже многозадачные люди имеют всего один фокус – они просто очень быстро переключают внимание. Посмотрите видео, чтобы увидеть слепоту невнимания.

Искажение подтверждения – еще одна тенденция, связанная с вниманием и влияющая на тестирование. Оно происходит, когда вы обращаете внимания на факты, подтверждающие ваши убеждения. Поделюсь своим опытом столкновения с этим искажением. У нас было требование к цветовой схеме приложения, описывающее первичный и вторичный цвета, а также то, где их показывать. Мы почти упустили важный визуальный момент: белый текст был написан на светло-желтой кнопке.

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

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

В наше время вся индустрия обеспечения качества движется в сторону сдвига влево и утверждает процессы обеспечения качества. Фокусируясь на функциональном и автоматизированном тестировании, мы все еще находим пробелы в тест-покрытии. Каждый тестировщик должен быть способен заниматься исследовательским тестированием как минимум раз в неделю. Наши автотесты всегда чем-то ограничены. Автоматизированное регрессионное тестирование не способно в одиночку найти баги, затрагивающие все сценарии. Скрипты тестирования могут убедиться только в том, что указано в сценарии, и ловит только ожидаемые условия. Такие тесты могут быть частой сеткой, которая ловит пытающиеся пробраться сквозь нее баги, но откуда мы знаем, что эта сетка покрывает все возможные сценарии?

Исследовательское тестирование проверяет границы этой сетки и находит поведения, не охваченные скриптами.

Источник : https://martinfowler.com/bliki/ExploratoryTesting.html

Какие качества нужны тестировщику?

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

Гибкость. Отличные исследовательские тестировщики – компетентные тест-дизайнеры, умеющие проявлять изворотливость: если исследование определенной части ПО выдало ошибку, они должны уметь набросать новые тесты, ищущие связанные проблемы и недочеты. Исследовательский тестировщик, хорошо умеющий создавать импровизированные дополнительные тесты, может также определить масштаб бага, или как минимум описать пределы его влияния – в результате разработчику будет проще исправлять.

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

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

Отличные навыки коммуникации. Можно быть умным, пытливым и отлично искать баги, но толку от этого немного, если вы не можете передать свои находки разработчикам. В отсутствие тест-дизайнера, который вместе с менеджером продукта заранее определяет индивидуальные тест-шаги и ожидаемые результаты, тестировщики отвечают за объяснение идей для конкретного теста, его обстоятельств, и полученных результатов.

Как организовать сессию исследовательского тестирования

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

Приоритезируйте баги

В ходе тестирования каждый тестировщик знает кластер, содержащий максимум багов приложения. Приоритезируйте эти кластеры и начинайте с них свое исследование.

Включайте исследовательское тестирование в тест-план

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

Задайте временные рамки

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

Тест-чартеры

В книге "Exploreit!" Элизабет Хендриксон предлагает простой шаблон, который можно использовать для планирования масштаба исследовательских тест-сессий:

У Элизабет есть отличный пример, который мне особенно нравится:

"Исследовать редактирование профилей с разными методами авторизации с целью найти сюрпризы".

Тест-туры

Тест-туры – отличная альтернатива чартерам. В книге "Исследовательское тестирование" Джеймс А. Уиттакер предлагает концепцию тест-туров. Идея тут в том, чтобы сравнить ПО с городом. Тестировщик должен изучить город с разных точек зрения. Вы можете выбрать существующий тур или придумать свой собственный.

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

Персоны

Возможно, вы замечали, как тестировщики используют аргумент "Как пользователь, я ожидаю…" Во множестве случаев это вполне разумный оборот, и тестировщик действительно является пользователем тестируемой системы. У тестировщиков тоже есть банковские счета, они тоже бронируют полеты или заказывают еду. Но в ряде случаев мы не пользователи тестируемой системы. Мы можем проверять систему управления происшествиями для производства нефти, а большинство из нас никогда не работало на таком опасном производстве. Поэтому важно знать, кто наши конечные пользователи, и быть достаточно гибкими, чтобы поставить себя на их место. Персоны позволяют тестировщикам проверять приложение с новой точки зрения.

Персону можно описать, например, так:

"Дженет – 67-летняя пенсионерка, владеет собакой. Современные технологии не особо для нее важны – поэтому дома у нее медленное WiFi-соединение, легкий Android-планшет, и нет ноутбука. Протестируйте заказ товаров для собаки как Дженет – у нее много свободного времени, и хватает терпения на медленную связь".

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

Заключение

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

Обсудить в форуме