26 июня 2018

Как внедрить исследовательское тестирование в гибкий проект…

… и не пожалеть об этом

Тестировщик Noveo Анастасия вновь делится интересной и наталкивающей на размышления статьей о тестировании.

Exploratory testing translation by Noveo

Исследовательское тестирование (здесь ИТ, англ. exploratory testing, ET) — это метод ручного тестирования, целью которого является взаимодействие с приложением без детальной подготовки, основанное на знаниях и опыте. Специалисты часто сравнивают исследовательское тестирование со спортивными играми, где неизвестно, как противник отреагирует на ваше действие. Исследовательское тестирование работает как мощное дополнение, расширяющее формальное тестовое покрытие, и не требует дополнительного времени на разработку и написание тест-кейсов. Именно эта особенность исследовательского тестирования часто привлекает внимание менеджеров agile-проектов как разумный способ сэкономить время, деньги и внедрить тестирование в установленные проектом сроки. Но может ли исследовательское тестирование полностью заменить другие типы ручного и автоматизированного тестирования в проектах, работающих по гибкой методологии? Попробуем разобраться.

Исследовательское тестирование: 4 главных вопроса

Несмотря на кажущуюся понятность определения исследовательского тестирования, эту технику часто путают с так называемым интуитивным (англ. ad hoc) тестированием.

Ниже представлена диаграмма, сравнивающая интуитивное, исследовательское и сценарное (англ. formal) тестирование.

Критерии сравнения сводятся к четырем главным вопросам: Что?, Когда?, Зачем? и Кто?

Интуитивное тестирование Исследовательское тестирование Сценарное тестирование
ЧТО? Тестирование без подготовки:

  • наименее формальный подход;
  • результаты практически никогда не документируются.
Параллельное изучение продукта, составление и проведение тестов:

  • может быть неформальным или частично формализованным;
  • включает множество юз-кейсов, основанных на личном опыте тестировщика.
Вдумчивое тестирование с подготовкой, покрывающее функциональные и нефункциональные особенности продукта.
КОГДА? На любой стадии проекта вместо сценарного тестирования. Проводится в течение всего проекта как дополнение (или замена) сценарного тестирования. Часть каждой итерации разработки.
ЗАЧЕМ? Чтобы получить отзывы реальных пользователей (бета-тестирование). Чтобы оценить качество продукта в ходе выполнения разных юз-кейсов. Чтобы убедиться, что:

  • продукт работает соответственно ожиданиям;
  • команда поддерживает приемлемый уровень качества.
КТО? Любой заинтересованный человек, от обычного пользователя до QA-инженера. QA-инженер любого уровня. Чем выше уровень (и, как следствие, больше опыта), тем эффективнее будет тестирование. QA-инженер любого уровня.
Требования к тестировщику Базовое знание проекта.
  • Опыт работы в предметной области проекта;
  • непрерывная коммуникация внутри команды.
  • Знание предметной области проекта;
  • непрерывная коммуникация внутри команды.

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

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

Суммируя всё вышесказанное, можно подумать: “Окей, быть тестировщиком-исследователем не так уж и просто. Почему же этот метод считается быстрым, не требующим подготовки и подходящим любому QA-инженеру?”. Дело в том, что есть 2 вида исследовательского тестирования.

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

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

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

Отметим, что этот подход хорош для команд с 1-2 опытными тестировщиками. Большинство проектов требуют более структурированного подхода, который предоставляет нам другой вид исследовательского тестирования.

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

В этой технике процесс ИТ разделяется на несколько сессий, которые контролирует тест-лид (или тест-менеджер).

Тестирование проходит следующим образом:

  • тестировщики изучают проект и создают интеллектуальную карту (англ. mind map) или примерный план будущих сценариев;
  • тест-менеджер формирует требования, каждое из которых проверяется в рамках одной сессии. Сессия длится от 45 до 120 минут;
  • тестировщики проводят позитивные, негативные, пограничные и т.д. тесты, которые соответствуют одному требованию. Они могут незначительно отклоняться от требования по необходимости;
  • результаты тестирования предоставляются тест-менеджеру для ревью. Результаты могут быть использованы для написания сценарных тестов или обновления информации о проекте.

Что это нам даст?

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

Создается впечатление, что ИТ подходит для любого гибкого проекта. Получается, можно забыть про старое доброе сценарное тестирование и обращаться только к исследовательскому? Давайте сперва рассмотрим “за” и “против” такого радикального решения и его возможное влияние на проект.

ЗА ПРОТИВ
  • Моментально обнаруживает дефекты, что снижает стоимость их починки;
  • рождает идеи для новых тест-кейсов;
  • отлично подходит для проектов без четко описанных требований;
  • обеспечивает хорошую коммуникацию внутри команды и тестирование с оглядкой на мнение всех ее участников;
  • экономит время за счет отсутствия формализованной тестовой документации;
  • помогает тестировщикам фокусироваться на важном функционале.
  • Полностью опирается на опыт тестировщика и/или его знание проекта;
  • требует от тестировщика творческого, нестандартного мышления;
  • по сравнению со сценарным тестированием, процесс почти не контролируется.

Несмотря на то, что выгоды от внедрения ИТ перевешивают возможные негативные последствия, некоторые аргументы “против” могут перерасти в ошибки, из-за которых тестирование станет неэффективным.

Примеры ошибок:

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

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

Исследовательское тестирование: в поисках баланса

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

1. Стадии, когда лучше всего подключать ИТ:

  • создание и пересмотр требований кпроекту на ранних стадиях разработки;
  • тестирование позитивных, негативных и нестандартных сценариев для функционала, разработанного в рамках спринта;
  • расширение набора регрессионных тестов.

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

3. Общая специфика и сложность проекта. Эксперты советуют разумно подходить к выбору соотношения сценарного и исследовательского тестирования в зависимости от особенностей проекта. Здесь нет какого-то среднего соотношения, потому что каждый проект уникален. Например, для комплексной CRM-системы  процент сценарного тестирования будет 80-90 против 20-10 процентов ИТ соответственно. Для стартапа с частыми релизами, напротив, 80-90% времени стоит отдать исследовательскому тестированию.

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

Exploratory testing translation by Noveo

Оригинал: http://blog.qualitytesting.info/how-to-fit-exploratory-testing-into-an-agile-project-with-no-regrets/

Автор: http://www.qualitytesting.info/profile/IharIuliyeu

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Читайте в нашем блоге

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: