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

— Сколько людей работало над этими двумя проектами: Buganizer и Matrix?

Тед: В самые жаркие периоды разработки над Buganizer работало пять инженеров, а над Matrix четыре. Я всегда расстраиваюсь, думая о том, чего бы мы добились с постоянной большой командой. Но, думаю, мы все-таки прекрасно справились теми силами, которыми располагали.

— Какие самые серьезные технические проблемы вы преодолевали, разрабатывая инструменты?

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

— Что ты посоветуешь программистам, которые разрабатывают средства тестирования?

Тед:

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

— Какой ты видишь следующую масштабную или просто интересную проблему, которую нужно решить в области тестовых инструментов и инфраструктуры?

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

Интервью с создателем WebDriver Саймоном Стюартом

Саймон Стюарт — создатель WebDriver и гуру браузерной автоматизации в Google. WebDriver — это опенсорс-инструмент для тестирования веб-приложений, который популярен как в Google, так и за его пределами. Исторически WebDriver — это одна из самых горячих тем на конференции Google Test Automation Conference.

Авторы встретились с Саймоном, чтобы узнать, что он думает об автоматизации тестирования веб-приложений и о будущем WebDriver.

— Мне кажется, многие люди не совсем понимают, в чем отличие Selenium от WebDriver. Ты можешь объяснить разницу?

Саймон: Джейсон Хаггинс начал проект Selenium, когда работал в ThoughtWorks.[31] Джейсон писал веб-приложение и ориентировался преимущественно на браузер IE, который занимал тогда больше 90% рынка. Но он постоянно получал сообщения о багах от пользователей, пересевших на Firefox, причем исправление ошибки для Firefox могло нарушить работу приложения в IE. Джейсон придумал Selenium как механизм, запускающий и тестирующий приложение в обоих браузерах.

Я начал разрабатывать WebDriver примерно через год после создания Selenium, но еще до того, как проект Джейсона вышел на стабильность. Я ориентировался на более общее тестирование веб-приложений, поэтому неудивительно, что мы выбрали разные способы реализации. Проект Selenium строился на запуске JavaScript-кода в браузере, а WebDriver сам интегрировался в браузер через API. У каждого подхода были свои достоинства и недостатки. Selenium почти сразу же мог работать с новыми браузерами, например с Chrome, но не умел загружать файлы и нормально обрабатывать действия пользователя. Все-таки возможности песочницы JS ограничены. Механизм WebDriver был встроен в браузер, поэтому он мог обходить эти ограничения, но добавлять другие браузеры было тяжело. Когда мы оба пришли в Google, мы решили объединить проекты.

— Но мы до сих пор слышим оба названия. Это все еще разные проекты?