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

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

«Тестсорсинг»
Виртуализация
Информация
Перемещение тестирования к началу
Визуализация
Культура тестирования
Тестировщики в роли дизайнеров
Тестирование после релиза

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

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

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

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

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

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

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

	Поколение	Роль поставщика
№1	Внутреннее тестирование	Предоставляют инструменты
№2	Аутсорсинг	Предоставляют услуги по тестированию (это включает использование инструментов)

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

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

№3

Краудсорсинг

Предоставляют тестировщиков (это включает тестирование и использование инструментов)

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

№4

Тестсорсинг

Предоставляют артефакты тестирования (это включает в себя тестировщиков, тестирование, и инструменты)

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

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 применяют методы раннего тестирования, а в будущем, надеюсь, мы придумаем, как делать это коллективно. Тестирование будет начинаться не тогда, когда появится что-то тестируемое, как это происходит сейчас, а тогда, когда существует что-то, нуждающееся в тестировании. Это тонкое, но важное различие.

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

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

Продолжение следует...

Будущее тестирования