Джеймс Уиттакер - Как тестируют в Google

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

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

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

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

Инфраструктура тестирования постепенно перемещается в облако. Репозитории тест-кейсов, редакторы кода тестов, средства записи и выполнения — все они будут работать прямо на сайте или в расширении браузера. Подготовка, прогон и отладка тестов эффективнее, когда они выполняются на одном языке и в одном контексте с приложением. В наше время чаще всего речь идет о веб-приложениях, и так не только в Google. В нативных проектах, не связанных с вебом (например, платформенные приложения Android и iOS), тестирование будет управляться из веба и использовать адаптированные веб-фреймворки тестирования. Native Driver [76] Пост в тестовом блоге Google по поводу Native Driver: http://google-opensource.blogspot.com/2011/06/introducing-native-driver.html — прекрасный пример перехода на модель «веб — первичен, нативность — вторична».

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

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