Home

Автор: Майкл Болтон
Оригинальная публикация: Swan Song
Перевод: Алексей Баранцев

Чёрным лебедем в одноименной книге Нассима Николаса Талеба называются невероятные и неожиданные события, приводящие к крупным неприятностям. Одна из наиболее важных целей тестирования -- обнаружение проблем в тестируемом продукте. Что могут сделать тестировщики, чтобы помочь снизить вероятность встречи с Чёрным Лебедем?

С самого рождения индюк видит, что люди -- это добрые, внимательные и заботливые существа. Фермер кормит индюка, содержит его в сухости и тепле, защищает его от хищников. Каждый день индюк получает всё новые и новые подтверждения своей фундаментальной уверенности в доброжелательности людей. А затем, за несколько дней до Дня благодарения, индюк получает неприятный сюрприз.

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

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

Когда мы тестируем, мы используем модели. Мы моделируем область тестирования, принимая решение о том, где пролегает граница между тем, что мы будем тестировать, а что нет. Мы моделируем структуру программы, используя диаграммы и блок-схемы. Мы моделируем покрытие разными способами, чтобы как можно лучше исследовать проблемы различных типов. Каждая модель является лишь проекцией, образом чего-то более сложного, поэтому в каждой модели чего-то не хватает. Талеб объясняет, где кроется опасность: "Модели и толкования, эти интеллектуальные проекции реальности, не всегда ложны, они ложны только при некоторых конкретных способах использования. Сложность заключается в том, что a) вы не знаете заранее (а узнаёте только постфактум), когда модель окажется ложной, и b) ошибки могут приводитиь к очень крупным последствиям. Эти модели подобны потенциально полезным лекарствам, имеющим случайный, но очень серьёзный побочный эффект".

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

Однако дефокусировка играет не менее важную роль. В реальном мире наши клиенты не выполняют переинициализацию системы после каждого использования. Они действуют не так, как мы. У них встречается масса различных задач, ролей, характеров и шаблонов поведения. Их сложные действия не всегда укладываются в рамки наших ожиданий, и они не особенно заботятся о том, насколько продукт соответствует спецификациям и документированным требованиям. Их волнует, насколько продукт соответствует их личным требованиям, независимо от того, являются ли они документированными, неявными или вообще невыясненными. Часто у нас нет возможности получить прямой выход на пользователя, чтобы понять, каковы эти требования в тот или иной момент. Чтобы обнаружить некоторые проблемы, с которыми могут столкнуться наши пользователи, нам нередко требуются сложные насыщенные сценарии, длинные последовательности действий и тесты, отличающиеся тем, что их сложно пройти, а не тем, что результат легко проверить. Как говорит Талеб, "Когда вы имеете дело с неопределённостью, самое худшее, что вы можете делать -- фокусироваться. Фокусировка приводит к ошибочным предсказаниям, она позволяет вас одурачить". Несмотря на то, что мы можем уверенно предсказать, что в программе есть и будут ошибки, мы не можем с такой же уверенностью предсказать, где их следует искать. Баги по своей природе оказываются непредсказанными, а иногда и непредсказуемыми. Если бы они были предсказуемыми, мы могли бы не допустить их появления вообще.

Нам часто предлагается моделировать риск, используя формулу "вероятность помноженная на влияние". Однако наше понимание вероятности, влияния, а также функции, которая связывает их с риском -- это тоже модели, так что основанная на них оценка рисков создает условия, благоприятные для появления Чёрных Лебедей. В 1995 году в компании Intel использовался подобный подход, чтобы оценить влияние ошибки в модуле деления чисел с плавающей точкой на конечных пользователей и на их собственный бизнес. Поскольку никакие предыдущие ошибки в процессорах никогда не приводили к возникновению столь серьёзного риска, использованная в Intel модель рисков не учитывала эмоциональное влияние и реакцию СМИ на это событие. Компания была просто заклёвана Чёрными Лебедями -- негативными отзывами в прессе, в результате чего стоимость её акций резко снизилась. Впрочем, необходимо сразу предупредить, что из-за "синдрома объяснимости" (это ещё один аспект, рассматриваемый Талебом в своей книге) нам легко сейчас в ретроспективе рассуждать о том, что компании Intel следовало бы иначе подойти к решению этой проблемы. Мы знаем, чем закончилась эта история, и из-за этого у нас возникает обманчивая вера в то, что мы могли бы сделать лучше. Как бы не так!

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

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

Мы не можем подтвердить хоть сколько-нибудь общее утверждение о продукте, используя проверки -- отдельные конкретные наблюдения некоторых аспектов поведения системы, завершающиеся принятием решения "да/нет", которые могут быть выполнены машиной. Проверки, особенно в форме автоматизированных модульных тестов, крайне полезны. Они поддерживают разработку, направляемую тестами, обеспечивая программисту быструю обратную связь о том, развивается ли исходный код программы в нужную сторону или нет. Проверки помогают выполнять рефакторинг, выявляя неожидаемые или нежелательные изменения в поведении программы. Проверки позволяют выявить важные проблемы ещё до того, как они покинут среду разработки, и эти проверки надо выполнять быстро -- сотни или даже тысячи за считанные секунды, с такой скоростью их может выполнять только машина. Однако, при этом следует соблюдать осторожность, поскольку проектирование и разработка проверок требует реальных навыков как в тестировании, так и в программировании. Впрочем, более важно то, что проверки подтверждающего типа неизбежно следуют нашим моделям, вместо того, чтобы исследовать их. Я не открыл тут ничего нового, ещё в 1961 году Лидс (Leeds) и Вейнберг (Weinberg) писали:

"Один из уроков, который мы должны вынести, заключается в том, что сколько бы тестов мы ни выполнили, само по себе это не имеет большой ценности. Слишком часто тесты всего лишь демонстрируют, насколько хорошо компьютер может справляться с одними и теми же заданиями, получая на вход различные числа. Как и во многих других случаях, нас, вероятно, направляет по ложному пути наш опыт взаимодействия с живыми людьми, которые по своей природе не блещут способностью стабильно и без отклонений выполнять повторяющиеся действия. Компьютерные программы, наоборот, трудно сделать достаточно гибкими и адаптивными (впрочем, и для людей это иногда является проблемой). Нам нужно, чтобы каждый тест делал некоторую работу, не сделанную предыдущими тестами. Чтобы этого добиться, мы должны стараться развить в себе с одной стороны скептицизм и недоверчивость, а с другой стороны -- живое воображение".

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