Exploratory testing что это
Тестирование методом свободного поиска: Отказ от плана не значит отказ от цели
В статьях Джеймса Баха можно встретить несколько различных определений того, что такое тестирование методом свободного поиска (exploratory testing), и одно из них звучит так: «тестирование без заранее подготовленных сценариев, выполняемых в точным соответствием с планом» (Exploratory tests, unlike scripted tests, are not defined in advance and carried out precisely according to plan).
За это тестирование методом свободного поиска часто подвергается критике — как можно отказаться от планов, а как же управляемость, контроль и учёт? И вообще, если не будет планов, тогда каждый будет делать кто во что горазд, что-то будет протестировано несколько раз, что-то вообще не будет протестировано, люди не будут знать, что им делать.
Но в действительности сторонники тестирования методом свободного поиска вовсе не призывают к анархии. Напротив, огромное количество статей Джеймса Баха посвящено планированию.
Кажущееся противоречие разрешается очень просто — сторонники этого подхода к тестированию предлагают отказаться от тактического планирования, от излишней детализации планов до уровня отдельных тестов. И заменить тактический план постановкой цели, оставив тестировщику свободу в выборе способов достижения этой цели.
Тестировщик, имея перед собой ясную цель, может, конечно, наметить себе некоторый план, который должен его привести к этой цели. Но если на его пути встретятся какие-то препятствия, или он заметит, что выбранный план уводит в сторону, или следуя этому плану он не достигнет цели к поставленному сроку — это повод для того, чтобы изменить план, а не пытаться «подправить цель».
Исследовательское тестирование: пустая трата времени или мощный инструмент?
Одни считают, что исследовательское тестирование более продуктивное, чем привычное нам тестирование по сценариям. Другие — что это пустая трата времени и ресурсов. Так ли это на самом деле?
Исследовательское тестирование это:
Это метод ручного тестирования, который базируется на взаимодействии с приложением без детальной подготовки, основанное на знаниях и опыте тестировщика, из-за чего его квалификация может серьезно повлиять на результат.
Три вида тестирования, которые не стоит путать
По формальности документирования выделяют три вида тестирования:
Под ad-hoc тестированием понимают тестирование без использования спецификаций, планов и разработанных тест-кейсов — здесь преимущественно чистая импровизация. В таком виде тестирования полностью отсутствует предварительная подготовка, происходит наиболее достоверная имитация случайного пользователя.
Исследовательское тестирование — более формальная версия ad-hoc: тестирование, не требует написания тест-кейсов без необходимости, но подразумевает, что каждый последующий шаг(тест) выбирается на основании результата предыдущего шага(теста). А по Сэму Канеру, «Testing Computer Software», «исследовательское тестирование» — вдумчивый подход к ad-hoc тестированию.
Сценарное тестирование является классическим тестированием по предварительно написанным и задокументированным сценариям. Оно требует наибольшей степени формальности и детализации документирования, что затрачивает гораздо больше сил тестировщика и его времени, однако наиболее подходит для ведения отчетности, статистики и т.п.
Общие сведения
Исследовательское тестирование можно понимать как подход или саму идею, которой придерживается специалист в процессе. Исследовательское тестирование подразумевает под собой одновременное изучение проекта и его функционала, создание тест-кейсов в уме и их исполнение, не записывая и не создавая тестовую документацию без необходимости.
Такой вид тестирования может не предусматриваться в тест плане, а тест-кейсы выполняются и модифицируются динамически. Эффективность такого тестирования напрямую зависит от опыта тестировщика ранее имевшим дело с этим приложением, платформой, знанием мест скопления возможных багов и рисками которые относятся к конкретному продукту. Тестировщики могут успешно применять исследовательский подход и при разработке новых тестов в начале итерации, и при анализе уже завершенных тестов, и даже как вариант дымового тестирования, избегая лишних затрат времени.
Рассмотрим преимущества и недостатки исследовательского тестирования
Преимущества исследовательского похода
Недостатки исследовательского подхода
В каких же случаях стоит применять исследовательское тестирование?
— В запасе имеется довольно много времени после регресса
Бывает, конечно, зачастую не так часто, вы успеваете в срок и остается некоторое количество времени, и чтобы убедиться, что вы внимательно прошлись по всем тест-кейсам, что ничего не упустили, применяют исследовательское тестирование.
— Одни и те же тест-кейсы на регрессе
Количество имеющихся тест-кейсов на проекте зачастую довольно велико. Еженедельные прохождения по одним и тем же тест-кейсам приводят к тому, что глаз замыливается, и вследствие этого баги пробираются на прод. Когда же мы идем не по шагам и в голове не держим, что нам осталось еще пройти пару сотен кейсов – это помогает взглянуть на проект с несколько другой стороны.
Функционал нашего приложения не очень большой, поэтому можно смело использовать исследовательское тестирование. Но стоит помнить и об обратной стороне — проект расширяется, количество коллег в команде растет и документация в скором времени просто будет необходима. Даже если сроки «горят», закладывайте время на составление документации.
Как было сказано выше, кейсов на проекте может быть очень большое количество и иногда, из-за горящих сроков, команда просто не успевает актуализировать тест-кейсы. Либо вы пришли на проект и там просто нет документации.
В каких же случаях не стоит применять одно только исследовательское тестирование?
Клиенту важно знать, что было проверено, ему необходим отчет о тестировании. В данном случае составляются чек-листы и тест-кейсы.
— На проекте есть автоматизация
Приложение покрывается автотестами, тут тест-кейсы просто необходимы.
Что такое исследовательское тестирование?
И чем оно отличается от тестирования по сценариям (сценарного тестирования)
Этот пост является переводом статьи Джеймса Баха 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 обычно используют оба подхода в одном проекте. Тем не менее есть много важных различий между двумя подходами.
Зачем проводить исследовательское тестирование?
Наиболее обсуждаемыми темами в управлении эффективным исследовательский циклом тестирования являются тестировщик, стратегии тестирования и отчетность. Сценарный подход к тестированию является попыткой механизировать процесс тестирования, когда берется идея из головы тест-дизайнера и излагается на бумаге. Подобный способ тестирования очень полезен. Но тестировщики, использующие исследовательский подход, придерживаются мнения, что запись тестовых сценариев и следование им «отупляет» тестировщика, мешая ему быстро находить ключевые проблемы. Чем более интеллектуальным мы можем сделать тестирование, тем больше шансов у нас будет, что мы протестируем приложение правильно и успеем сделать это вовремя. В этом и заключается мощь исследовательского тестирования: богатство этого процесса ограничивается только широтой и глубиной нашей фантазии, а также нашим пониманием природы тестируемого приложения.
Сценарное тестирование занимают свою нишу. Я могу себе представить ситуации в тестировании, когда эффективность и воспроизводимость настолько важны, что мы должны написать сценарии для них или их автоматизировать. Например, в случае, когда тестовая платформа регулярно бывает недоступна, как в случае клиент-серверных приложений, в которых есть только несколько настроенных серверов и они должны быть разделены между командами разработки и тестирования. Здравый смысл подсказывает нам, что мы должны заранее тщательно проработать сценарий тестов, чтобы получить максимальную отдачу во время выполнения тестов в выделенное нам время. Исследовательское тестирование особенно полезно в сложных ситуациях тестирования, когда мало что известно о продукте, или как часть подготовки набора сценариев тестов. Основное правило заключается в следующем: исследовательское тестирование используется в тех случаях, когда выполнение следующего теста неочевидно, или когда вы хотите выйти за рамки очевидного. По моему опыту, это происходит в большинстве случаев.
Exploratory Testing: что это такое и как его использовать
Long story short: прежде чем заняться тестированием, я проектировал дома и сооружения. Знаю, как быстро посчитать момент сопротивления, и понимаю, зачем это делать. Запроектировал кучу мелких деталей и даже один большой жилой дом в Киеве и часть аэропорта в Борисполе.
Работа инженера по качеству на какой-то процент состоит из Exploratory Testing. Оказывается, что это эффективный инструмент, хотя четкого значения этого термина быстро я найти не смог. Мое понимание Exploratory Testing сформировалось скорее через собственные представление и бэкграунд, поэтому аналогии будут связаны со строительством и архитектурой.
Эта статья о том, почему все еще нужно что-то исследовать и как инженеру по качеству объяснив подходы к Exploratory Testing другим участникам разработки.
Иллюстрация Алины Самолюк
Что такое Exploratory Testing
Буквально выходит «исследование». Важно в профессиональном исследовании то, чтобы его процесс и результаты были интересны кому-то, кроме исследователя. Кто-то — это, скажем прямо, человек, владеющий бюджетом на разработку и тестирование.
Реальный пример. Есть компания N, которая выпускает на рынок новый сервис в рамках своей платформы. Скажем, можно было арендовать номер, а теперь и взять в аренду авто. Новое решение — отдельное мобильное приложение, но хранит данные о пользователе и настройки для всех приложений. Новое приложение пока не поддерживает Apple Pay, поэтому сбрасывает настройку на ближайшую доступную — Cash. Это потенциально приводит пользователя, который арендует номер, в ситуацию, когда он просто открыл приложение по прокату авто, и теперь должен искать наличные для оплаты номера, хотя он был уверен, что уже оплатил, потому что он знает, что у него настроен Apple Pay.
В явном виде требования, где говорилось бы, что новое приложение не должно сломать кейсы существующих пользователей, скорее всего, не будет. Для бизнеса это очевидно. Автотесты и функциональное тестирование не находят такой ошибки, потому что она предполагает сильное изменение среды, о котором нет упоминаний.
У тестировщика есть шансы найти такую ошибку, если он проведет сессию Exploratory Testing, которая как раз и выведет его за явную спецификацию в недокументированные требования. Обнаружив такую ошибку, QA кажется, что всем должно быть очевидно, что исследования нужны, и он хочет добавить их в процесс.
Плохой пример: мы как QA приходим к заказчику/стейкхолдеру и говорим: «Тикеты в джире, конечно, это хорошо, но я бы исследованием занялся». Стейкхолдеру не очевидно, зачем это. Более того, ему не очевидно, зачем заниматься прохождением тест-кейсов и заведением тикетов. Зато с тикетами это хоть понятная и устоявшаяся модель работы. Все так делают, и вроде результаты дает.
И это плохой пример того, как начать исследовать. Ведь, скорее всего, компания предпочтет остаться при тест-кейсах. Стейкхолдер не пойдет интересоваться, как прошло исследование, потому что он ничего об этом не знает. Ему кажется, что ошибки находятся сами собой в пределах тех артефактов, которые есть (например, тест-кейсов).
Хороший пример: говорим стейкхолдеру, какой приблизительно процент продукта исследовали, что нашли две очень большие проблемы, которые мешают решить задачу X пользователя. «Если бы мы проходили сценарии, у нас не было бы шансов их найти. Давайте теперь формализуем исследование в явном виде и запланируем время и формат». Показываем артефакты от сессии исследования, например записи и вопросы-проблемы, которые были обнаружены в процессе.
Желательно, чтобы длина сессии была небольшой, а вопросы в той плоскости, которая волнует стейкхолдера — о том, что заблокирует выпуск продукта или сильно снизит репутацию. Тогда компании уже интереснее в явном виде проводить исследования, потому что в его результатах есть артефакты, которые дают возможность делать выводы и принимать решения.
Есть и другие, более экстремальные подходы. Например, Session Based Test Management, его автор — James Bach, кажется, он вообще единственный, кто говорит о тестировании не в ключе технологий. Честно говоря, я слабо себе представляю, как такое внедрить в среднестатистической компании. Для компаний любые подходы, особенно не практикуемые в соседней аналогичной компании, — это сплошные знаки вопроса.
Scrum или другой Agile-метод так популярен не потому, что он хорош, а потому, что предсказуем. Скажем, существует подход, который комплексно решает проблему наличия регрессий в продакшн-энвайронменте, но всем участникам процесса не совсем понятно, в чем он состоит. Тогда все останутся добавлять тест-кейс скорее на найденный баг, чем на пересмотр процесса. Sad but true, нужно быть очень известным или оказаться в компании, готовой на большие эксперименты, чтобы внедрять нетипичные вещи.
Аналогии
Итак, если бы это был город, роли и обязанности делились бы как-то так (с некоторыми упрощениями в разработке программных решений):
С последним часто не так. QA Engineers становятся чем-то вроде контролирующей организации, которая отвечает за качество работы строителей. В свою очередь, AQA Engineers являются теми, кто это будет контролировать через установку систем видеонаблюдения. Ни те, ни другие не могут оценить, а решилась ли изначальная задача жителей, в чем она состояла и зачем этот новый бордюр. Сказали, что должен быть — проверяем, что есть.
Нужен ли был бордюр жителю, который собирается ходить в парк с детской коляской, — как-то этот вопрос пропустили и сфокусировались на своем решении. Даже сослались на норму установки бордюров, не сопоставив ее с реальной ситуацией. В итоге бордюр сделан хорошо, но никак не помогает проехать человеку с коляской.
Всегда есть задача X
Но не всегда понятно, в чем она состоит. Скажем, мы ищем ошибки в физических сценариях похода пользователя на киевский велотрек из района метро «Золотые ворота».
Ожидаемый флоу приблизительно такой: пользователь идет на киевский велотрек в выходной день и по дороге планирует зайти перекусить. Вот так мы себе представляем возможные сценарии.
Расставляем их по приоритету. Например, выбираем наиболее приоритетным самый короткий путь. Находим ошибку в том, что по пути пришлось переходить на другую сторону дороги. Другая ошибка — из-за очереди в McDonald’s перформанс был ниже ожидаемого.
У задачи X всегда есть ситуация
Может ли так выйти, что, пройдя предыдущие кейсы, исправив ошибки, мы не сделали опыт лучше? Конечно, это частый случай, потому что мы не выяснили всех обстоятельств.
После выяснения этих обстоятельств окажется, что ошибки, которые мы обнаружили ранее, не имеют никакого значения. Это не отменяет того факта, что они существуют. Просто они вне нашей ситуации. Потому что выяснилось: «Золотые ворота» вообще не там, где мы их нашли с помощью Google Maps, пользователь живет в этом районе и привык ходить через двор, а там поставили забор и сломали его базовый сценарий. И в целом событие происходит до реконструкции трека, а пользователь — активист, занимающийся реконструкцией. Можно сказать, активный бета-пользователь.
Выходит, что ошибки, которые мы нашли ранее, вообще не имеют отношения к конечному юзкейсу. А имплементация уже слишком далеко, чтобы ее развернуть. Поэтому нанимаем еще кассиров в McDonalds, чтобы решить проблему перформанса, и ставим еще один забор, чтобы нельзя было пройти через двор.
Какое это имеет отношение к разработке
Как бы нам не хотелось называть свою деятельность IT-сферой, ее не существует. Мы просто решаем проблемы других людей с помощью софта, и наши исследования и подходы ничем не отличаются от любой другой деятельности, кроме простоты внесения изменений. По сути, вопросы, которые стоит задать до исследования, открывают неописанные требования.
Реальный пример: интеграция 3rd party library в решение. Описанные требования (условно упрощены):
Неописанные требования (слишком очевидные):
В каждом из неописанных требований нашлась минимум одна ошибка, которую невозможно было бы обнаружить, имея только тест-кейсы, которые относятся к прямой функциональности. Кроме этого, подход к поиску неописанных требований также дает возможность отсечь ситуации, в которых ошибки есть, но они нас не интересуют.
Условно, осуществляя поиск по серийным номерам электронных компонентов, мы не ожидаем, что пользователь из Испании будет пользоваться dead keys, хотя у него есть такая возможность. Это связано с тем, что нет компонентов, которые бы содержали, скажем, символ ñ в маркировке. Делали бы мы, например, словарь, наоборот, нас бы интересовало, почему слова España и España (можно это проверить — скопировать прямо отсюда в текстовый компаратор, в тот же Notepad++) считаются разными и как это обойти, какие могут быть сайд-эффекты.
Исследование не отменяет автоматизацию
Сейчас есть деление на QA и AQA. Мне кажется, оно навязано рекрутментом в Украине. Даже возникают вопросы вроде «вы ручной тестировщик или автоматизированный». Мне больше нравится термин «автоматический» — он больше подчеркивает комичность ситуации. По факту этот вопрос имеет немного другое значение, а именно «можете ли вы, не зная Java, написать тест на Java + Selenium, чтобы кнопки в браузере нажимались сами? А мы дороже бы продали заказчику ваши навыки».
Exploratory Testing часто ставят с обратной стороны автоматизации, хотя вроде бы никто явно и не говорит, что Manual QA не должен знать языки программирования и уметь обращаться с несколькими популярными фреймворками. Точно так же, как и с Postman или SQL, Compare Plugin for Notepad++, Greenshot, Git и другими инструментами. Сложно себе представить, чтобы современные исследователи, скажем тропиков, не использовали туристические технологии, которые появились за последние 100 лет. Но в рекрутменте в отношении QA почему-то так.
Зачем всем этим заниматься
Исследованиями занимается практически любой тестировщик, но обычно в компаниях никто, кроме тестировщиков, об этом не знает. Со стороны они похожи на исследователей плоской Земли, в то время как именно эта часть работы наиболее творческая и эффективная с точки зрения качества продукта.
Exploratory Testing с подготовкой и без выглядит как самые известные экспедиции на Южный полюс Амундсена и Скотта.
Как подготовиться к исследованию
Подготовка выглядит так же, как подготовка к путешествию, то есть нужно определить, что взять с собой. Это помогает также установить, что не брать. Например, если человек едет на выходные в европейскую столицу, то набор вещей для горного похода, скорее всего, не пригодится. Возможно, даже изучать будет особо нечего, потому что на длинную прогулку с заходом во все дворы нет времени, а Эйфелева башня уже достаточно изучена. Таким образом можно, например, не брать большой фотоаппарат, зато взять флягу и сфокусироваться на одном конкретном районе.
Кажется, это банально. Из моего опыта бывает, что QA сосредотачиваются на написании всех тест-кейсов на все требования максимально детально. Но есть базовая ситуация, при которой приложение просто не запускается, и как раз этот случай остается незамеченным, потому что фокусируются на одних и тех же деталях. Приведу аналогию: туристы в Париже сильно сосредоточены на качестве фотографии башни, которых и так уже достаточно, а не на городе.
В реальности разработки это означает, что, наверное, не стоит тратить много времени на то, чтобы попробовать вписать символ 🍉 в какое-то поле, если точно очевидно, что решение будет использоваться на десктопном браузере. И наоборот, если решение в основном для мобайла, важно, чтобы клавиатура для ввода телефона имела телефонную раскладку, а не текстовую.
Важный аспект исследований — не бояться выбросить результаты своих трудов или резко поменять подход. Достичь этого можно путем коротких сессий по часа с поэтапным углублением в детали, которые вообще мало кому интересны. Например, если у людей перелет из украинской зимы в теплую Индию на месячное путешествие, скорее всего, есть смысл надеть старую куртку для дороги в аэропорт и там ее и оставить, а не тащить весь месяц с собой там, где она не нужна.
В тестировании это означает, если какой-то формат рапорта об ошибках не решает вопрос качества, стоит изменить формат. Например, если с ростом функциональности становится все больше регрессионных ошибок, лучше перенести написание автотестов на этап проектирования функциональности. А не писать больше и больше тест-кейсов и выполнять регрессионное тестирование дольше в ущерб времени на нахождение новых ошибок.
Вместо выводов
Мне кажется, об Exploratory Testing стоит говорить со всеми участниками разработки и на всех этапах. Тогда общее впечатление о QA в индустрии сдвинется от «человека, который не осилил стать программистом» до «человека, который может явно сказать, что нужно сделать, чтобы продукт был жизнеспособным». Может, даже подвинет рекрутмент из «сколько лет у вас опыта с мобайлом?» в «как вы находите проблемы?» 🙂
Чем больше специалистов в индустрии владеют практикой Exploratory Testing, тем больше шансов, что люди будут легко и непринужденно пользоваться софтом, жить свою жизнь и не искать, как бы обойти проблему, которую в разработке пропустили. Потому что в их городе уже побывали специалисты по урбанистике, а не только отдел контроля качества установки бордюров.
Підписуйтеся на Telegram-канал редакції DOU, щоб не пропустити найважливіші статті.