Продолжение перевода серии заметок Джеймса Виттейкера под названием «The Future of Testing». Эта серия в оригинале была опубликована в конце 2008 года, и в ней Джеймс сделал ряд предсказаний относительно того, как будет выглядеть работа тестировщиков в будущем, лет через 10-20. Его прогнозы во многом основаны на тех идеях, которые развивались и продолжают развиваться в компании Microsoft, где Джеймс работал в то время.
В переводе мы собрали все заметки серии в одну статью, состоящую из восьми частей (в данном посте представлены последние четыре части):
Как может выглядеть компьютерная программа? Разве не было бы полезно иметь визуализацию программы, которой можно было бы пользоваться во время разработки и тестирования? С одного взгляда нам было бы ясно, какие части продукта ещё остались незавершенными. Зависимости, интерфейсы и данные стали бы проще для восприятия, и, хотелось бы надеяться, их было бы проще протестировать. По крайней мере, мы могли бы наблюдать во время разработки, как продукт растет и развивается, а во время тестирования смотреть, как обрабатываются входные данные и как происходит взаимодействие с окружением.
У других инженерных дисциплин есть такие визуализации. Возьмём тех, кто делает автомобили. Все люди, занятые в процессе сборки, могут видеть машину. Они могут видеть, что на автомобиль еще не установлены бамперы или руль. Они могут наблюдать сборку на всём протяжении конвейера, от пустого кузова до полнофункционального продукта, готового к отправке дилеру. Сколько осталось до завершения? Ну, метров двадцать до конца линии!
Тот факт, что все участники процесса сборки автомобиля имеют общее видение продукта, является очень полезным. Они используют единые термины, которые все могут понять, так как каждая часть, каждое соединение, каждый интерфейс находится там, где он должен быть, и тогда, когда он должен там быть.
К сожалению, это не наш мир. Нас постоянно мучают вопросы «сколько осталось до завершения?», «какие задачи не выполнены?». Это проблема, которую будут решать тестировщики 21-го века.
Архитекторы и разработчики уже занимаются ей. Visual Studio содержит большое количество схем и визуализаций – от диаграмм последовательностей до графов зависимостей. Тестировщики тоже уже решают эту проблему. Внутри стен «империи» уже существуют системы визуализации для просмотра изменений кода в Xbox (объекты, код которых изменился, при рендеринге подсвечиваются зеленым, а после тестирования подсветка исчезает), для определения недостаточно тщательно протестированных сложных участков кода Windows (тепловые карты, показывающие соотношение покрытия кода и сложности кода, выполненные в трехмерном пространстве, позволяют обнаружить проблемные области). Эти визуализации выглядят впечатляюще, они красивы и позволяют тестировщикам с одного взгляда определить, что именно нуждается в тестировании.
Нам нужно больше подобных визуализаций, но к этой задаче нужно подходить осторожно. Мы не можем просто принять диаграммы, предоставленные группами UML и моделирования. Эти визуализации предназначены для решения других проблем, которые могут совпадать, а могут и не совпадать с теми, которые встречаются у нас. Многие из существующих визуализаций созданы, чтобы помогать архитекторам или разработчикам, но их потребности отличаются от наших. Мы должны думать об этом с позиций тестировщиков. Нам нужны визуализации, которые связывают требования с кодом, тесты с интерфейсами, изменения в коде с пользовательским интерфейсом, покрытие кода с элементами управления. Разве не здорово, когда запускаешь тестируемое приложение и видишь, что элементы управления «светятся» с интенсивностью, которая отражает тестовое покрытие или количество тестов, в которых они были задействованы? Или было бы очень неплохо видеть анимированный график использования сети или взаимодействия с базой данных в реальном времени? Почему мы не можем увидеть сетевой трафик или SQL запросы сразу же? Мы не видим многое из того, что скрыто внутри нашего приложения, и пришло время вытащить это на поверхность и использовать для повышения качества программы.
Эта задача может быть решена в ближайшем будущем, и над ней работает много умных людей.
Это тестирование программ в ярких красках.
Пару месяцев назад я присутствовал на лекции, которую проводил один из Ведущих Специалистов Microsoft (впрочем, возможно это был Выдающийся Инженер, я не очень хорошо улавливаю разницу между ними). Как и все наши Ведущие Специалисты, он был невероятно умён и когда он представлял проекты по разработке нескольких новых продуктов, которые он делал со своими коллегами, на меня что-то снизошло.
Видимо, я не смог удержать это в себе, и у меня на лице появилось выражение, напоминающее то, которое иногда бывает у людей с камнями в почках. Ведущий Специалист это заметил (так же как и девушка, сидевшая рядом со мной, но я не хочу об этом рассказывать) и после лекции подошел ко мне. Вот так начался наш разговор:
— Джеймс, – ( надо же, он моё имя знал!) – я вижу, что у Вас есть какие-то сомнения относительно моего проекта или продукта, про который я рассказывал. Я хотел бы услышать Ваше мнение.
— Нет, никаких проблем ни с Вашим продуктом, ни с проектом. Мои сомнения касаются Вас.
— Простите?
— Такие люди, как вы, пугают меня, – сказал я, – Вы тратите все своё время на мечты о новых возможностях и путях использования, Вы проектируете интерфейсы и протоколы. Вы важный человек, и люди прислушиваются к Вам и делают то, о чем Вы мечтаете. Но вы делаете всё это, не имея ни малейшего понятия о тестировании.
И в этот момент он попытался сделать правильную вещь – обратиться к тестировщикам за помощью. Он пригласил меня принять участие в оценке дизайна продукта. Это было именно то, чего следовало от него ожидать.
Но это совершенно не то, что нужно.
Привлечь тестировщика к проектированию продукта лучше, чем не делать этого вообще. Но не сильно лучше. Тестировщики будут обращать основное внимание на вопросы тестопригодности. Разработчики на возможность реализации. А кто учитывать оба аспекта? Кто будет решать, кто прав, и когда нужно идти на компромисс? Никто. Привлечение тестировщика к проектированию дает лишь незначительное улучшение; привлечение проектировщиков (и всех остальных участников) к тестированию – вот будущее.
Серьёзно, ну почему люди, которые создают программы, так мало смыслят в тестировании? И почему мы не делали попыток это изменить? Может быть мы, тестировщики, слишком укоренились в своей роли и теперь ревностно охраняем ключи от нашего интеллектуального царства? Неужели тестирование настолько полно тайн и загадок, что разработчики не могут его постигнуть? А может быть разработчики привыкли сваливать эту «не очень-то интересную» часть работы на нас и воспринимают теперь это как должное?
Включение тестировщиков в команду разработки не помогает. Вовлечение их на ранних этапах тоже. У нас есть проекты с соотношением разработчиков и тестировщиков один к одному, но производимые продукты всё равно не выглядят достаточно надёжными. Есть и проекты с куда «худшим» отношением числа разработчиков к числу тестировщиков, которые выпускают продукты явно лучше. Я думаю, что в будущем мы увидим, что разделение ролей не работает. Это разделение, наоборот, способствует тому, что тестирование применяется слишком поздно, и использовать весь его потенциал не получается.
Нынешняя культура тестирования и разделение ролей порочны, и правильный путь – в объединении ролей. Качество должно быть работой каждого. Думайте об этом в терминах Толкиена: одна роль, чтоб править всеми!
Вообразите мир, в котором знание о тестировании есть у каждого участника процесса разработки. Архитектор знает, как тестировать, проектировщик знает это, разработчик тоже не отстаёт, и все они применяют эти знания во всём, что делают, постоянно и последовательно. Это не отменит необходимость в существовании выделенных тестировщиков – должен же кто-то представлять независимое мнение, это просто приведёт к лучшему тестированию. Если каждое решение, принятое на любом из этапов разработки, будет подвержено правильным проверкам, тогда финальное тестирование сможет достичь такого уровня тщательности, о каком сейчас мы можем только мечтать. Если каждый участник проекта понимает тестирование, представьте, чего могут достигнуть несколько выделенных тестировщиков!
Чтобы эта утопия стала реальностью, потребуются огромные изменения в культуре тестирования. Тестирование должно войти в программы всех учебных заведений, выпускающих программистов. По мере профессионального роста разработчика обучение тестированию не должно прекращаться, а наоборот должно становиться мощнее и изощреннее. Нам нужно достигнуть такого уровня, когда все заинтересованные в проекте лица понимают тестирование, и им ничего не остаётся кроме как применять принципы тестирования во всём, что они делают. Однажды появятся инструменты для поддержки этого. Однажды мы окажемся на рубеже, когда просто не получится написать программу, которую нельзя протестировать, и не потому, что какой-то крутой тестировщик добился этого, а потому что каждый участник проекта работал над этим.
Тестирование играет слишком важную роль, чтобы «плестись в хвосте» процесса разработки. Проектные решения, важные с точки зрения тестирования, принимаются уже на ранних стадиях, и именно тогда тестирование должно начинаться. Нельзя также отдавать тестирование в руки единственной выделенной роли, отвечающей за качество. Напротив, нам необходимы такие культурные изменения, которые сделают качество работой каждого, и принципы тестирования проникнут во всё, что мы делаем.
В современном мире тестировщики в основном занимают последнюю линию обороны, но это часто не находит признания при оценке работы и во время раздачи бонусов. Если мы находим серьезный баг – ну так мы и должны были его найти, так и ожидалось. Если мы пропускаем баг – нам задают вопросы. К тестировщикам часто так относятся – игнорируют, если вы делаете, и ругают, если не делаете.
Но всё меняется, и это тоже скоро изменится, потому что это должно измениться. Мой друг Роджер Шерман (первый корпоративный директор по тестированию в Microsoft) описывает это изменение, сравнивая тестирование с гусеницей, которая становится бабочкой. По словам Роджера, бабочка, которая должна получиться из тестирования – это дизайн.
И я не могу с ним не согласиться. Если тестирование и техники тестирования станут применяться на более ранних стадиях процесса разработки, работа тестировщиков будет больше похожа на проектирование программ, чем на верификацию. Мы будем уделять больше внимания разработке стратегии качества для всех программных артефактов, а не только для исполняемого кода. Мы будем тратить больше времени на выявление потребности в тестировании, чем на выполнение тест-кейсов. Мы будем контролировать и оценивать автоматизацию, а не создавать и отлаживать ее. Мы будем проводить больше времени за анализом состояния уже готовых тестов, чем за созданием новых. Мы станем дизайнерами, и наша работа поднимется на более высокий уровень абстракции и сместится ближе к началу жизненного цикла.
В Microsoft эту роль играют тест-архитекторы, и я думаю, что большинство работ по тестированию движется в этом направлении. Если вы прочитали предыдущие шесть частей, тогда вы понимаете, какие изменения требуются для того, чтобы эта дизайно-ориентированная роль смогла выйти на первое место.
Это выглядит как светлое будущее, но тут определённо найдётся ложка дёгтя. Источник проблемы – в типах ошибок и методах тестирования, которые мы успешно используем сейчас. Не будет преувеличением сказать, что мы лучше ищем структурные ошибки (сбои, зависания и дефекты, связанные с самой программой, с её внутренним устройством, а не функциональностью), чем ошибки бизнес-логики. Но в будущем, о котором я рассказываю, будет множество технологических решений для устранения структурных ошибок. Это освободит тестировщиков для работы с ошибками бизнес-логики, а это такая категория проблем, с которой, как мне кажется, вообще вся наша индустрия не умеет справляться организованным или систематическим способом.
Поиск ошибок бизнес-логики означает, что мы должны понимать саму бизнес-логику. Понимание бизнес логики означает более тесное взаимодействие с клиентами и конкурентами, это означает погружение в ту область знаний, в которой работает наше программное обеспечение, это означает не только вовлечение на ранних стадиях цикла разработки, но и участие в работе над прототипами, требованиями, юзабилити и так далее, как мы никогда не делали прежде.
Работа на начальных этапах цикла разработки очень трудна, и у тестировщиков нет соответствующего опыта. Чтобы успешно стартовать, мы должны быть готовы к встрече с этими новыми проблемами, мы должны быть готовы осваивать новые способы мышления, новые подходы к пользователям и к качеству.
Работа в начале конвейера определённо отличается от того, чем мы занимаемся сейчас, и это то место, где многие и многие тестировщики будут находить своё место по мере того, как будущее становится настоящим.
Это заключительная часть моих предсказаний о будущем тестирования. Надеюсь, что предыдущие вам понравились. А напоследок я приберег один из, возможно, наиболее противоречивых своих прогнозов: в будущем мы будем поставлять тестовый код вместе с программными продуктами и будем иметь возможность выполнять его удаленно. Я уже предвижу улыбки хакеров и негодование защитников конфиденциальности, но к этому я вернусь чуть позже.
Я был в группе Windows, когда выпускалась Vista, и вспоминаю, как показывал ее как-то вечером дома своему тогда восьмилетнему сыну. Он много играет (и работает, если вы можете в это поверить) на компьютере, и ему очень понравился интерфейс Aero, симпатичные гаджеты на боковой панели, а скорость, с которой работали его любимые игры (в то время это были Line Rider и Zoo Tycoon), по-настоящему его впечатлила. Я еще подумал: «Как жаль, что он не ведет отраслевой блог», но я отвлекся от темы.
Так вот, в конце он задал мне вопрос, внушающий страх каждому тестировщику: «Папа, а что здесь сделал ты?»
Я замолчал, что довольно необычно для меня, и пробормотал что-то невразумительное. Как вы объясните восьмилетнему ребенку, что вы работали над чем-то несколько месяцев (я только начал работу в Microsoft и присоединился к работе над Vista в самом конце), но фактически ничего не сделали? Я попытался обойтись стандартными ответами на этот страшный вопрос (восклицательные знаки обязательны, они помогают мне убедить себя, что в моих словах есть доля правды):
«Я работал над тем, чтобы сделать ее лучше!»
«То, что она работает так, как она работает… это благодаря мне!»
«Если бы не мы, тестировщики, она была бы угрозой для общества!»
Последнее из этих заявлений мне особенно нравится. Впрочем, все они звучат одинаково неубедительно. Как такое может быть, что я работал над продуктом так долго, и не могу в качестве своего вклада продемонстрировать ничего, кроме отсутствия некоторых ошибок.
Мне кажется, именно в тот момент у меня родилась эта идея: тестовый код должен поставляться вместе с программой, он должен продолжать существование после релиза и выполнять свою работу в отсутствие тестировщиков. Это не жалкая попытка дать мне и моим коллегам возможность указывать на что-то для хвастовства, но способ обеспечить непрекращающееся тестирование и диагностику. Скажем прямо, к моменту выпуска мы никогда не можем сказать, что тестирование полностью завершено, так почему же мы должны останавливаться?
Кое-что из этого мы уже делаем. Технология Watson (вам наверняка знакомо сообщение «отправлять/не отправлять отчет об ошибке» в Windows-приложениях), входящая в состав Windows, позволяет нам собирать данные об ошибках сразу же при их возникновении в процессе эксплуатации. Следующим логическим шагом должна быть возможность сделать что-нибудь с полученной информацией.
В настоящее время Watson собирает данные об ошибке и захватывает релевантную отладочную информацию. Затем какой-то бедолага-разработчик должен пробраться через все эти данные и понять, как исправить это с помощью обновлений Windows. В 2004 году это было революционной идеей, и она по-прежнему актуальна. Через несколько лет это, возможно, будет считаться устаревшим подходом.
Что если тот самый бедолага сможет запускать дополнительные тесты и пользоваться всеми преимуществами тестовой инфраструктуры, которая существовала до выпуска продукта? Что если он сможет установить исправления и запустить регрессионное тестирование в том окружении, в котором произошел сбой? Что если он сможет установить обновления в эксплуатационную среду и попросить приложение провести регрессионное тестирование себя?
Бедолагой он не будет, это точно. Но поскольку тестирование и тестовые артефакты теряются после финальной сборки и поставки продукта, сейчас это невозможно.
Чтобы достигнуть таких возможностей, приложение должно сохранять данные предварительного тестирования и всегда иметь их при себе. А это означает, что возможность самотестирования станет одной из основных особенностей программного обеспечения будущего. Наша работа будет заключаться в том, чтобы найти способ включения нашей «магии» тестирования внутрь самого продукта. А нашей наградой будет радость от того, как сияют глаза наших детей, когда они увидят, что самая первоклассная особенность продукта — та, которую мы спроектировали!
Ах да, насчет хакеров и поборников конфиденциальности: не бойтесь! Хью Томпсон и я уже давно предупреждали о включении тестового кода в поставку (см. главу Атака №10 в книге «Как взломать программную защиту»). Поскольку мы знаем, как осуществить взлом, мы имеем шансы сделать всё правильно.
Заключение
Коллеги, даже если вы не согласитесь с идеями, высказанными Джеймсом – задумайтесь о том, что будет с тестированием не через год, не через два, а через полвека. Начинать строить это будущее нужно уже сейчас. И строить его будем мы с вами, поэтому оно будет таким, каким мы его сделаем.
Желающие ознакомиться с более подробной версией предсказаний Джеймса Виттейкера могут посмотреть и послушать запись его выступления на конференции GTAC, а также запись вебинара, организованного uTest.
В переводе мы собрали все заметки серии в одну статью, состоящую из восьми частей (в данном посте представлены последние четыре части):
- «Тестсорсинг»
- Виртуализация
- Информация
- Перемещение тестирования к началу
- Визуализация
- Культура тестирования
- Тестировщики в роли дизайнеров
- Тестирование после релиза
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.