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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

И чем оно отличается от тестирования по сценариям (сценарного тестирования)

Этот пост является переводом статьи Джеймса Баха What is Exploratory Testing? Это первый перевод из серии статей Баха про исследовательское тестирование и все, что с ним связано с сайта http://www.satisfice.com. Если вы нашли неточность в переводе или ошибку в терминологии прошу сообщить о ней в комментариях к статье.

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

Параллельное проектирование и выполнение тестов

Простейшее определение исследовательского тестирования — это разработка и выполнения тестов в одно и то же время. Что является противоположностью сценарного подхода (с его предопределенными процедурами тестирования, неважно ручными или автоматизированными). Исследовательские тесты, в отличие от сценарных тестов, не определены заранее и не выполняются в точном соответствии с планом. Звучит это просто, но на практике все весьма туманно. Это происходит из-за того, что «определенный» не означает что мы жестко фиксируем все и вся. Даже в том случае, если тщательно определены все тестовые сценарии, то работа с большим количеством интересных деталей (например, как быстро печатать на клавиатуре, или какие виды поведения программы признать ошибочными) остаются на усмотрение тестировщика. Кроме того, даже в свободной форме поисковой сессии тест будет включать в себя ограничения состоящие в том, какую часть продукта тестировать или какую стратегию использовать. Хороший исследовательский тестирировщик будет записывать идеи тестов и использовать их в последующих циклах испытаний. Такие заметки иногда очень похожи на сценарии тестирования, даже если они таковыми не являются. Исследовательское тестирование иногда путают с «ad hoc» тестированием. Ad hoc тестирование обычно относится к процессу импровизации, поиска ошибки экспромтом. По определению, любой может заниматься ad hoc тестированием. Термин «исследовательское тестирование» (придумал Cem Kaner, в книге Testing Computer Software) обозначает вдумчивый подход к ad hoc тестированию. За последние десять лет, Джеймс Уиттакер, Сем Канер и я работали для выявления навыков и техник позволяющих эффективно использовать исследовательское тестирование. Например, полностью определены и сформулированы процессы исследовательского тестирования, см. General Functionality and Stability Test Procedure for Microsoft’s Windows 2000 Compatibility Certification program.

Баланс между исследовательским и сценарным тестированием

Если каждый следующий тест, который мы выполняем, выбирается по результатам предыдущего теста, это означает, что мы используем исследовательское тестирование.Мы начинаем заниматься поисками и исследованиями, когда мы не можем сказать, какие тесты должны быть выполнены, или когда мы еще не имели возможности эти тесты создать, то есть мысль об их написании даже не приходила нам в голову. Если мы идем по сценариям, и на свет выплывает новая информация, которая предлагает нам лучшую стратегию тестирования, мы можем перейти к поисковому режиму (как и в случае обнаружения новой ошибки, которая требует подробного рассмотрения). С другой стороны, мы больше следуем сценарному подходу, когда 1) неопределенность в том, как мы хотим проверить, мала 2) новые тесты относительно неважны, 3) необходимость обеспечения эффективности и надежности в выполнении этих тестов стоит усилий по работе с подобными тестами, 4)мы готовы платить за написание и поддержание тестов.

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

Зачем проводить исследовательское тестирование?

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

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

Источник

• ← Циркадные ритмы что это
• что такое отсутствует инвойс →