Exploratory testing что такое
Тестирование методом свободного поиска: Отказ от плана не значит отказ от цели
В статьях Джеймса Баха можно встретить несколько различных определений того, что такое тестирование методом свободного поиска (exploratory testing), и одно из них звучит так: «тестирование без заранее подготовленных сценариев, выполняемых в точным соответствием с планом» (Exploratory tests, unlike scripted tests, are not defined in advance and carried out precisely according to plan).
За это тестирование методом свободного поиска часто подвергается критике — как можно отказаться от планов, а как же управляемость, контроль и учёт? И вообще, если не будет планов, тогда каждый будет делать кто во что горазд, что-то будет протестировано несколько раз, что-то вообще не будет протестировано, люди не будут знать, что им делать.
Но в действительности сторонники тестирования методом свободного поиска вовсе не призывают к анархии. Напротив, огромное количество статей Джеймса Баха посвящено планированию.
Кажущееся противоречие разрешается очень просто — сторонники этого подхода к тестированию предлагают отказаться от тактического планирования, от излишней детализации планов до уровня отдельных тестов. И заменить тактический план постановкой цели, оставив тестировщику свободу в выборе способов достижения этой цели.
Тестировщик, имея перед собой ясную цель, может, конечно, наметить себе некоторый план, который должен его привести к этой цели. Но если на его пути встретятся какие-то препятствия, или он заметит, что выбранный план уводит в сторону, или следуя этому плану он не достигнет цели к поставленному сроку — это повод для того, чтобы изменить план, а не пытаться «подправить цель».
Что такое исследовательское тестирование?
И чем оно отличается от тестирования по сценариям (сценарного тестирования)
Этот пост является переводом статьи Джеймса Баха 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 обычно используют оба подхода в одном проекте. Тем не менее есть много важных различий между двумя подходами.
Зачем проводить исследовательское тестирование?
Наиболее обсуждаемыми темами в управлении эффективным исследовательский циклом тестирования являются тестировщик, стратегии тестирования и отчетность. Сценарный подход к тестированию является попыткой механизировать процесс тестирования, когда берется идея из головы тест-дизайнера и излагается на бумаге. Подобный способ тестирования очень полезен. Но тестировщики, использующие исследовательский подход, придерживаются мнения, что запись тестовых сценариев и следование им «отупляет» тестировщика, мешая ему быстро находить ключевые проблемы. Чем более интеллектуальным мы можем сделать тестирование, тем больше шансов у нас будет, что мы протестируем приложение правильно и успеем сделать это вовремя. В этом и заключается мощь исследовательского тестирования: богатство этого процесса ограничивается только широтой и глубиной нашей фантазии, а также нашим пониманием природы тестируемого приложения.
Сценарное тестирование занимают свою нишу. Я могу себе представить ситуации в тестировании, когда эффективность и воспроизводимость настолько важны, что мы должны написать сценарии для них или их автоматизировать. Например, в случае, когда тестовая платформа регулярно бывает недоступна, как в случае клиент-серверных приложений, в которых есть только несколько настроенных серверов и они должны быть разделены между командами разработки и тестирования. Здравый смысл подсказывает нам, что мы должны заранее тщательно проработать сценарий тестов, чтобы получить максимальную отдачу во время выполнения тестов в выделенное нам время. Исследовательское тестирование особенно полезно в сложных ситуациях тестирования, когда мало что известно о продукте, или как часть подготовки набора сценариев тестов. Основное правило заключается в следующем: исследовательское тестирование используется в тех случаях, когда выполнение следующего теста неочевидно, или когда вы хотите выйти за рамки очевидного. По моему опыту, это происходит в большинстве случаев.
Исследовательское тестирование: когда его стоит применять и как это делать
Многие скептически относятся к исследовательскому тестированию, так как считают, что это пустая трата времени и ресурсов. Но на самом деле это не так. В этой статье я расскажу, когда исследовательское тестирование принесет проекту пользу. В русскоязычной литературе дается очень много различных определений для термина «исследовательское тестирование». Нередко под этим понятием подразумевается ad-hoc тестирование и наоборот. Почему так сложилось исторически можно узнать там — Исследовательское тестирование 3.0. Чтобы при чтении статьи не возникало путаницы, сверим часы и зафиксируем определения.
Что такое исследовательское тестирование
Ad-hoc тестирование
Под ad-hoc тестированием будем понимать тестирование без использования спецификаций, планов и разработанных тест-кейсов: чистая импровизация.
Исследовательское тестирование
Более формальная версия ad-hoc: тестирование, не требующее написания тест-кейсов, но подразумевающее, что каждый последующий тест выбирается на основании результата предыдущего теста. А по Сэму Канеру, «Testing Computer Software», «исследовательское тестирование» — вдумчивый подход к ad-hoc тестированию.
Сценарное тестирование
Классическое тестирование по предварительно написанным и задокументированным сценариям.
Перечитайте эти пункты еще раз, но уже с мыслью о том, почему плюсы сценарного тестирования могут оказаться минусами для исследовательского и наоборот.
Когда можно применять исследовательское тестирование в чистом виде
Мало времени
Если тестовая документация написана, но времени на прохождение тестов уже нет, нужно выбирать наиболее критичные области приложения, которые реально протестировать за имеющееся время. Составить чек-лист с идеями и тестировать вокруг них.
Сложности с требованиями
Требований нет, они не полны или устарели и нет возможности их актуализировать.
Небольшой проект
Продукт маленький, и разработка тестовых сценариев займет больше времени, чем сам процесс тестирования.
Когда можно применять исследовательское тестирование в дополнение к обычному тестированию
Пришел внезапный запрос на изменения
Времени на разработку новых сценариев нет, так как все заняты другими запланированными задачами или изменения потребуют переработать большую часть документации. В этой ситуации тестирование исследовательским методом может быть наиболее оптимальным.
Когда хочется перестраховаться
Продукт уже протестирован по сценариям, но всё еще хочется убедиться в том, что ничего не было упущено.
Когда одним исследовательским тестированием не обойтись:
Приложение стандартизованное
Приложения, работающие по стандартам и гостам, а также системы, для которых малейшее отклонение может быть критичным. Это могут быть приложения, отвечающие за полеты ракет или проводящие финансовые операции.
Проводится интеграционное тестирование
В этом случае исследовательское тестирование возможно, например, при тестировании API. Но обычно интеграционное тестирование проводится для проверки взаимодействия внутренних компонентов приложений. Эта работа хорошо покрыта документацией и часто автоматизируется.
Тестовые сценарии отдаются на аутсорс
Аутсорс аутсорсу рознь, но контролировать поставленную задачу и процент ее выполнения проще по формализованным сценариям.
Длительный проект
Тестировщики могут быть подключены к проекту на время определенной фазы, а после, пока разработчики реализовывают новый функционал, заниматься другими проектами. Если долго не тестировать конкретную функциональность, то ее специфика забывается.
Развенчание мифов или как применять исследовательское тестирование
«Исследовательское тестирование невозможно проконтролировать, им нельзя управлять. Сложно определить, когда пора остановиться и покрыт ли весь функциональность»
Иногда исследовательское тестирование воспринимают как антоним к сценарному и относятся к нему как к тестированию в полном хаосе.
На самом деле эффекта измеримости и распараллеливания задач добиться достаточно просто. Хватает зафиксировать объем работ и разделить его на измеримые по времени части.
«Нельзя доверить выполнение тестирования первому встречному»
Отчасти это действительно так. Но и сценарное тестирование не следует отдавать «случайному» человеку. На практике невозможно хорошо тестировать продукт, следуя только по заранее подготовленным шагам. Всегда возникает желание отступить от тщательно выверенных сценариев и поработать с деталями — добавить негативных проверок, проверить работу с прерываниями и так далее. И это хорошо, так как покрыть продукт тестами на 100% невозможно и никогда нельзя до конца исключить фактор человеческой ошибки.
В целом, улучшение навыков QA-команды всегда является одной из целей QA-подразделения. Используя исследовательское тестирование, инженеры задействуют интуицию и опыт, накопленные ранее и привыкают постоянно анализировать продукт.
«Сложно „продать“ исследовательское тестирование заказчику, объяснить его необходимость»
На самом деле для заказчика важен результат и прозрачность процессов. В данном случае результат – это продукт, удовлетворяющий представлениям заказчика о качестве. А необходимой прозрачности процессов можно достигнуть с помощью грамотных отчетов.
Выводы
Исследовательское тестирование — не означает полное отсутствие документации и хаос, а является мощным инструментом.
Используя ранжирование типов тестирования от полностью исследовательского до полностью сценарного, детализируя структурно составленные чек-листы, можно подобрать оптимальный уровень документации для вашего проекта и сэкономить время.
Сценарное и исследовательское тестирование являются полностью совместимыми и компенсируют недостатки друг друга. Можно покрыть детальными тестами сложные технические аспекты проекта и написать поверхностные чек-листы для пользовательского интерфейса.
Будьте гибкими. Вырабатываете стратегию, которая наилучшим образом подойдет для вашего продукта. Качественных вам проектов.
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 сосредотачиваются на написании всех тест-кейсов на все требования максимально детально. Но есть базовая ситуация, при которой приложение просто не запускается, и как раз этот случай остается незамеченным, потому что фокусируются на одних и тех же деталях. Приведу аналогию: туристы в Париже сильно сосредоточены на качестве фотографии башни, которых и так уже достаточно, а не на городе.
В реальности разработки это означает, что, наверное, не стоит тратить много времени на то, чтобы попробовать вписать символ