Дек. 25

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, нужно быть очень известным или оказаться в компании, готовой на большие эксперименты, чтобы внедрять нетипичные вещи.

Аналогии

Итак, если бы это был город, роли и обязанности делились бы как-то так (с некоторыми упрощениями в разработке программных решений):

Product Owner — градостроительный совет, определяет высокоуровневый вектор того, какой это город для жителей.
Dev Lead — архитектурное и конструкторское бюро, определяет, как будет осуществляться строительство, каких выбрать поставщиков, как организовать очередность.
Developers — организация-исполнитель, фактически занимается тем, чтобы все построить.
QA Engineers — экспертная группа урбанистов, которая определяет, насколько город вписывается в реальные нужды жителей, и исправляет проблемы в работе всех задействованных структур. Важно, что сама эта группа фактически ничего не создает, зато понимает, как это должно работать в реальной жизни.

С последним часто не так. 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 сосредотачиваются на написании всех тест-кейсов на все требования максимально детально. Но есть базовая ситуация, при которой приложение просто не запускается, и как раз этот случай остается незамеченным, потому что фокусируются на одних и тех же деталях. Приведу аналогию: туристы в Париже сильно сосредоточены на качестве фотографии башни, которых и так уже достаточно, а не на городе.

В реальности разработки это означает, что, наверное, не стоит тратить много времени на то, чтобы попробовать вписать символ