Исследовательское тестирование: В поисках музыки исследования ПО

Предисловие от переводчика.
Как и обещал, выкладываю перевод статьи Jonathan Kohl Exploratory Testing: Finding the Music of Software Investigation, от июля 2007. Статья была переопубликована в декабре 2007 журналом Methods and Tools (HTML-вариант). Джонатан дал свое согласие на публикацию перевода, и ему на самом деле очень лестно думать, что его статья теперь доступна и для неанглоговорящих читателей. Перевод совсем сырой, я его даже не перечитывал полностью, элементарно нет времени с ним возиться, поэтому не обессудьте. Остается добавить лишь то, что exploratory я всегда переводил как исследовательский, а если вы встречаете слова разрешение и напряжение и не можете увязать с контекстом, вернитесь к первому абзацу и постарайтесь понять их абстрактный смысл. Термин эвристика можно также трактовать как некая устоявшаяся практика (на мой взгляд это самое близкое по смыслу), но для context driven testing school этот термин достаточно устоявшийся.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы начать тестирование в таких условиях, я часто использую разработанную мной мнемонику "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