В самом начале было тестирование. Никто не различал сценарное и исследовательское тестирование. В 1961 году Джерри Вайнберг в книге «Основы компьютерного программирования» в главе о тестировании определил его как в основе своей исследовательское и попросил с осторожностью относиться к его формализации.
«Конечно же, сложно заставить машину определить, насколько программа соответствует поставленным программистом целям без внесения огромного пласта информации об этой цели. Если бы у нас был простой способ предоставлять машине такого рода информацию для проверки, мы с таким же успехом могли бы повесить на машину и сам процесс написания программы. Давайте не забывать о том, что сложные логические операции происходят за счет простых инструкций, которые выполняет компьютер, и это не компьютеру решать, что логично при вводе/выводе.»
Джерри понимал разницу между машинной и человеческой работой. Но затем объявились формализаторы и всех запутали. Формализаторы, официально начиная в 1972 году с публикации первой книги по тестированию «Методы тестирования программ», сфокусировались на формах тестирования, а не на его сути. Под формами мы имеем в виду слова, изображения, строки битов, файлы данных, блок-схемы и другие явные формы моделирования. Это все то, что мы можем увидеть, прочитать, на что можем указать, перенести с места на место, подсчитать, хранить, вернуть обратно и т.д. Так и подмывает взглянуть на все эти артефакты и воскликнуть «Да будет тестирование!» Но суть тестирования — не в каком-то из этих артефактов. Тестирование, на пересечении человеческих процессов мышления и реализации, позволяет применять эти артефакты. Артефакты тестирования без людей — это как больницы без врачей и медсестер, возведенные в ранг произведений искусства: в лучшем случае, от них совсем немного пользы; в худшем — они представляют опасность для тех ни в чем не повинных людей, которые решат поправить там свое пошатнувшееся здоровье.
Мы не обвиняем инноваторов. На тот момент они имели дело с новыми блестящими гипотезами. Их ограничивала лишь небесная твердь! Но формализация на пару с механизацией вскоре вырвались из лаборатории. За этим последовали безумные разговоры о «тестировочных фабриках» и спроектированные на скорую руку стандарты IEEE. Потом в «приличных» кругах заговорили о сценарно-ориентированном тестировании. Неформальное тестирование было приравнено к непрофессиональному тестированию. Роль мыслящих, чувствующих, обменивающихся информацией людей была замещена.
Джеймс влез в драку в 1987 году и попытался хоть как-то вывести толк из всего этого. Путем обычного наблюдения за процессом тестирования он обнаружил, что «ситуативное» тестирование куда лучше справлялось с отловом багов, а сценарное тестирование — нет. (Это открытие далось не так уж и просто. Мы имеем в виду, что не очевидные истины относительно тестирования могут быть доказаны всем тем, что нас окружает, когда мы откладываем фольклор в сторонку и внимательно смотрим, как люди справляются с ежедневной рутиной.) Он начал писать и говорить о своих наблюдениях. Спустя несколько лет работы тест-менеджером, когда вовсю использовались тестовые компиляторы и инструменты для разработки, он узнал, что Джем Канер придумал термин «исследовательское тестирование», чтобы показать процесс, обратный сценарному тестированию. В первоначальном определении, занимавшем всего несколько страниц, Джем едва его поскреб, но он был первым, кто заговорил о проектировании тестов во время их выполнения.
Так появилось то, что мы называем ИТ 1.0.
ИТ 1.0: Восстание
Тестирование со сценарием и без него — понятия разные. Поначалу мы были практически поглощены качеством тех идей, которые возникли во время несценарного тестирования. Когда мы проводили ИТ, мы находили больше багов. Сам процесс ощущался как качественное тестирование. Тогда мы еще не понимали, почему. Таким образом, первая итерация исследовательского тестирования как риторика и теория была нацелена на избавление от смирительной рубашки сценария, чтобы было больше месте для этого «лучшего тестирования». Мы сталкивались с аргументами о том, что «ситуативное тестирование неконтролируемо и неуправляемо, и заниматься им не стоит». Мы выступили против такого подхода, в подобном контексте исследовательское тестирование было неким особым набором действий. Таким образом, крестоносцы ИТ относились к нему как к технике, тем самым оправдывая ее использование. «Отложите в сторону ваши сценарии и посмотрите на продукт. Взаимодействуйте с ним! Ищите баги!»
Большая часть мира до сих пор рассуждает о исследовательском тестировании именно в таком ключе: как о технике и четко выраженном порядке действий. Но мы ошиблись с определением. Ведь из-за него мы загнали и исказили суть исследовательского тестирования. Сначала все было нормально, но если рассматривать ИТ как технику, то в конечном итоге можно зайти в тупик. И в наши дни многие люди, даже те, кто написал книги об исследовательском тестировании, все еще с радостью придерживаются подобного определения.
Эра ИТ 1.0 начала угасать в 1995-м. На тот момент лишь горсть людей в индустрии активно пыталась развить исследовательское тестирование в дисциплину, несмотря на то, что все тестеры неосознанно или неформально следовали ей, как и всегда. Для тех нескольких людей бросить ИТ во мраке было неприемлемо.
ИT 1.5: Толкование
В 90-х годах прошлого века зародившееся в Северной Америке небольшое сообщество тестеров (которое затем выросло во всемирное контекстно-ориентированное (context-driven) сообщество, задев немного сообщество Agile-тестирования) также боролось за четкое определение навыков и процессов, необходимых в процессе тестирования. Для этого они применили две исследовательских метода. Первым был гуманистический подход к разработке программного обеспечения, предложенный Джерри Вайнбергом, который комбинировал системное мышление с семейной философией. Вторым было оправдание когнитивной науки Джема Канера и критический рационализм Карла Поппера. Эта работа в скором времени заставила нас пересмотреть наше представление о сценарном и исследовательском тестировании. Почему? Потому что наше понимание глубинных основ самого тестирования быстро развивалось.
Когда Джеймс примкнул к ST Labs в 1995-м году, он был впервые в полной мере привлечен к развитию виденья и методологии тестирования программного обеспечения. Именно тогда они с Джемом и начали свое пятнадцатилетнее сотрудничество. Тогда же и сформировалась методология быстрого тестирования ПО. Одной из первых крупных инноваций на этом пути была направляющая эвристика (guideword heuristics) как практический способ настройки в реальном времени на тестировочное мышление с комплексной базовой моделью тестировочного процесса. Списки техник тестирования и шаблонов ведения документации еще долго были в ходу, но с общим развитием терминологии и когнитивных моделей для продвинутого тестирования программного обеспечения мы стали рассматривать исследовательское тестирование в новом свете. Мы начали сравнивать и сопоставлять важные структуры сценарного и исследовательского тестирований и связи между ними, вместо того, чтобы видеть в них подходы, которые мало чем различаются.
В 1996-м году Джеймс создал первый тестировочный класс, названный «Исследовательским тестированием». Он склонялся к разработке шаблонного подхода и пытался включить его в класс. Он определил саму компетенцию тестирования.
В этот период Джеймс еще разделял исследовательское тестирование и ситуативное тестирование, чего мы больше не делаем. ИТ — это процесс ситуативного тестирования, в разрезе терминологии: ситуативное означает «для этого; для такой-то цели». Он очень старался разделить квалифицированное и неквалифицированное тестирование, но сейчас нам известны куда более подходящие для этого способы. Теперь мы определяем неквалифицированное ситуативное тестирование как ИТ, ведь неквалифицированное приготовление пищи все так же является приготовлением пищи, а неквалифицированные (любительские) танцы танцами и остаются. Термина «исследовательское тестирование» описывает характер деятельности, которая, ко всему прочему, может быть и ситуативной.
В 1999-м году Джеймсу было поручено определить формализированный процесс исследовательского тестирования для Microsoft. Однако идея «формализированного ситуативного процесса» казалась парадоксальной, что дало начало конфликтам, которые были разрешены серией конструктивных споров между Джеймсом и Джемом. Эти дебаты привели к тому, что мы назовем ИТ 2.0.
Был также прогресс в том, чтобы сделать исследовательское тестирование более дружественным к управлению проектами. В 2000-м году, вдохновленные работой на Microsoft, Джеймс и Джон Бах разработали «Сессионное управление тестами» для отдела в Hewlett-Packard. Это была своего рода обобщенная форма процессов в Microsoft, с целью создать больший уровень учитываемости для в принципе неформальной исследовательской работы. СУТ было призвано защитить исследовательскую работу от навязчивых формализаторов, которые привыкли моделировать тестирование в рамках тест-кейсов. В каком-то смысле СУТ довольно успешно помогало людям понять, что исследовательская работа абсолютно управляема. СУТ превращало позицию «не делай этого» в «ладно, блоки исследовательского тестирования так же имеют право на существование, как и тест-кейсы.»
К 2000-му году большая часть тестировочного мира что-то да слышала об исследовательском тестировании. Мы начали превращать мир в место, безопасное для более качественного тестирования.
ИТ 2.0: Интеграция
Эра ИТ 2.0 была самой продолжительной, основанная на ключевом постулате: исследовательско-сценарный континуум.
Это шкала, по которой тестирование ранжируется от полностью исследовательского до полностью сценарного. Вся тестировочная работа укладывается в эти рамки. Приняв это, мы перестали говорить об исследовательском тестировании как о технике — это в большей мере был подход, применяемый к методикам (или, как Джем любит выражаться, «стиль» тестирования).
Мы могли размышлять о тестировании в данном ключе, поскольку, в отличии от того, что было 10 лет назад, теперь у нас сформировалось понятие о навыках и элементах, необходимых для тестирования. Это уже больше не было какое-то «созидательное и мистическое» действо, будто некоторые люди уже с рождения «интуитивно» понимали сам процесс. Мы рассматривали тестирование как уже связанные специфические структуры, модели и когнитивные процессы, а никак не исследование, потому мы решили, что можем с пользой для дела отделить исследование от тестирования. Большую часть из того, что в 90-х мы называли исследовательским тестированием, мы начали называть «вольным исследовательским тестированием».
К 2006-му году мы пришли к простому определению ИТ: это одновременное изучение, разработка тестов и выполнение тестов. Чтобы дать этой сфере импульс, Джеймс и Джем в январе организовали встречу, названную Саммитом по развитию исследовательского тестирования. Участвовали Джеймс Бах, Джонатан Бах, Скотт Барбер, Майкл Болтон, Элизабет Хэндриксон, Джем Канер, Майк Келли, Джонатан Кол, Джеймс Линдси и Роб Саборин. Готовясь к встрече, мы совершили тревожное открытие: каждый участник саммита был согласен с определением ИТ, но лишь немногие сошлись на том, что это определение означает. На тот момент мы не знали, как обозначить этот феномен, но теперь в сообществе контекстно-ориентированного тестирования его называют теневым соглашением. Чтобы бросить вызов теневому соглашению и продвинуть лучшее понимание ИТ, кое-кто из нас решил позаимствовать более запоминающееся и подробное определение, предложенное Джемом и позже имевшее несколько интерпретаций: «стиль тестирования, выделяющийся свободой и ответственностью отдельно взятого тестера за постоянную оптимизацию качества его работы во время создания тестов, их выполнения, интерпретации их результатов вместе с заранее согласованным обучением, которое проходит параллельно ходу разработки всего проекта.» Независимо друг от друга, Джон Бах и Майкл предложили «свободу и ответственность» как часть этого определения.
Таким образом, мы пришли к специфике и гибкой идее исследования и его роли в тестировании. Исследование можно рассматривать по-разному: это поиск неизведанного, творческий процесс, работа без карты, совершение действий, которые никто больше не предпринимал, сопротивление трудностям, спонтанное использование и так далее. с появлением концепции континуума (которую Джон, брат Джеймса, назвал «степенью свободы тестировщика») и обсуждениями на конференции ExTRS, мы осознали, что большинство из этих разных понятий исследования уже занимают центральную роль в тестировании. Как добавлять прилагательное «исследовательское», и как оно противопоставляется «сценарному», каждый для себя определял сам.
Все последствия нового определения стали понятны в последующие годы, а Джеймс и Майкл начали проводить обучение и давать консультации по методологии быстрого тестирования программного обеспечения. Теперь мы учитываем то, что под «исследовательским тестированием» мы отсылались к подробному, компетентному, самодостаточному тестированию. Иными словами, во всех отношениях, не касающихся средств тестирования, компетентное исследовательское тестирование мало чем отличается от компетентного сценарного тестирования. Но средства гораздо важнее документации, обдумываний, затраченного времени, инструментов, сознательных намерений. Вы можете проводить сценарное тестирование, даже не имея под рукой какого-то клочка бумаги (при сценарном тестировании не требуется буквального следования сценарию). Вы можете проводить сценарное тестирование без предварительного планирования (кто-то, продумывая идею теста, может в реальном времени говорить вам, что делать). Вы можете моментально приступать к сценарному тестированию (кто-то мог передать вам скрипт, или, возможно, вы только что дописали свой сценарий). Вы можете идти по сценарию с инструментами или без них (инструменты делают тестирование более разнообразным, но необязательно более заскриптованным). Вы вполне можете проводить сценарное тестирование даже неосознанно (возможно, вам и кажется, что у вас есть свободный выбор, но ваша модель поведения и привычки создали для вас невидимую тюрьму). Суть сценарного тестирования состоит в том, что тестировщик ничего не контролирует — в большей степени, он сам находится под контролем средств или процесса. Нам понадобились годы, чтобы прийти к этой простой, но жизненно важной идее!
В те времена мы сосредоточились на преставлении того, какие специфические навыки должны применяться при исследовательском тестировании. Джеймс и Джон Бахи создали справочник исследовательских навыков и тактик, чтобы отшлифовать специфику и тонкости для ответа на вопрос «что конкретно исследовательское есть в исследовательском тестировании?»
В 2007-м году случился еще один пускай медленный, но достаточно весомый прорыв. Началось с мелочи: частично вдохновленный книгой «Форма действия», Джеймс начал различать процессы, требующие человеческих рассуждений и здравого смысла, и те, где этого не требовалось. Он назвал их «осознанными» и «неосознанными» (вольный перевод понятий sapient и non-sapient). Для нас это стало новой вехой: систематическое изучение и развитие неявных понятий.
В 2009-м Майкл также к этому пришел, разделив тестирование и проверку. Тестирование не может быть автоматизированным, а проверка может быть автоматизированна полностью. Проверка включена в тестирование. Поначалу Джеймс возражал против этого, поскольку уже существовала концепция осознанного тестирования, и различать их не было необходимости. По его мнению, проверка была просто-напросто неосознанным тестированием. Но, несколько лет подряд применяя эти идеи во время консультаций и тренингов, мы пришли к выводу, что проверка и тестирование лучше укладываются в голове, чем осознанность и неосознанность. По той причине, что «неосознанность» звучала как «тупость»; мы будто осуждали проверку, называя ее неосознанной.
Заметили, что для емкого определения терминологии и подходов могут потребоваться годы? Это те инструменты и идеи, которые требуются нам для того, чтобы на практике принимать оптимальные решения. Но, подобно новым лекарствам, появившимся на рынке, иногда может потребоваться значительный багаж опыта, чтобы понять не только преимущества, но и потенциально опасные побочные эффекты от наших идей и терминов. Это вполне объясняет то, почему те из нас, кто уже долгое время занимается этим ремеслом, не всегда проявляют терпение к своим коллегам и клиентам, которые пожимают плечами и говорят, что «это всего лишь термины». Но для нашей деятельности подобные термины означают разницу между понятной коммуникацией, которая является основой рабочего процесса и дисциплины, и хрупким фольклором, который меняется с каждым новым роем словечек, призванных обличить в форму фантазии менеджмента.
ИТ 3.0 Нормализация
В 2011-м году социолог Гарри Коллинз принялся все для нас менять. Началось это с Майкла, прочитавшего «Умалчиваемые и неявные знания». Мы быстро подсели на ясный стиль повествования и блестящую интуицию Гарри. На протяжении многих лет он изучал ученых за работой, и его идеи о том, как происходит научный процесс идеально подходят к тому, что мы имеем на ниве тестирования.
Ознакомившись с работами Гарри и его коллег, мы поняли, как вообще говорить об умалчиваемых и неявных понятиях, что позволило нам определить, что можно, а что нельзя закодить в сценарий или другие артефакты. Он различал поведение (наблюдаемые, поддающиеся описанию аспекты деятельности) и действия (поведение с определенной целью, что, кстати, вдохновило Джеймса разделять осознанное и неосознанное тестирование). Он распутал различия между мимеоморфическими действиями (действия, которые мы хотим копировать и повторять в одном и том же виде раз за разом) и полиморфическими действиями (действия, которые мы должны каждый раз менять, чтобы справиться с социальными условиями); этим он помог определить объем и ограничения для автоматизации. Вместе с Тревором Пинчем он написал книгу о том, из чего состоит научный процесс; и еще одну, в соавторстве с Робом Эвансом — об экспертизе; еще одну — о том, как ученые решили оценивать специфические экспериментальные результаты.
Работа Гарри помогла придать структуру другим идеям, которые мы собрали по ходу дела.
- Идеи МакЛуэна о медиа и инструменах;
- Работа Карла Вика об осмыслении;
- Понятия о темпах Ванкатеша Рао, которые привели нас к понятиям о разборчивости Джеймса. С. Скотта;
- Осознание (к которому мы пришли благодаря невинному вопросу тестировщика из банка «Беркли») того, что «исследовательско-сценарный континуум» на самом деле является «формальным континуумом». Иными словами, формализировать действия означает сделать его более сценарным;
- Осознание важного различия между спонтанным и совещательным тестированием, которое лишь частично отражает то, чем занимается тестировщик;
- Концепция «ответственного тестировщика» (в значении тестировщика, который берет на себя полную и персональную ответственность за качество своей работы);
- Появление важного различия между проверкой и тестированием, которое заменило необходимость говорить об «осознанности»;
- Последующее переопределение термина «тестирование» в глоссарии быстрого тестирования программного обеспечения, чтобы сделать его более наглядным.
О последнем пункте
ИТ 3.0 — понятие немного парадоксальное, поскольку то, чем мы занимаемся в рамках методологии быстрого тестирования ПО, отправляет на пенсию термин «исследовательское тестирование».
Да, все верно, спустя 22 года мы отправили этот термин на пенсию. Почему?
Потому что сейчас мы определяем любое тестирование как исследовательское. Теперь определение тестирования звучит так:
Тестирование — это процесс оценки продукта путем его изучения через исследование и экспериментирование, что включает в себя: опрашивание, проработку, моделирование, наблюдение, заключение, исходящую проверку и т.д.
Подходит ли сценарное тестирование под данное определение? Под «сценарием» мы имеем в виду любую контрольную систему или фактор, который влияет на ваше тестирование и находится вне сферы вашего выбора (пускай даже временно). Это не относится тоько лишь к получаемым вами определенным инструкциям, которым вам приходится следовать. Ваши склонности загоняют вас в сценарий. Как и ваше неведение. Сама организация рабочего процесса также является сценарием. Выбор действий, который вы совершаете и никогда не пересматриваете — тоже сценарий.
Определив тестирование как процесс исследовательский, мы переводим сценарий в разряд гостей в нашей мастерской; потенциально полезный, но чужеродный элемент тестирования, о котором интересно рассуждать и применять в качестве тактического маневра в определенных ситуациях. Хороший тестировщик не должен пренебрегать сценариями, равно как и дровосек не пренебрегает сложной техникой. Это вам либо поможет, либо уничтожит, серьезные профессионалы такое не игнорируют.
Вы занимаетесь тестированием? Значит, вы уже занимаетесь исследовательским тестированием. Проводите сценарное тестирование? Если вы проводите его ответственно, то вы также занимаетесь исследовательским тестированием со сценариями (и, возможно, с проверкой). Если вы проводите только «сценарное тестирование», значит, вы попросту проводите немотивированную проверку, и вполне можно утверждать, что в действительности вы не тестируете. Вы пытаетесь вести себя как машина, а не как ответственный тестировщик.
ИТ 3.0 — это, своего рода, понижение должности сценария до техники и повышение исследовательского тестирования к просто тестированию.
Данный материал является переводом статьи Джеймса Баха и Майкла Болтона.
