Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи
Перевод: Ольга Алифанова

В прошлой части ретроспективных уроков исследовательского тестирования я делился знаниями об эвристиках. Сегодня мы поговорим об одной специфической эвристике – эвристике оракула тестирования.

Что такое оракул тестирования?

В области технологий со словом "оракул" можно столкнуться в нескольких контекстах (конечно, помимо компании с тем же названием).

Если вас интересует более широкий смысл термина "оракул" в IT, вы можете ознакомиться с определением машины оракула, связанное с работами Алана Тюринга. Оно немного связано с нашей темой, потому что определяется как сущность, способная на решение проблемы.

В области тестирования мы используем концепцию тест-оракула. Используется он практически так же – это сущность (тип может варьировать), дающая нам решение проблемы или валидирующая, является ли относящаяся к тестированию информация верной.

Почему оракул так называется?

В древние времена оракулом называли мудрого человека или старейшину, к которому шли за советом в случае необходимости принять важное решение. "Надо ли начинать войну на севере?" или "Должна ли дочь нашего правителя выйти замуж за Х для воцарения мира?", и так далее. Все эти вопросы касались критически важных проблем, и, как правило, слова оракула расценивались очень серьезно.

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

Что может быть оракулом тестирования?

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

Ментальная модель или ощущение (Опыт) – это может показаться слегка абстрактным, но если вы хоть раз тестировали ПО и находили в нем проблемы, то знаете, что начинается это с ощущений. Что-то говорит вам – тут что-то не так, это нужно изучить. В любом случае этого недостаточно для создания баг-репорта, поэтому мы будем исследовать вопрос подробнее.

Артефакты (Справка) – любой вид знания, зафиксированного письменно, или документ, дизайн, черновик, любая форма коммуникации, которая несет знания. Все это можно использовать как оракул.

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

Соответствие известным продуктам (Умозаключение) – применение знаний о сравнимых продуктах к тестируемому, и поиск:

• Несоответствий: общественным стандартам для приложений, которые мы тестируем. Пример: у всех мобильных калькуляторов есть определенная опция, но у нас она реализована слегка иначе.
• Соответствий: проблемам, с которыми мы сталкивались в том же классе приложений. Пример: каждый раз при тестировании загрузки файлов я ищу проблемы с валидацией ограничения размера файлов, потому что мой предыдущий опыт (один оракул) с другими схожими приложениями (другой оракул) гласит, что там часто кроются баги.

Почему оракулы – это так важно?

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

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

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

Где найти оракулы в живой природе?

Как я говорил ранее, оракулы – концепция, которую вы используете в тестировании, нравится вам это или нет. Вы можете не знать, что вы ими пользуетесь, или не называть это оракулом.

Примеры использования оракулов:

• Тест-кейсы и тест-сценарии: я небольшой их фанат, но люди ими пользуются. Если вы знакомы с концепцией создания тест-кейса, то знаете, что там есть раздел "Ожидаемый результат". Это классический пример оракула, так как он сообщает всем о правильном поведении приложения. Аналогичное применимо к ожиданиям в баг-репортах и автоматизированных проверках.
• Документация: документы и спецификации используются как оракулы. Это неплохо, но проблема в том, что они создаются и поддерживаются людьми и страдают от тех же проблем, что и код: они теряют актуальность, в них есть ошибки, они расплывчато сформулированы, чересчур техничны, чересчур поверхностны, слишком детализированны… Проблемы возникают, когда мы, как тестировщики, начинаем рассматривать документацию как единственный ценный источник знаний, в то время как в первую очередь нами должны руководить эксперименты и исследования.

Подробно об оракулах

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

Если вас интересует концепция оракулов тестирования, то вот пара ресурсов, которые могут вам пригодиться:

• FEW HICCUPS
• The oracle problem – статья Кема Кейнера

Вот о каких оракулах я узнал из этих статей, и применяю их ежедневно:

• FEW HICCUPPS – незаменимый оракул, если вы пользуетесь им для валидации, правильное ли поведение вы наблюдаете. Это именно то, для чего он был предназначен – для использования в качестве чек-листа. Каждый раз, сталкиваясь с неуверенностью, баг ли это, вы можете прибегнуть к FEW HICCUPPS и поразмышлять, можно ли валидировать это поведение стандартом, понимаете ли вы цель, соответствует ли она продукту, заявлениям о продукте, истории продукта, и так далее. Этот тип мышления, управляемого через вопросы – причина моей убежденности, что оракулы могут работать в обратном направлении, то есть не только как внешняя сущность для валидации истины о продукте, но и как провокация экспериментов, помогающих вскрыть несоответствия между ожиданиями и реальностью.
• Оракул регресса – если вы рассматриваете регрессионное тестирование как возможный оракул, то, насколько я понимаю, вы освобождаетесь от большей части этой ноши – ожидания, что это неотъемлемая и всемогущая часть эффективного тестирования. Многие люди убеждены, что регрессионное тестирование означает, что нужно каждый раз прогонять набор тестов, или все ваши тесты, или все автоматические проверки. Я могу написать целую статью о всем том, что неверно в этом убеждении, но я ценю ваше время, поэтому просто поверьте мне на слово. Вместо этого попробуйте относиться к регрессу как к виду оракула. Как оракул и, соответственно, эвристика, он имеет ограниченную эффективность.
• Ограничения как оракул – я убежден, что это самый очевидный, простой в использовании, и в то же самое время наиболее упускаемый оракул. При любом тестировании у вас есть список ограничений – максимальная длина строки, количество разрешенных спецсимволов, размер файла – и все это подсказки для вас. Как хороший тестировщик, вы в первую очередь должны думать, что будет, если вы нарушите правила? Что будет, если не вводить запрашиваемое количество символов? Что произойдет? Появится ли ошибка, будет ли исключение, предусмотрел ли разработчик подобный сценарий? Если вы один из тех, кто говорит "Без понятия, с чего начинать тестирования", то вот неплохой план действий – найдите все ограничения продукта, составьте список, постарайтесь нарушить их как минимум тремя различными способами, зафиксируйте результаты, и пусть собранная информация станет толчком для более глубокого тестирования. Это хороший старт тестирования, и он прямо у вас перед глазами.
• Самоверифицируемые данные как оракул – я активно пользуюсь этим оракулом в автоматических проверках, в основном для имен тестов. Я также пытаюсь приучить к этому разработчиков. Здравый смысл гласит, как минимум мне, что имя автоматической проверки должно сообщать о проверяемом результате. Это также хороший способ убедиться, что ваши проверки фокусируются на одном действии и его результате, а не распыляются на разные возможности. Пример: если моя проверка называется testingValidAdminUserFlow и падает, я без понятия, где она упала и что с ней не так. Это значит, что мне придется изучать вопрос, и это увеличивает временные затраты. С другой стороны, если вы создаете небольшие, однозначные проверки, использующие самоверифицируемые данные как оракул, вы легко определите, в чем проблема. К примеру, если проверка называется loginAsAdmin200Test и падает, вы будете точно знать, что авторизация под администратором не вернула код ответа 200.

Оракулы – это эвристики

В качестве заключения: нравится вам это или нет, вы используете оракулы, и верьте мне, это хорошо. Чем больше вы о них знаете, тем больше вы знаете в принципе.

О чем никогда нельзя забывать: оракулы – это тоже эвристики, и страдают от тех же самых проблем – они ненадежны и редко работают как единственный источник истины. Ваша тест-документация может устареть, она может быть запутанной, недостающей, или использовать расплывчатые определения. Люди, владеющие знаниями, могут что-то забыть, направить вас по неверному пути, страдать от когнитивных искажений, ваше опорное приложение может иметь баги…

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

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