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

Определение 

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

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

  • Ориентированный на практику метод тестирования: больше интуиции — меньше подготовки; больше опоры на опыт — меньше документов/артефактов
  • При этом применение формализированных документов не исключается; может быть создан план исследовательского тестирования — короткое описание действий во время предстоящей 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

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

***

Источник

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

Подписаться
Уведомить о
guest

0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

🔥 Популярное

💬 Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас