— Как насчет будущего WebDriver? К чему стремится ваша команда?
Саймон:Сейчас на поле вышло много игроков. Всего пару лет назад у нас был рынок с одним доминирующим браузером. Это в прошлом. Internet Explorer, Firefox, Chrome, Safari, Opera — далеко не все примеры, и это только десктоп. Браузеры на базе WebKit для мобильных устройств плодятся бешеными темпами. Коммерческие инструменты игнорируют все, кроме IE. Это кажется безумием, ведь 2008 год давно прошел. Следующим логичным шагом станет стандартизация WebDriver, чтобы мы могли гарантировать работу веб-приложений в разных браузерах. Конечно, было бы полезно сотрудничать с разработчиками браузеров, чтобы мы могли обеспечивать совместимость с WebDriver API.
— Похоже, это задача для комитета по стандартизации. Есть прогресс в этом направлении?
Саймон:Да. К сожалению, это означает, что мне приходится писать английские буквы вместо кода, зато у комитета W3C [32] World Wide Web Consortium (сокращенно W3C) — Консорциум Всемирной паутины, который разрабатывает и внедряет технологические стандарты для всего интернета. — Примеч. перев.
появилась наша спецификация, ведь разработчики браузеров связаны с этой организацией.
— Чего ты ожидаешь в будущем? Как средства автоматизации браузеров будут развиваться дальше?
Саймон:Надеюсь, они отойдут на второй план. Рассчитываю, что любой браузер будет поддерживать автоматизацию API и люди наконец перестанут думать об инфраструктуре, а просто будут использовать ее. Я хочу, чтобы разработчики концентрировались на новых фичах своих веб-приложений, а не на том, как их автоматизировать. WebDriver станет по-настоящему успешным, когда разработчики перестанут замечать, что он вообще используется.
Глава 3. Кто такой инженер по тестированию
Разработчики в тестировании в Google создают, настраивают, поддерживают и развивают инфраструктуру для автоматического тестирования. Инженеры по тестированию играют другую роль — они ориентированы на «человеческую сторону»: как пользователи будут взаимодействовать с приложением и какие проблемы при этом могут возникнуть. Им, как и большинству технических специалистов в Google, нужно уметь программировать. Но все-таки для решения многих задач тестировщикам не нужно писать код. [33] Это довольно общее описание. На самом деле многие тестировщики в Google делают почти то же, что и разработчики в тестировании, и тогда они пишут много кода. Других можно приравнять к релиз-менеджерам, они пишут очень мало кода.
Тестирование, обращенное к пользователю
В предыдущей главе мы описали инженера по тестированию как своеобразного «разработчика во имя пользователя», и это действительно так.
В Google есть особое, ставшее уже частью культуры компании, почтение к программированию. Принято считать, что любой, кто входит в команду разработки, должен знать, как писать код. Поэтому тестировщики должны уметь программировать, если хотят работать наравне с разработчиками. Тестировщик в Google, с одной стороны, обладает техническими навыками, которые так уважают разработчики, а с другой — умеет фокусироваться на потребностях пользователей, что постоянно держит программистов в тонусе. Вот такое вот раздвоение личности!
На заметку
Тестировщики должны уметь программировать, если хотят работать наравне с разработчиками. Тестировщик в Google, с одной стороны, обладает техническими навыками, которые так уважают разработчики, а с другой — умеет фокусироваться на потребностях пользователей, что постоянно держит программистов в тонусе.
Должностные обязанности тестировщиков сложно описать однозначно. Они отслеживают все, что связано с качеством, на протяжении всего процесса разработки, по мере того как одиночные сборки постепенно складываются в один большой продукт. Поэтому многие из них вовлекаются в самую низкоуровневую работу, где требуется еще одна пара опытных глаз и инженерный опыт. Это вопрос рисков: тестировщики находят самые уязвимые места в продукте и делают то, что принесет максимум ценности конкретно в этом случае. Иными словами, тестировщик будет выполнять задачи разработчика в тестировании, если именно эта работа принесет сейчас наибольшую пользу. Если нужно провести, например, код-ревью, он сделает это. Если тестовая инфраструктура хромает — тестировщик займется ею. Один и тот же тестировщик может сегодня заниматься исследовательским тестированием, а завтра в тестовых целях сам будет использовать продукт как обычный пользователь.
Читать дальше