Home

Автор: Оксана Разина

Оригинальная публикация: http://quality-lab.ru/misconceptions-of-exploratory-testing/

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

Именно поэтому наиболее удачным решением может оказаться выбор исследовательского тестирования в моно-варианте. Поскольку сам термин «исследование» подразумевает индивидуальную заинтересованность и вовлеченность в процесс, мы все сразу же задумываемся о подводных камнях данного подхода.

Конечно, говоря о тестировании, нельзя не упомянуть распространенные ошибки самих тестировщиков. Есть такой психологический момент: если не обозначены рамки, то начинает казаться, что можно делать всё, что угодно. И этот процесс будет называться тестированием. Многие начинающие тестировщики совершенно необоснованно думают, что «исследовательское» тестирование позволяет не соблюдать основные принципы тестирования.

Заказчики и их заблуждения

Исследовательское тестирование не контролируемо и не управляемо

Представим, что задание на тестирование получено. Мы радостно потираем руки в предвкушении интересной динамичной деятельности, и тут приходит менеджер и говорит: «Ребят, да вы что, с меня голову снимут за ваши эксперименты! А как мы отчитаемся по покрытию функционала тестами? А как вы время оцените?». Резонные опасения, не правда ли? Так мы узнаём, что нашему менеджеру не хватает уверенности в том, что мы сможем грамотно выстроить процесс тестирования и представить его результаты в надлежащем виде.

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

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

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

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

В ряде случаев это может быть действительно так. Однако, если участников тестирования больше одного, с таким подходом можно и поспорить. В качестве примера расскажу случай из практики. К нам поступила срочная и неожиданная заявка на тестирование нового проекта — это была CMS (админка) для одного приложения. В качестве ресурсов у нас был один опытный тестировщик и один стажер. Мы решили сделать план админки и детализировать его с учетом предположений опытного тестировщика.

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

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

• использование чит-листов;
• сессионное тестирование;
• парное тестирование;
• тест-туры Джеймса Виттакера (James A. Whittaker).

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

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

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

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

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

Тестировщики и их заблуждения

Исследование продукта с целью дальнейшего написания тестов — это и есть исследовательское тестирование

Многие скажут, что это утверждение верно, и будут по-своему правы, ведь исследование проводится и в том, и в другом случае. Я же думаю, что имеет смысл разделять понятия «тестирование» и «тест-анализ».

По сути, готовясь к написанию тестов, мы действительно проводим исследование: выполняем анализ имеющейся документации, продумываем стратегию, расставляем приоритеты — то есть, определяем, ЧТО и КАК будем тестировать.

Если говорить об исследовательском тестировании, то конечной целью этого процесса является ответ на вопрос: «Насколько наш продукт соответствует этим ожиданиям?» Да, мы тоже проектируем тесты на ходу, но это лишь часть глобального процесса. Разные цели — разный результат, так что не совсем уместно называть исследовательским тестированием только подготовку к написанию тестов.

Исследовательское тестирование базируется на идее беспорядочного выполнения различных действий

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

Для исследовательского тестирования не нужна предварительная подготовка

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

Необязательно своевременно актуализировать статус проверок

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

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

А напоследок я скажу…

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

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