Чтение онлайн

— Как насчет будущего WebDriver? К чему стремится ваша команда?

Саймон: Сейчас на поле вышло много игроков. Всего пару лет назад у нас был рынок с одним доминирующим браузером. Это в прошлом. Internet Explorer, Firefox, Chrome, Safari, Opera — далеко не все примеры, и это только десктоп. Браузеры на базе WebKit для мобильных устройств плодятся бешеными темпами. Коммерческие инструменты игнорируют все, кроме IE. Это кажется безумием, ведь 2008 год давно прошел. Следующим логичным шагом станет стандартизация WebDriver, чтобы мы могли гарантировать работу веб-приложений в разных браузерах. Конечно, было бы полезно сотрудничать с разработчиками браузеров, чтобы мы могли обеспечивать совместимость с WebDriver API.

— Похоже, это задача для комитета по стандартизации. Есть прогресс в этом направлении?

Саймон: Да. К сожалению, это означает, что мне приходится писать английские буквы вместо кода, зато у комитета W3C [32] появилась наша спецификация, ведь разработчики браузеров связаны с этой организацией.

— Чего ты ожидаешь в будущем? Как средства автоматизации браузеров будут развиваться дальше?

Саймон: Надеюсь, они отойдут на второй план. Рассчитываю, что любой браузер будет поддерживать автоматизацию API и люди наконец перестанут думать об инфраструктуре, а просто будут использовать ее. Я хочу, чтобы разработчики концентрировались на новых фичах своих веб-приложений, а не на том, как их автоматизировать. WebDriver станет по-настоящему успешным, когда разработчики перестанут замечать, что он вообще используется.

Разработчики в тестировании в Google создают, настраивают, поддерживают и развивают инфраструктуру для автоматического тестирования. Инженеры по тестированию играют другую роль — они ориентированы на «человеческую сторону»: как пользователи будут взаимодействовать с приложением и какие проблемы при этом могут возникнуть. Им, как и большинству технических специалистов в Google, нужно уметь программировать. Но все-таки для решения многих задач тестировщикам не нужно писать код. [33]

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

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

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

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

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

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

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

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

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

— Где у продукта слабые места?

— Есть ли проблемы с безопасностью, конфиденциальностью, производительностью, надежностью, пригодностью использования, совместимостью?

— Работают ли первичные пользовательские сценарии как следует? Подходят ли они для международной аудитории?

— Взаимодействует ли продукт с другими (аппаратными и программными) продуктами?

— Хорошо ли работают средства диагностики проблем?

На самом деле вопросов, на которые предстоит ответить тестировщикам, гораздо больше, и все они связаны с выявлением рисков при выпуске продукта. И сов­сем не обязательно тестировщики выполняют всю работу сами, их задача в том, чтобы работа была выполнена. Для этого они могут привлекать других людей там, где это нужно. Так или иначе, тестировщикам платят за то, чтобы они защищали пользователей и бизнес от плохого проектирования, запутанного интерфейса, багов, проблем с безопасностью, конфиденциальностью и т.д. В Google только эти специалисты тратят все свое рабочее время на то, чтобы искать слабые места в приложениях. Поэтому эта роль намного меньше формализована, чем, например, роль разработчика в тестировании. К тестировщикам обращаются за помощью на всех стадиях проекта: и на этапе идеи, и во время выпуска восьмой версии, и даже когда проект уже считается древним, «законсервированным». Часто один такой инженер работает над несколькими проектами одновременно, особенно если его умения сфокусированы на безопасности, защите конфиденциальности и нюансах интернационализации.

Конечно, работа тестировщиков зависит от проекта. Одни много программируют, но держат фокус скорее на средних и больших тестах (например, сквозных пользовательских сценариях), чем на малых. Другие берут уже существующий код и ищут слабые места, которые могут привести к появлению дефектов. Занимаясь такой работой, тестировщики даже могут изменять код проекта (но не писать его с нуля!), но прежде всего они должны исполнять свою роль, то есть смотреть на всю систему целиком, фокусироваться на ее полноценном использовании. У тестировщиков есть своя суперсила: поиск неоднозначностей в требованиях и умение грамотно обосновывать свои сообщения о всевозможных существующих и вероятных проблемах.