Home

Автор: Jonathan Kohl, Kohl Concepts Inc., www.kohl.ca
Оригинальная публикация на английском языке: "Exploratory Testing: Finding the Music of Software Investigation"

Переводчик: Валерий Худобородов, bugsclock.blogspot.com
Оригинальная публикация перевода на русский язык

Предисловие переводчика.

Exploratory я всегда переводил как исследовательский, а если вы встречаете слова разрешение и напряжение и не можете увязать с контекстом, вернитесь к первому абзацу и постарайтесь понять их абстрактный смысл. Термин эвристика можно также трактовать как "некая устоявшаяся практика". На мой взгляд это наиболее близкий по смыслу перевод, но для context driven testing school этот термин уже прижился сам по себе.

Мой друг Стив незаурядный игрок на классической гитаре. Наблюдение за его игрой -- вдохновляющее зрелище, он потратил годы на оттачивание сноровки и исключительно мастерски владеет инструментом. Стив может рассказать о технике своей игры, дать несколько уроков и показать ученикам, как усовершенствовать свои умения. Он может петь под гитару и говорит, что музыка это напряжение (tension) и разрешение (resolution) [Напряжение -- это переход в диссонансное звучание, а разрешение -- это, наоборот, переход в консонанс. Диссонансные аккорды звучат более жёстко, напряжённо, а консонансные более мягко и гармонично - прим. пер.] Если вся музыка будет напряженная, слушателю станет не по себе. Если будет только разрешаться -- то это скучные, утомительные повторения. Стив расширяет эту идею до фактических физических действий, которые гитарист использует для извлечения определенных звуков. К примеру, если вы играете с большим преобладанием напряжения, вы будете ограничены в возможностях выполнить определенные действия. Чтобы играть музыку, вам необходимо найти баланс между напряжением и разрешением, а, чтобы найти этот баланс, вам необходимо сочетание знаний, навыков и творческого подхода.

Как и Стив, мой друг Джеймс Бах тоже исключительно искусен. Он не гитарист, он тестировщик. Джеймс так же вдохновляет, когда демонстрирует свою технику. Он мастер квалифицированного исследовательского тестирования: одновременного проектирования тестов, их выполнения, и познания [1]. Джеймс тоже может объяснить используемые им техники тестирования, чтобы обучить учеников-тестировщиков. Увидев первый раз, как он тестирует софт, я сразу вспомнил Стива. Но в этом случае напряжение и разрешение не было связано с музыкой или техникой игры на музыкальном инструменте. Вместо этого напряжение и разрешение вращались вокруг идей. Джеймс одновременно разрабатывал и выполнял тесты, основанные на любознательности по отношению к приложению. Все его тесты обладали обратной связью, посредством которой он получал познания для разработки следующего теста. Напряжение происходило от исследовательского характера его тестов, а разрешение проявлялось в их результатах. Это была музыка взаимодействия ума тестировщика и тестируемого приложения. И это не было неожиданностью -- как тестировщик, Джеймс имеет хорошо развитое сочетание знаний, навыков и творческого подхода.

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

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

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

В тестировании заранее записанные тестовые сценарии также предоставляют возможность их интерпретации каждым исполнителем по-своему. Автоматизация гарантирует, что эти скрипты будут выполнены так, как записаны, но как и автоматическая музыка, нехватка интерпретации в выполнении может ограничить полученный результат. Машина сможет найти лишь те проблемы, которые мы можем предсказать и запрограммировать. Повторение одних и тех же тестов может стать скучным и нудным, становится "разрешением" идеи, без живого "напряжения", рождаемого любопытством. Но с другой стороны есть импровизационное тестирование: исследовательское. Чистое исследовательское тестирование означает, что мой следующий тест полностью порожден моими текущими идеями без каких-либо заготовок. Чистое сценарное тестирование и чистое исследовательское -- два берега одной реки.

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

На что похоже квалифицированное исследовательское тестирование? Представим сценарное и исследовательское тестирование в действии. Однажды я наткнулся на ручной тест и аналогичный автоматический, которые были написаны несколько релизов назад. Они были подготовлены для приложения, с которым я был плохо знаком, и в нём использовались технологии, которые я едва знаю. Я никогда не выполнял эти тесты раньше, поэтому я запустил автотест первым, чтобы узнать, что же там тестируется. Он выполнился успешно, но само выполнение и его результаты не дали какой-либо полезной информации, кроме как "тест пройден". По мне, это равносильно получению письма в котором говорится: "Поздравляем! Возможно, вы уже победитель!". Подобного рода заявления несут очень малую смысловую нагрузку.

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

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

Я выполнил другой тест, и свободный от ограничений, которые накладывали на меня заранее записанные тесты, заметил нечто, что привлекло мое внимание: приложение стало подтормаживать. Зная, что с течением времени причины некоторых проблем проявляются сильнее, я решил попробовать тест другого рода. Я смог бы проследовать до последней части ручного теста, подождать несколько минут, и досконально проверить систему. Я выполнил этот новый тест и система, как оказалось, стала тормозить ещё сильнее. Сообщения приложения говорили мне, что всё в порядке, однако "тормозное" поведение было симптомом более крупной проблемы, не покрываемой первоначально выполненным тестом.

Заглянув "за фасад" интерфейса пользователя, я обнаружил, что приложение молча сбоило; в то время, как считалось, что выполнение транзакции записи в базу данных прошло успешно, на самом деле данные удалялись. Мы каждый раз теряли данные с момента запуска первого теста. Даже если тест казался пройденным, в приложении происходил серьезный сбой. Если бы я прогонял только ручной и авто тесты, проблема оставалась бы незамеченной и привела бы к катастрофическим последствиям при поставке продукта. К тому же, если бы я тратил время, на запись тестов, а затем выполнял их, я бы, скорее всего, упустил возможность, позволившую мне найти источник проблемы. Простое выполнение записанных текстов это всего лишь "разрешение" идеи и не позволяет обнаружить что-либо интересное. С другой стороны, взаимодействие "разрешения" и "напряжения" идей при исследовательском тестировании быстро приводит к важным находкам. Благодаря подобным результатам, я не склонен использовать большое количество заранее записанных ручных тестов в своей работе.

Так как же я обнаружил эту проблему, подобную часовой мине, с которой мог столкнуться заказчик? Я рассматривал тестовые скрипты как они есть: неполноценные источники информации, которые могли бы ограничить мои возможности в получении полезной информации о приложении. Перед, во время и после выполнения я разрабатывал и переделывал тесты, основываясь на своих наблюдениях. Также у меня были плохие предчувствия, когда я запускал тест. Я научился изучать эти предчувствия, а не подавлять их, потому что чувство "напряжения" не включено заранее в скрипт или процесс; часто такое быстрое исследование приводит к важным находкам. Я не позволил скрипту диктовать мне, что следует делать или что считать успешным результатом. Я был уверен, что исследовательское тестирование подтвердит или опровергнет ответы, представленные в записанных тестах.

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

Музыканты используют схожие техники, и могут распознать "the circle of fifth" как эвристику, которой надо следовать, если они заблудились в своей импровизации. (Это вовсе не гарантирует, что эвристика будет работать. Когда эвристика не подходит, вы просто пробуете другую.) Музыканты стремятся иметь большой набор эвристик, и столь же широко используют мнемонику. Как пример - "Every Good Boy Does Fine", который используется для запоминания нот "EGBDF" на нотном стане. Искусные тестировщики используют похожий инструментарий для запоминания тестовых идей и техник.

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

Чтобы начать тестирование в таких условиях, я часто использую разработанную мной мнемонику "MUTII". (Композитор Nicolo Mutii помогает мне вспоминать это название.) Эта мнемоника помогает мне сохранять логичность в размышлениях о тестировании. Расшифровка мнемоники:

Market (рынок) -- целевая группа пользователей. Например, финансовый отдел или бухгалтерская контора среднего пошиба.

Users (пользователи) -- реальные пользователи, которые будут использовать приложение. Кто они? Что делают? Какие у них мотивы использовать наш продукт?

Tasks (задачи) -- для решения каких задач пользователь будет использовать продукт? Каковы его типичные рабочие задачи?

Information (информация) -- как продукт расскажет мне о задачах, которые он автоматизирует, и как я смогу выполнить их?

Implementation (реализация) -- легко ли использовать продукт первый раз? Он надежный? Могу ли я легко выполнить свои задачи с учетом дизайна продукта и предоставляемой им информации?

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

Когда я начинаю тестировать, я раскрываю свой блокнот для записи наблюдений и мыслей, а также любых найденных багов (см. рисунок 1). Я начинаю планировать тест в уме, выполнять его в приложении и изучаю результат. Я постоянно повторяю это процесс, изменяя тесты, и оглядываюсь на свою MUTII-мнемонику.

Рисунок 1: Фрагмент журнала тестовой сессии.

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

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

Использование мнемоник и эвристик помогает мне быть последовательным в тестировании, но я не позволяю им управлять моими действиями. Если я нахожу что либо подозрительное, я исследую это, и либо подтверждаю либо отвергаю свои подозрения. Очень просто переключаться между мнемониками и эвристиками в свободную импровизацию и возвращаться назад, либо вообще импровизировать с высокоструктурированными тестами. Исследовательское тестирование -- как импровизация -- помогает адаптировать мышление и действия, основываясь на том, как продукт "отвечает". Это самый значительный принцип. Вы можете использовать возможности, как только их обнаруживаете. К тому же, вы можете быстро адаптироваться к рискам проекта, выявлять и исследовать новые. Отточив мастерство управления мышлением в тестировании, вам больше не придется ждать спонтанных находок, появляющихся из ниоткуда, у вас не будет проблем с объяснением нахождения или воспроизведения каких-то особенных проблем.

Развитие навыков исследовательского тестирования показывает вам все издержки вашего подхода к тестированию. Квалифицированное тестирование, также, как квалифицированное музицирование часто относят к магии, просто потому, что это сложно понять. Музыка основана на наборе шаблонов, эвристик и техник. Если вы знаете немного, вы без труда можете сыграть. Получение их путем проб и ошибок - долгий процесс, и вам будет очень сложно объяснить, как вам удалось их приобрести. Тестирование использует чистое наблюдение, и метод проб и ошибок может быть эффективным, но гораздо эффективнее, если есть система, в которое он вписывается.

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

Сссылки:
1. Bach, James. (2003) Exploratory Testing Explained
http://www.satisfice.com/articles/et-article.pdf
2. Kaner, Cem. (2004). The Ongoing Revolution in Software Testing. Presented at Software Test & Performance Conference, December, 2004, Baltimore, MD
http://www.kaner.com/pdfs/TheOngoingRevolution.pdf
3. Bach, James. (1999, November) Heuristic Risk-Based Testing. Software Testing and Quality Engineering Magazine http://www.satisfice.com/articles/hrbt.pdf

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