Home

Автор: Джеймс Виттейкер (James Whittaker)
Перевод: Феликс Зинатуллин (часть 1), Алексей Баранцев (часть 2 и общее редактирование), Алекс Сергеев (части 3 и 6), Андрей Адеркин (части 4, 5 и 7) и Роман Твердохлебов (часть 8)

Оригинальная публикация

Совместными усилиями участников Клуба тестировщиков мы сделали перевод серии заметок Джеймса Виттейкера под названием «The Future of Testing». Эта серия в оригинале была опубликована в конце 2008 года, и в ней Джеймс сделал ряд предсказаний относительно того, как будет выглядеть работа тестировщиков в будущем, лет через 10-20. Его прогнозы во многом основаны на тех идеях, которые развивались и продолжают развиваться в компании Microsoft, где Джеймс работал в то время.

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

1. «Тестсорсинг»
2. Виртуализация
3. Информация
4. Перемещение тестирования к началу
5. Визуализация
6. Культура тестирования
7. Тестировщики в роли дизайнеров
8. Тестирование после релиза

Итак, перед вами – будущее тестирования.

1. «Тестсорсинг»

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

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

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

Таким образом, первые два поколения тестирования выглядят следующим образом:

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

Это даёт нам третье поколение:

А что же дальше? Существует ли агрессивный ген, прячущийся глубоко в ДНК нашей дисциплины, который заставит краудсорсинг развиться во что-то еще лучшее? Я думаю – да, хотя для этого могут потребоваться годы и несколько технологических скачков. Я выдумаю новый термин сейчас, исключительно для того, чтобы как-то назвать эту новую концепцию: тестсорсинг.

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

2. Виртуализация

Для того, чтобы тестсорсинг смог появиться, должны быть преодолены два ключевых технологических барьера: повторное использование тестовых артефактов и доступность пользовательских окружений. Позвольте мне объяснить, что это такое:

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

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

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

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

Кроме того, виртуализация также обеспечивает тестировщикам доступ к пользовательским окружениям. Пользователь может в один клик превратить свой компьютер в виртуальную машину и передать её тестировщикам или сделать общедоступной «в облаке». Сейчас мы уже можем хранить все существующие в мире видеоматериалы так, что они доступны для просмотра каждому из любой точки, почему бы нам не сделать то же самое с пользовательскими окружениями? Технологии виртуализации уже готовы к использованию (для персональных компьютеров) или почти готовы (для мобильных или специализированных устройств). Нам просто надо научиться применять их для решения задач тестирования.

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

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

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

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

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

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

3. Информация

Итак, мы подошли к моему третьему предсказанию, которое относится к информации и к тому, как тестировщики будут использовать её для улучшения тестирования в будущем.

Какую информацию мы используем, когда тестируем программы? Спецификации? Руководство пользователя? Предыдущие (или конкурирующие) версии? Исходный код? Анализ сетевых протоколов? Мониторинг процессов? Помогает ли эта информация и насколько легко ее использовать?

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

Отличную идею, как представить информацию для тестирования, я нашел в видео играх. В играх мы очень близко подошли к совершенству в способах предоставления и использования информации. Чем больше информации об игре, игроках, препятствиях, окружении – тем лучше вы играете и можете достигнуть более высоких результатов. В видео играх эта информация выводится на специальную информационную панель, называемую HUD, или head up display. Вся информация об оружии, здоровье и возможностях игрока видна и доступна для мгновенного использования. Точно так же доступна информация о текущем местоположении игрока в виде мини-карты и информация об оппонентах (мой сын играл в Pokémon, в котором имелся доступа к Pokédex, где можно было получить информацию о всех видах покемонов, существующих в игре… Я бы хотел иметь такой Bug-é-dex, содержащий информацию обо всех багах, которые могут мне встретиться). Идея очень проста: чем больше информации ты можешь получить и использовать, тем выше шансы на успех в игре.

Я бы очень хотел добиться того же для тестировщиков: дать им больше информации, чтобы увеличить успешность их работы. Но большая часть тестирования в мире завязла в чёрном ящике без хорошей информационной инфраструктуры. Где же наша мини-карта, которая показывает, что мы тестируем сейчас и как это связано со всей системой. Было бы здорово, если бы я мог навести курсор на элемент пользовательского интерфейса и увидеть исходный код или список свойств, реализованных в этом элементе (и которые я могу протестировать)? Если я тестирую API, то почему я не могу увидеть список комбинаций параметров, которые я и мои товарищи уже проверили? Мне нужно получать эту информацию оперативно, в лаконичной и удобной для восприятия форме, помогающей мне тестировать, вместо того, чтобы бродить в поисках нужной информации по сайту, сделанному в SharePoint, или по базе данных, полной несвязанных друг с другом проектных документов. Это меня только отвлекает. Я хочу видеть это прямо перед собой!

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

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

А в будущем сможем. Это будущее будет сильно отличаться от настоящего с его информационным голодом, в котором нам приходится сейчас работать.

4. Перемещение тестирования к началу

В тестировании существует разрыв, который «разъедает» качество, продуктивность, общую управляемость всего жизненного цикла разработки. Это временной интервал между тем моментом, когда дефект внесён в систему, и моментом, когда этот дефект обнаружен. Чем длиннее этот интервал, тем более продолжительное время дефект находится в системе. Очевидно, что это плохо, но рассуждения о том, что чем дольше дефект находится в системе, тем дороже обходится его исправление, должны остаться в прошлом.

В будущем мы должны устранить этот разрыв полностью.

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

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

Давайте рассмотрим их по порядку, начиная с «тестирования ранних артефактов разработки». На последней линии обороны мы применяем к исполнимому коду программы различные стратегии поиска дефектов, используя внешние (публичные) интерфейсы программы. Мы берем скомпилированную программу или комплект библиотек, цепляем их к нашему тестовому окружению, и издеваемся над ними, используя различные входные параметры и данные, до тех пор, пока не разыщем определенное количество багов, чтобы иметь хоть какую-то уверенность, что качество достаточно высокое. Но зачем ждать, пока будут готовы бинарники? Почему мы не можем применить эти методы тестирования к архитектурным артефактам? К требованиям и user stories? К спецификации и дизайну? Как такое случилось, что все технологии, техники, знания, собранные за последние полвека, применяются только к исполняемому артефакту? Почему архитектуру нельзя тестировать таким же способом? Почему мы не можем применить то, что знаем, к дизайну и user stories? Ответ таков: нет никаких веских причин, из-за которых мы не можем этого сделать. Я уже сейчас вижу, что многие прогрессивные группы в Microsoft применяют методы раннего тестирования, а в будущем, надеюсь, мы придумаем, как делать это коллективно. Тестирование будет начинаться не тогда, когда появится что-то тестируемое, как это происходит сейчас, а тогда, когда существует что-то, нуждающееся в тестировании. Это тонкое, но важное различие.

«Ранняя компиляция» — это вторая часть, но ее реализация представляет собой технологический барьер, для преодоления которого необходим скачок. Сейчас мы пишем программу компонент за компонентом, и не можем собрать систему целиком до тех пор, пока не будет готова каждая её часть. Это означает, что тестирование вынуждено дожидаться, пока все компоненты достигнут определенного уровня завершённости. Баги могут находиться в программе на протяжении дней и недель до того момента, как тестирование отправится на их поиски. Можем ли мы заменить недописанные компоненты виртуальными? Или заглушками, которые имитируют поведение компонента с точки зрения внешнего наблюдателя? Можем ли мы создать компоненты-хамелеоны общего назначения, которые будут изменять свое поведение, чтобы соответствовать системе, в которую они (временно) встроены? Я предполагаю, что можем, потому что... мы должны это сделать. Виртуальные компоненты и компоненты-хамелеоны позволят тестировщикам применить своё искусство обнаружения багов сразу же после того, как баг создан. У ошибок будет мало шансов прожить дольше первого вздоха.

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

5. Визуализация

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

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

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

К сожалению, это не наш мир. Нас постоянно мучают вопросы «сколько осталось до завершения?», «какие задачи не выполнены?». Это проблема, которую будут решать тестировщики 21-го века.

Архитекторы и разработчики уже занимаются ей. Visual Studio содержит большое количество схем и визуализаций – от диаграмм последовательностей до графов зависимостей. Тестировщики тоже уже решают эту проблему. Внутри стен «империи» уже существуют системы визуализации для просмотра изменений кода в Xbox (объекты, код которых изменился, при рендеринге подсвечиваются зеленым, а после тестирования подсветка исчезает), для определения недостаточно тщательно протестированных сложных участков кода Windows (тепловые карты, показывающие соотношение покрытия кода и сложности кода, выполненные в трехмерном пространстве, позволяют обнаружить проблемные области). Эти визуализации выглядят впечатляюще, они красивы и позволяют тестировщикам с одного взгляда определить, что именно нуждается в тестировании.

Нам нужно больше подобных визуализаций, но к этой задаче нужно подходить осторожно. Мы не можем просто принять диаграммы, предоставленные группами UML и моделирования. Эти визуализации предназначены для решения других проблем, которые могут совпадать, а могут и не совпадать с теми, которые встречаются у нас. Многие из существующих визуализаций созданы, чтобы помогать архитекторам или разработчикам, но их потребности отличаются от наших. Мы должны думать об этом с позиций тестировщиков. Нам нужны визуализации, которые связывают требования с кодом, тесты с интерфейсами, изменения в коде с пользовательским интерфейсом, покрытие кода с элементами управления. Разве не здорово, когда запускаешь тестируемое приложение и видишь, что элементы управления «светятся» с интенсивностью, которая отражает тестовое покрытие или количество тестов, в которых они были задействованы? Или было бы очень неплохо видеть анимированный график использования сети или взаимодействия с базой данных в реальном времени? Почему мы не можем увидеть сетевой трафик или SQL запросы сразу же? Мы не видим многое из того, что скрыто внутри нашего приложения, и пришло время вытащить это на поверхность и использовать для повышения качества программы.

Эта задача может быть решена в ближайшем будущем, и над ней работает много умных людей.

Это тестирование программ в ярких красках.

6. Культура тестирования

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

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

— Джеймс, – ( надо же, он моё имя знал!) – я вижу, что у Вас есть какие-то сомнения относительно моего проекта или продукта, про который я рассказывал. Я хотел бы услышать Ваше мнение.

— Нет, никаких проблем ни с Вашим продуктом, ни с проектом. Мои сомнения касаются Вас.

— Простите?

— Такие люди, как вы, пугают меня, – сказал я, – Вы тратите все своё время на мечты о новых возможностях и путях использования, Вы проектируете интерфейсы и протоколы. Вы важный человек, и люди прислушиваются к Вам и делают то, о чем Вы мечтаете. Но вы делаете всё это, не имея ни малейшего понятия о тестировании.

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

Но это совершенно не то, что нужно.

Привлечь тестировщика к проектированию продукта лучше, чем не делать этого вообще. Но не сильно лучше. Тестировщики будут обращать основное внимание на вопросы тестопригодности. Разработчики на возможность реализации. А кто учитывать оба аспекта? Кто будет решать, кто прав, и когда нужно идти на компромисс? Никто. Привлечение тестировщика к проектированию дает лишь незначительное улучшение; привлечение проектировщиков (и всех остальных участников) к тестированию – вот будущее.

Серьёзно, ну почему люди, которые создают программы, так мало смыслят в тестировании? И почему мы не делали попыток это изменить? Может быть мы, тестировщики, слишком укоренились в своей роли и теперь ревностно охраняем ключи от нашего интеллектуального царства? Неужели тестирование настолько полно тайн и загадок, что разработчики не могут его постигнуть? А может быть разработчики привыкли сваливать эту «не очень-то интересную» часть работы на нас и воспринимают теперь это как должное?

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

Нынешняя культура тестирования и разделение ролей порочны, и правильный путь – в объединении ролей. Качество должно быть работой каждого. Думайте об этом в терминах Толкиена: одна роль, чтоб править всеми!

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

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

Тестирование играет слишком важную роль, чтобы «плестись в хвосте» процесса разработки. Проектные решения, важные с точки зрения тестирования, принимаются уже на ранних стадиях, и именно тогда тестирование должно начинаться. Нельзя также отдавать тестирование в руки единственной выделенной роли, отвечающей за качество. Напротив, нам необходимы такие культурные изменения, которые сделают качество работой каждого, и принципы тестирования проникнут во всё, что мы делаем.

7. Тестировщики в роли дизайнеров

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

Но всё меняется, и это тоже скоро изменится, потому что это должно измениться. Мой друг Роджер Шерман (первый корпоративный директор по тестированию в Microsoft) описывает это изменение, сравнивая тестирование с гусеницей, которая становится бабочкой. По словам Роджера, бабочка, которая должна получиться из тестирования – это дизайн.

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

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

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

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

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

Работа в начале конвейера определённо отличается от того, чем мы занимаемся сейчас , и это то место, где многие и многие тестировщики будут находить своё место по мере того, как будущее становится настоящим.

8. Тестирование после релиза

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

Я был в группе Windows, когда выпускалась Vista, и вспоминаю, как показывал ее как-то вечером дома своему тогда восьмилетнему сыну. Он много играет (и работает, если вы можете в это поверить) на компьютере, и ему очень понравился интерфейс Aero, симпатичные гаджеты на боковой панели, а скорость, с которой работали его любимые игры (в то время это были Line Rider и Zoo Tycoon), по-настоящему его впечатлила. Я еще подумал: «Как жаль, что он не ведет отраслевой блог», но я отвлекся от темы.

Так вот, в конце он задал мне вопрос, внушающий страх каждому тестировщику: «Папа, а что здесь сделал ты?»

Я замолчал, что довольно необычно для меня, и пробормотал что-то невразумительное. Как вы объясните восьмилетнему ребенку, что вы работали над чем-то несколько месяцев (я только начал работу в Microsoft и присоединился к работе над Vista в самом конце), но фактически ничего не сделали? Я попытался обойтись стандартными ответами на этот страшный вопрос (восклицательные знаки обязательны, они помогают мне убедить себя, что в моих словах есть доля правды):

«Я работал над тем, чтобы сделать ее лучше!»

«То, что она работает так, как она работает… это благодаря мне!»

«Если бы не мы, тестировщики, она была бы угрозой для общества!»

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

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

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

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

Что если тот самый бедолага сможет запускать дополнительные тесты и пользоваться всеми преимуществами тестовой инфраструктуры, которая существовала до выпуска продукта? Что если он сможет установить исправления и запустить регрессионное тестирование в том окружении, в котором произошел сбой? Что если он сможет установить обновления в эксплуатационную среду и попросить приложение провести регрессионное тестирование себя?

Бедолагой он не будет, это точно. Но поскольку тестирование и тестовые артефакты теряются после финальной сборки и поставки продукта, сейчас это невозможно.

Чтобы достигнуть таких возможностей, приложение должно сохранять данные предварительного тестирования и всегда иметь их при себе. А это означает, что возможность самотестирования станет одной из основных особенностей программного обеспечения будущего. Наша работа будет заключаться в том, чтобы найти способ включения нашей «магии» тестирования внутрь самого продукта. А нашей наградой будет радость от того, как сияют глаза наших детей, когда они увидят, что самая первоклассная особенность продукта — та, которую мы спроектировали!

Ах да, насчет хакеров и поборников конфиденциальности: не бойтесь! Хью Томпсон и я уже давно предупреждали о включении тестового кода в поставку (см. главу Атака №10 в книге «Как взломать программную защиту»). Поскольку мы знаем, как осуществить взлом, мы имеем шансы сделать всё правильно.

Заключение

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

Желающие ознакомиться с более подробной версией предсказаний Джеймса Виттейкера могут посмотреть и послушать запись его выступления на конференции GTAC, а также запись вебинара, организованного uTest.

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