Как тестируют в Google

Куда движется роль инженера по тестированию

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

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

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

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

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

Что станет с тест-директором и тест-менеджером

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

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

Инфраструктура тестирования в Google все еще клиентская. Множество тестов Selenium и WebDriver, написанных на Java или Python, хранится в репозитории, собирается и разворачивается на выделенных виртуальных машинах с помощью shell-скриптов. Тест-драйверы внедряют тестовую логику на Java в браузер, сами при этом выполняются как приложение в ОС. Решение работает, но инфраструктуру пора перестраивать, потому что этот метод требует дорогостоящих человеческих и машинных ресурсов для создания и выполнения тестов.

Инфраструктура тестирования постепенно перемещается в облако. Репозитории тест-кейсов, редакторы кода тестов, средства записи и выполнения — все они будут работать прямо на сайте или в расширении браузера. Подготовка, прогон и отладка тестов эффективнее, когда они выполняются на одном языке и в одном контексте с приложением. В наше время чаще всего речь идет о веб-приложениях, и так не только в Google. В нативных проектах, не связанных с вебом (например, платформенные приложения Android и iOS), тестирование будет управляться из веба и использовать адаптированные веб-фреймворки тестирования. Native Driver [76] — прекрасный пример перехода на модель «веб — первичен, нативность — вторична».

76

Пост в тестовом блоге Google по поводу Native Driver: http://google-opensource.blogspot.com/2011/06/introducing-native-driver.html

В современной быстро меняющейся среде, где проекты вместе со своими тестами возникают и исчезают все быстрее, будет оставаться все меньше внутренних, заточенных под один проект тестовых фреймворков и выделенных машин для тестов. Разработчики тестов начинают вкладывать больше усилий в развитие опенсорс-проектов, объединять и выполнять их в облачных мощностях. Selenium и WebDriver задают модель разработки инфраструктуры, сопровождающейся сообществом и финансируемой корпорациями. Будет возникать еще больше таких проектов, повысится степень интеграции между открытыми тестовыми фреймворками, открытыми багтрекинговыми системами и системами управления исходным кодом.

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

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

В завершение

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

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

Приложение А. Тест-план для Chrome OS

Статус: черновик

Контакт: [e-mail]

Автор: [e-mail]

Обзор тем

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