26 авг. 2009 г.

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

Предисловие от переводчика.
Как и обещал, выкладываю перевод статьи 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

19 авг. 2009 г.

Мифы и грабли: Откуда есть пошло Исследовательское Тестирование и причем тут ad hoc


Вообще, изначально был только ad hoc testing, который считался несистематичным, небрежным, неспланированным и прочее. Но на самом деле, это просто импровизация тестировщика во время тестирования. Потом, где-то в начале 90-х годов прошлого века, собрались товарищи (самый яркий представитель - Канер), которые объявили себя context-driven software testing school, усовершенствовали тот самый ad hoc и чтобы не вводить никого в заблуждение, придумали термин exploratory testing (который упоминается в книге Канера Testing Computer Software), что по сути являлось всего-навсего "умудренным" подходом к ad hoc тестированию. В последующее десятилетие, тремя китами Exploratory Testing - Cem Kaner, James Bach и James Whittaker, были разработаны специальные техники и выделены навыки, которые необходимы для применения Исследовательского Подхода. Ради интереса, можно изучить данный артефакт.

Разница между ad hoc и exploratory testing в том, что теоретически, ad hoc может провести кто угодно, а для проведения exploratory необходимо мастерство и владение определенными техниками. Обратите внимание, что определенные техники это не только техники тестирования. Ну а в настоящее время, на фронтах идут битвы за разделение понимания exploratory и ad hoc.

Написано по памяти из всяких разных источников и интервью Д.Баха, ссылки лень искать

18 авг. 2009 г.

51 основное качество успешного проекта


У нас в офисе, над кофе-машиной висит бумажка:
Чтобы стать успешным, проект должен сочетать в себе 51 основное качество (переводить не буду):
1. Accessibility
2. Affordability
3. Beauty
4. Build
5. Caching
6. Code Coverage
7. Compatibility
8. Complexity
9. Consistency
10. Credibility
11. Cyclomatic complexity
12. Discoverability
13. Documentation
14. Efficiency
15. Ethics
16. Extensibility
17. Honesty
18. Integration
19. Licensing
20. Logging and instrumentability
21. Maintainability
22. Marketability
23. Memorability
24. Modularity
25. Open-ness
26. Optimisibility
27. Originality
28. Parallelability
29. Performance
30. Platform versatility
31. Popularity
32. Power
33. Practicality
34. Predictability
35. Purity
36. Readability
37. Reliability
38. Remarkability
39. Responsiveness
40. Reusability
41. Robustness
42. Scalability
43. Scriptability (automatability)
44. Security
45. Simplicity
46. Testability
47. Transparency
48. Trustworthiness
49. Usability
50. User eXperience
51. Versatility

Вы можете позволить себе три.
Два из них - безопасность (44 - security) и удобство использования (49 - usability).
Выберите ещё одно.

Источник http://secretgeek.net/core51.asp

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


Хочу представить анонс перевода очередной, в этот раз довольно большой, статьи на тему исследовательского тестирования от Jonathan Kohl, которая в оригинале называется "Exploratory Testing: Finding the Music of Software Investigation". Ссылку, как обычно, не даю, а любителям прочитать в оригинале, найти не составит труда. Может быть, среди читателей есть люди, знающие конкретный перевод для музыкальных терминов tension и resolution? Был бы весьма признателен за подсказку. Поскольку сама статья довольно длинная, слишком скоро остальную часть не ждите, надеюсь за неделю справлюсь.

************************************

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

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

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

Сссылки

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

13 авг. 2009 г.

Exploratory testing: Развитие понимания об исследовательском тестировании. Часть 3


Часть 1
Часть 2

Исследовательское тестирование это то, что вы выполняете, когда вам нужен быстрый результат? Исследовательские подходы, как правило, работают быстрее сценарных, ибо у исследовательского подхода меньше пробелов и задержек в обмене познанного между участниками, а также и вследствие того, что познание происходит быстрее, если люди сами управляют своей деятельностью. При исследовательском методе, тестировщик склонен быть более вовлеченным в познание; динамично переключать внимание; проводить одновременно множество исследований - что-то сознательно, а что-то нет; моментально давать оценку - сознательно либо нет; и принимать мгновенные решения в отношении того, что делать дальше. А вот при сценарном подходе трудно сходу придумать емкий, атомарный тест; даже невероятно невовлекаемый человек будет проводить проницательное, несценарное исследование снова и снова. Как минимум из-за тенденции к повторению и невовлечению, выполнение сценарных тестов человеком часто воспринимается как скучная и монотонная работа. Выполнение сценарных тестов машиной занимает меньше времени, но сама подготовка сценария (будет он выполнен машиной, либо человеком) отнимает больше, нежели когда его не готовить, плюс подводный камень - стоимостm автоматизации.

Как обращал наше внимание Jerry Weinberg в своей к ниге Perfect Software And Other Illusions About Testing, много важных тестов проводится без нажатий кнопок на клавиатуре или запуска автотестов. Исследовательский подход может быть применен к любому аспекту процесса разработки, а не только к выполнению тестов (т.е. конфигурация, управление, наблюдение и оценка работающего продукта). Ревью может быть проведено как исследовательским, так и сценарным методом, с учетом того, что рецензент сам определяет что наблюдать. Например, ревью может быть проведено в свободном стиле (в этом случае оно может быть весьма исследовательским); руководствуясь сводом идей, оформленных в виде чек листа (в данном случае подход немного более сценарный и менее исследовательский); или руководствуясь набором строгих условий, таких, как те, что используются статическими анализаторами кода (в этом случае подход будет совершенно сценарный).

Для разработчиков, тестирование (как мы помним "обследование продукта в целях его оценки") является естественным элементом парного программирования, и так как проектирование, исполнение, интерпретация и познание сильно переплетены, парное программирование есть исследовательский процесс. TDD (test-driven development) имеет сильно выраженные исследовательские черты по той же причине. В натуре, Elisabeth Hendrickson цитирует момент прояснения одного программиста: "Я понял! Это же разработка через тестирование! (TDD)". Меня аналогично осенило, когда я понял, что TDD весьма и весьма исследовательский стиль разработки.

Такая, вот, история. И тестирование, и познание, весьма расширяемый и исследовательский процесс, поэтому, вероятно, было бы неплохо нам побольше изучать, познавать и проверять в деле эти идеи.

Источник DevelopSense Blog, автор Michael Bolton

12 авг. 2009 г.

Exploratory testing: Развитие понимания об исследовательском тестировании. Часть 2


Часть 1

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

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

Для тех, кто неизбежно спросит "Чем отличается исследовательское тестирование от ad hoc тестирования?" я отвечу так, что не смогу провести различия, пока вы не объясните что вы понимаете под "ad hoc". Некоторые полагают, что "ad hoc" является синонимом "небрежный" или "поспешный" (прим. пер. - у нас чаще встречаются "свободный" и "случайный"). Исследовательское тестирование, конечно же, не поспешное и не небрежное (так же, как не случайное и не свободное, прим. пер.). Когда я смотрю в словарь, я вижу, что "ad hoc" буквально значит "к случаю", и в полном понимании "специальный, устроенный для данной цели, для данного случая". Комиссия Роджерс по Челленджеру была ad hoc-комиссией (прим. пер. - чрезвычайной?), созванная для выполнения конкретных целей и распущенная после того, как цели были достигнуты. В этом смысле, ad hoc и exploratory не такие уж и разные. Почти все выполняемое тестирование, исследовательское ли, или сценарное, будет ad hoc (специальное, для данной цели); оно выполняется для обеспечения неких целей и прекращается по мере их достижения. Таким образом, я не могу быть уверенным, что вы подразумеваете под "ad hoc" пока вы мне не скажете. Я даю здесь определение исследовательскому тестированию; вы можете сравнить его со своим представлением об "ad hoc", если хотите.

Часть 3

11 авг. 2009 г.

Exploratory testing: Развитие понимания об исследовательском тестировании. Часть 1.


Представляю вашему вниманию очередной перевод. На этот раз статья посвящена исследовательскому тестированию (exploratory testing). Тема эта весьма интересная, и, как я вижу, слабо освещенная в нашем русскоязычном сегменте. Поскольку статья немалая, выкладываю пока первую часть, всего планируется три. Отдельное спасибо Алексею Никулину за безвозмездный перевод первого абзаца :) Итак, поехали!

Одним из заметных событий конференции CAST 2008 стал доклад Кема Канера "О пользе чеклистов и опасности сценариев: что предлагает традиционная система обучения тестировщикам". Большую часть доклада заняло сравнение исследовательского и сценарного процессов, в котором Кем противопоставил сценарии - готовые пошаговые инструкции, исполняемые более или менее автоматически - машиной или человеком, заменяющим её, и чеклисты - перечисление особенностей, которые могут быть интересны, и решение об их целесообразности находится во власти человека, пользующегося этим списком. Что по мне, самое ценное в докладе было развитие сюжета о природе исследования и исследовательского тестирования. Итак, по состоянию на 21 сентября 2008 года, моя (как обычно, тесно связанная с Кема и Джеймса Баха) актуальная на данный момент версия сюжета. Еще одна из целей - возможность сослаться на этот пост, чтобы не повторяться на форумах.

По определению Джеймса:
"тестирование - это обследование продукта в целях его оценки".
По Кему, современное исследовательское тестирование это (делаем глубокий вдох:
"стиль тестирования, подразумевающий определенную свободу и ответственность конкретного тестировщика в постоянной оптимизации качества его работы, воспринимающего проектирование, выполнение , оценку результатов тестов и познание (прим. пер. - изучение продукта; накопление опыта; развитие навыков; далее - познание) как взаимодополняющие активности, которые протекают параллельно на протяжении всего проекта".
Это было определение, которое он предложил на симпозиуме Heuristic and Exploratory Techniques в Palm Bay, Флорида, в марте 2006 (в котором James Bach, Jonathan Bach, Scott Barber, Tim Coulter, Rebecca Fiedler, David Gilbert, Marianne Guntow, James Lyndsay, Robert Sabourin, Adam White, Cem и я принимали участие). Короткая версия Джеймса:
"одновременное проектирование, выполнение тестов и познание".
Оба означают одно и то же. Одно более точное, другое краткое по содержанию.

Противоположность исследовательскому тестированию - сценарное тестирование. Причем оба они не являются техниками, это подходы к тестированию. Независимо от любых других аспектов, мы называем тест более исследовательским и менее сценарным если:
  • Элементы проектирования, выполнения и оценки результатов тестов и познание выполняются одним и тем же лицом

  • Процессы проектирования, выполнения и оценки результатов тестов и познание протекают вместе, нежели раздельно во времени

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

  • Все, что познано на данный момент, включая результаты самого последнего теста, определяет какой следующий тест выберет тестировщик

  • Тестировщик ориентирован на выяснение новой информации, нежели подтверждение имеющейся

  • В целом, тестировщик предпочитает разнообразить аспекты своих тестов, нежели повторять их, если повторение теста специально не направлено на раскрытие новой информации


Часть 2
Часть 3

9 авг. 2009 г.

Вы считаете себя экспертом в тестировании?


Тогда проанализируйте следующие утверждения:
1. Я должен составлять тест-план.
2. Важно, чтобы тестирование обладало свойством повторяемости.
3. Каждый тест-кейс должен иметь ожидаемый результат.
4. Автоматизация экономит деньги и время.
5. Все тесты основываются на модели того, что должно быть протестировано.
6. Достаточно хорошее качество (good enough) недостаточно хорошее.
7. Недокументированный тест не может быть улучшен.
8. Лучше использовать термин дефект нежели баг/ошибка.
9. Exploratory testing - полезная практика.
10. Неопределенность и двусмысленность должны быть исключены из требований.

Из доклада J.Bach "Becoming a Software Testing Expert"