Home

Авторы: Джеймс Бах, Майкл Болтон

Оригинал: http://www.satisfice.com/blog/archives/1509

Перевод: Ольга Алифанова

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

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

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

Джеймс Бах ввязался в этот бой в 1987 году и попытался разложить ситуацию по полочкам. Наблюдая процесс тестирования, он обнаружил, что ad hoc тестирование хорошо работает для поиска багов, а сценарное – нет (Примечание: Мы не пытаемся показать, что обнаружить это было легко и просто. Мы хотим сказать, что неочевидные истины тестирования присутствуют вокруг нас, и их можно осознать, если отложить фольклор о моделях и сценариях и присмотреться к тому, как на самом деле работают люди). Джеймс начал рассказывать о своем опыте и писать о нем. Когда он проработал тест-менеджером несколько лет (в основном тестируя компиляторы и другие инструменты разработки), до него дошла информация, что Кем Кэнер придумал термин "исследовательское тестирование" как антоним сценарного. В своей небольшой статье Кем не дал точного определения и только кратко наметил суть понятия, но он был первым, кто заговорил о создании тестов во время их исполнения.

Так появилось то, что мы называем "Исследовательским тестированием 1.0".

ИТ 1.0: Восстание

Тестирование со сценариями и без – это очень разные вещи. Во-первых, нам импонировало качество идей, появляющихся у нас во время исследовательского тестирования. Нам удавалось находить больше багов, и обнаруживать более качественные баги, и мы чувствовали, что тестируем лучше. Однако мы еще не поняли, почему это так. Поэтому первая итерация “теории исследовательского тестирования” фокусировалась на побеге из смирительной рубашки сценариев и создании пространства для этого "более качественного тестирования". Мы сталкивались с аргументом "ad hoc тестирование невозможно проконтролировать, им нельзя управлять, поэтому им не следует заниматься". Мы сопротивлялись и пытались сломать этот стереотип, и в этом плане исследовательское тестирование стало совершенно особым видом деятельности. Первопроходцы исследовательского тестирования относились к нему как к технике и отстаивали ее достоинства: "Отбросьте свои сценарии и посмотрите на продукт! Взаимодействуйте с ним! Ищите ошибки!".

Большая часть мира до сих пор думает об исследовательском тестировании как о технике и виде деятельности. Но мы были неправы, определяя его таким образом. Этот подход изолирует ИТ и представляет его в ложном свете. Для начала это было неплохо, но продолжать размышления в этом ключе – значит зайти в тупик. Однако многие тестировщики, даже авторы книг об ИТ, вполне удовлетворены такой постановкой вопроса.

Эра ИТ 1.0 пошла на спад в 1995 году. К этому моменту в отрасли осталось всего несколько человек, активно пытающихся сформировать исследовательское тестирование как отдельный вид деятельности, несмотря на то, что все тестировщики бессознательно или неофициально использовали его, используют и будут использовать. Защитники ИТ считали, что это недостаточные основания для того, чтобы перестать говорить о нем.

ИТ 1.5: Объяснение

В конце девяностых небольшое сообщество тестировщиков Северной Америки (которое позднее разрослось до международного сообщества Контекстно-Управляемого Тестирования, с некоторыми пересечениями с сообществом Agile-тестировщиков) тоже пыталось проникнуть в  суть навыков и мыслительных процессов, формирующих работу тестировщика. Участники сообщества разрабатывали две основных теории – гуманистический подход Джерри Вайнберга, объединяющий системное мышление и семейную психологию, и когнитивистику с критическим рационализмом Поппера, которую отстаивал Кем Кэнер. Их исследования вскоре заставили нас пересмотреть наши взгляды на сценарное и исследовательское тестирование, так как наше понимание первооснов тестирования быстро обогатилось.

Присоединившись к ST Labs в 1995 году, Джеймс впервые стал полноценным участником разработки видения и методологии тестирования. Так началось его пятнадцатилетнее сотрудничество с Кемом, и стартовала разработка методологии Rapid Software Testing. Одной из первых крупных инноваций на этом пути было введение понятия “эвристики ключевых слов” как практического способа объединить два аспекта: с одной стороны - реальный процесс мышления тестировщика, а с другой - лежащую в основе этого процесса детализированную модель тестирования. Списки техник тестирования и образцов документации существовали уже много лет, но после разработки словаря и когнитивных моделей для квалифицированного тестирования мы увидели исследовательский подход в новом свете. Мы начали сравнивать и противопоставлять основные структуры сценарного и исследовательского тестирования и взаимоотношения между ними вместо того, чтобы просто рассматривать их как разные по ощущениям виды деятельности.

В 1996 году Джеймс запустил свой первый тренинг по исследовательскому тестированию. Познакомившись с концепцией мышления при помощи шаблонов (design pattern thinking), он попытался использовать эту методику в программе обучения. Также он определил и ввел в курс обучения компетенции тестировщика.

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

В 1999 году Джеймсу поручили разработать формализованный процесс исследовательского тестирования для Microsoft. Идея "формального ad hoc тестирования" казалась парадоксальной и спровоцировала конфликт, который был разрешен путем конструктивных споров между Джеймсом и Кемом. Эти дебаты повлекли за собой рождение концепции, которую мы определяем как ИТ 2.0.

Исследовательское тестирование также стало более дружественным для проектного управления. В 2000 году Джеймс и Джон Бах, вдохновившись работой в Microsoft, разработали сессионный тест-менеджмент (Session-based test management) для рабочей группы в Hewlett-Packard. В каком-то смысле они обобщили подход, используемый Microsoft, с целью привязать отчетность к неформальной исследовательской работе. SBTM предназначался для защиты исследовательского тестирования от критики маниакальных формализаторов, привыкших моделировать тестирование через тест-кейсы. В каком-то смысле SBTM добился большого успеха, заставив людей осознать, что исследовательское тестирование может быть полностью контролируемым в управленческом плане. SBTM изменил отношение людей к ИТ: из "не делайте этого" оно превратилось "да, время, отведенное на исследовательское тестирование – это такая же задача, как и выполнение тест-кейса".

К 2000 году большая часть мирового сообщества тестировщиков уже имела некоторое представление об исследовательском тестировании. Мы начали делать мир тестирования лучше.

ИТ 2.0: Интеграция

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

Мы смогли воспринять тестирование таким образом, так как за прошедшие десять лет приобрели глубокое понимание навыков и элементов тестирования. Оно перестало быть неким "креативным и загадочным" умением, с которым рождаются. Мы увидели тестирование как комплекс определенных структур, моделей и когнитивных процессов, помимо исследовательского, и решили, что можем отделить исследовательский подход от тестирования в более осмысленном ключе. То, что мы назвали "исследовательским тестированием" в девяностых, стало называться "свободным (freestyle) исследовательским тестированием".

К 2006 году мы освоились с простым определением исследовательского тестирования как одновременного изучения продукта, тест-дизайна и выполнения тестов. В январе 2006 года Джеймс и Кем организовали встречу (Саммит по изучению исследовательского тестирования - Exploratory Testing Research Summit, ExTRS), целью которой было развить эту теоретическую область далее. В саммите приняли участие Джеймс Бах, Джонатан Бах, Скотт Барбер, Майкл Болтон, Элизабет Хендриксон, Кем Кэнер, Майк Келли, Джонатан Кол, Джеймс Линдси и Роб Сабурин. Во время подготовки к саммиту мы сделали тревожное открытие: все без исключения участники соглашались с определением ИТ, но никак не могли прийти к согласию, что же это определение на самом деле означает. В то время у нас не было названия для этого феномена (сейчас он определяется как поверхностное согласие в сообществе контекстного (context-driven) тестирования). Чтобы побороть эту поверхностность и прийти к лучшему пониманию исследовательского тестирования, некоторые из нас решили принять за основу более выразительное и наглядное определение, изначально предложенное Кемом и подправленное остальными участниками: "стиль тестирования, придающий особое значение свободному подходу и ответственности каждого тестировщика за постоянную оптимизацию качества его работы за счет восприятия тест-дизайна, выполнения тестов и интерпретации результатов тестирования, как взаимодополняющих видов деятельности, параллельно существующих на протяжении всего проекта". Джон Бах и Майкл, независимо друг от друга, предложили сделать упор в определении на "свободный подход и ответственность".

Итак, мы пришли к конкретному и детализированному определению исследования и его роли в тестировании. Исследование несет в себе множество смыслов: поиск пределов, креативность, работа без схем и плана, деятельность, которой никто раньше не занимался, противостояние сложностям, спонтанные действия, и т. д. С появлением концепции континуума (брат Джеймса Джон называет его "шкалой свободы тестировщика), а также после обсуждений на саммите ExTRS мы осознали, что множество из этих входящих в ИТ понятий уже характерны для тестирования. Что добавляет к "тестированию" определение "исследовательское"? Уровень контроля над процессом. Самостоятельный контроль над тестированием – вот то, что отличает исследовательский подход от сценарного.

Вся глубина нового определения стала проясняться в последующие годы, когда Джеймс и Майкл преподавали и консультировали по методологии Rapid Software Testing. Сейчас мы признаем, что определяя "исследовательское тестирование", мы старались определить глубокое, компетентное тестирование, контролируемое тестировщиком. Другими словами, только уровень контроля отличает квалифицированное исследовательское тестирование от квалифицированного сценарного. Только контроль! А не преднамеренность, не документация, не потраченное время, не инструменты, не сознательное стремление. Вы можете тестировать по сценариям, не имея под рукой даже обрывка бумаги (сценарное тестирование не означает, что вы буквальным образом идете по предписанным шагам). Вы можете тестировать по сценариям без всякого плана (кто-то другой может указать вам, что делать, когда его осенило соответствующей идеей). Вы можете неожиданно приступить к сценарному тестированию (кто-то дал вам сценарий, или вы только что придумали свой). И тестировать по сценариям можно как с инструментами, так и без них (инструменты изменяют процесс тестирования, но необязательно в сторону более сценарного подхода). Вы можете заниматься тестированием по сценариям даже бессознательно (возможно, вам кажется, что у вас есть свобода выбора, но избранные модели и привычки стали вашей тюрьмой). Суть сценарного тестирования в том, что тестировщик не контролирует процесс – его контролирует другой участник проекта или какой-либо иной процесс. Нам понадобились годы, чтобы осознать эту простую, жизненную идею!

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

В 2007 году готовился новый, постепенно назревающий прорыв. Он начался с малого: частично вдохновившись книгой "The Shape of Actions", Джеймс провел черту между процессами, которые требовали человеческого вмешательства и мышления, и теми, которые их не требовали. Он разделил их как "относящиеся к знанию" и "не относящиеся". Это повлекло за собой новый этап для нас: систематическое изучение неявных знаний о тестировании.

В 2009 году Майкл вслед за Джеймсом разделил тестирование и проверку. Тестирование не автоматизируется, а проверки могут быть автоматизированы полностью, при этом проверка – часть тестирования. Джеймс возразил, что это лишнее деление, так как концепция тестирования, требующего знаний, уже существовала. Для него проверка была просто "не относящимся к знанию" тестированием. Однако спустя несколько лет, потраченных на испытаниенаших идей в процессе консультирования и обучения, мы обнаружили, что “проверка” и “тестирование” проще для восприятия, чем "относящееся” и “не относящееся к знанию" тестирование. "Не относящееся к знанию" звучит как "глупое", как приговор проверкам.

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

ИТ 3.0: Нормализация

В 2011 году социолог Гарри Коллинз перевернул наш мир. Майкл прочитал книгу "Явное и скрытое знание" (Tacit and Explicit Knowledge), и мы были покорены блестящей логикой и пониманием автора. Гарри провел много лет за изучением работы ученых, и его представления о том, как происходит мыслительный процесс ученого, мало отличался от наших представлений о работе тестировщика.

Изучая работы Гарри и его коллег, мы уяснили разницу между скрытым и явным знанием – и, в свою очередь, поняли, что именно можно и нельзя закодировать как сценарий или любой другой артефакт тестирования. Гарри разделяет поведение (которое можно наблюдать и описывать) и деятельность (намеренные поведенческие склонности) – это и привело Джеймса к водоразделу между требующим и не требующим знания тестированием. Гарри подчеркнул различия между мимеформическими действиями (которые мы повторяем единообразно) и полиморфическими (адаптируемыми под ситуацию) – и, следовательно, внес большой вклад в определение границ автоматизации тестирования. Он написал книгу в соавторстве с Тревором Пинчем про конструирование научного знания; другую книгу вместе с Робом Эвансом, про опыт; и третью о том, как ученые оценивают отдельные результаты экспериментов.

Работы Гарри помогли структурировать собранные нами идеи:

• Идеи МакЛюэна про средства и инструменты.

• Работу Карла Уайка про создание смысла.

• Мнение Венкатеша Рао о времени, познакомившее нас со взглядами Джеймса С. Скотта на четкость.

• Осознание, что исследовательско-сценарный континуум на самом деле – континуум формальности. Другими словами, формализация деятельности придает ей менее исследовательский и более сценарный характер.

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

• Концепцию "ответственного тестировщика", берущего на себя всю полноту ответственности за качество своей работы.

• Проведение водораздела между проверкой и тестированием, избавившее нас от необходимости говорить о "разумности" в риторике тестирования.

• Последующее переопределение термина "тестирование" в методологии Rapid Software Testing, чтобы подчеркнуть вышеописанные свойства тестирования.

Про последний пункт в списке

ИТ 3.0 – немного парадоксальное название, так как мы, в рамках методологии Rapid Software Testing, работаем над аргументами против термина "исследовательское тестирование".

Да, спустя 22 года мы объявляем это понятие устаревшим. Почему?

Потому что теперь мы определяем любое тестирование как исследовательское.

Актуальное определение тестирования для нас:

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

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

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

Вы тестировщик? Значит, вы уже занимаетесь исследовательским тестированием. Вы тестируете по сценариям? Если вы ответственно подходите к процессу, вы занимаетесь исследовательским тестированием при помощи сценариев (и, возможно, проверок). Если вы занимаетесь только сценарным тестированием, то вы на самом деле немотивированно проверяете, а не тестируете по-настоящему. Вы ведете себя как автомат, а не как ответственный тестировщик.

Исследовательское тестирование 3.0 определило сценарии как технику, а исследовательское тестирование – как любое настоящее тестирование.