Home

Так получилось, что завершение перевода этой статьи Майкла Болтона удачно совпало с появлением на хабре заметки Натальи Руколь «Почему тестирование — это тупо и скучно?», которая вызвала достаточно бурное обсуждение. Эта статья призвана в какой-то степени объяснить, почему одним тестирование кажется скучным, а для других людей это самое интересное занятие в мире.

Когда мне было лет двадцать с небольшим, я решил, что если я хочу быть всесторонне образованным молодым человеком (и привлекательным для девушек), неплохо было бы научиться вкусно готовить. Как и большинство молодых людей, я не собирался тратить много времени и усилий на кухне, но при этом хотел производить впечатление. Кроме того, я хотел уметь готовить как из скромного набора продуктов своего холостяцкого холодильника, так и находясь на неисследованной территории чужой кухни. Один из моих стандартных приемов изучения нового – прийти в книжный магазин и порыться в книгах. Так я и сделал, и после недолгих поисков наткнулся на книгу «Гурман за 60 минут» Пьера Фрейни. «Отлично!», — подумал я.

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

Каждый рецепт включал основное блюдо и сопутствующий гарнир, не только радовавший глаз и вкус, но и балансировавший питательность блюда. Вдобавок каждый рецепт начинался с такого захватываюшего вступления, что даже когда я не был заинтересован в приготовлении этого блюда, меня увлекали истории мистера Фрейни и его знания о блюде. Прочитав всего лишь несколько страниц, я выучил массу новых вещей. Блюда так изящно дополняли друг друга, что хотя поначалу я и не уловил этого, постепенно я начал распознавать некоторые шаблоны. Ряд историй касался импровизации, многие начинались с того, что неожиданно нагрянули гости, и мистеру Фрейни приходилось создавать новое блюдо из тех немногих ингредиентов, которые были в полупустом холодильнике.

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

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

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

Итак, что же нам делать, если у нас нет навыков? Учиться. В отличие от продавцов гамбургеров, большинство из нас имеет возможность влиять на качество результатов своего труда. Мы можем использовать наше время и свободу для улучшения наших навыков и нам не нужно разрешения ни от кого, кроме нас, чтобы сделать это.

В следующих статьях я покажу вам, как развивать навыки. Особо я сосредоточусь на навыках, которые Джеймс Бах и я называем «быстрое тестирование» (Rapid Testing). Мы будем говорить о тех навыках, которые вытекают из критического, научного, системного мышления, эвристик и быстрого обучения. Эти навыки помогают нам оценить среду, в которой мы тестируем, определить, что необходимо нам для того, чтобы удовлетворить наших клиентов, задать важные вопросы о продукте, и выбрать и применить подходящие техники, чтобы ответить на эти вопросы – и все это с максимально возможной скоростью.

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

Если у тестировщика есть навыки, он начнет с выяснения у вас цели своей работы. После этого он начнет действовать независимо, но в нужном направлении. Если спецификация нечеткая или недоступна, он сможет сделать разумные заключения о продукте, проведя быстрое нацеленное исследование. Он выберет и разработает тесты, выявляющие риски, и поможет вам ранжировать их по важности. Не ограничиваясь спецификацией как единственным источником информации, он сможет найти и другие источники, которые помогут выявить проблемы. Выполняя функциональные тесты, он будет уделять внимание и другим критериям качества – удобству и простоте использования (usability), производительности, надежности, тестопригодности. Он даст вам быстрый ответ, его отчет будет чётким и достоверным. Вместо того чтобы думать об абстрактном «пользователе», он создаст набор различных профилей пользователей. Он взглянет на продукт как на часть более крупной системы и будет думать о целях тестирования достаточно широко.

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

В следующих статьях мы сосредоточимся на критическом мышлении, эвристиках, оракулах и покрытии, а также на развитии навыков и техник, которые позволят нам думать и рассуждать об этих самых оракулах, эвристиках и покрытиях быстро, но полно. Почему? Потому что так же, как и приготовление еды, тестирование – это то, что мы делаем для удовлетворения нужд других людей. Вы хотите быть шеф-поваром тестирования, разумно использующим доступные инструменты и ингредиенты, или только лишь парнем, который сидит за стойкой, переворачивая «тестбургеры»?

Об авторе

Майкл Болтон является одним из наиболее активных евангелистов школы контекстно-ориентированного тестирования. Он имеет более чем 20-летний опыт работы в области тестирования. Майкл регулярно выступает на конференциях, проводит тренинги и семинары, с 2005 года является постоянным колумнистом одного из самых популярных журналов в области тестирования Better Software (где и была впервые опубликована вышеприведённая статья) и ведёт замечательный блог о тестировании www.developsense.com/blog.shtml

17-18 ноября Майкл Болтон проведёт в Санкт-Петербурге двухдневный тренинг «Rapid Software Testing», разработанный им совместно с Джеймсом Бахом. Подробности тут: http://software-testing.ru/events/1094-rapid-software-testing

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