Уиттакер . - Как тестируют в Google
36 Позволить тестировщику детализировать возможность — здравая мысль: становится больше вариантов интерпретации функциональности и их преобразований в тестовые примеры, а это, в свою очередь, улучшает покрытие.
37 http://www.google.com/chrome
38 Подробнее о турах можно почитать у Джеймса Уиттакера в «Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design» (Addison Wesley, 2009).
39 Программа «Платим за баги» для Chrome обсуждается по адресу: http://blog.chromium.org/2010/01/encouraging-more-chromium-security.html
40 «Огурцами» называют поведенческие тест-кейсы. Подробнее — на http://cukes.info
41 Интервью с Тедом Мао приведено во второй главе.
42 Как и во многих багтрекинговых системах, для определения приоритета ошибки мы используем запись PX (где P — от слова priority, X — целое число). Ошибки P0 — самые сложные, ошибки P1 менее серьезны и т.д.
43 Процесс, по которому мы устанавливаем, в каком порядке рассматривать баги, и принимаем решения о том, кто и в каком порядке будет ими заниматься. Схож с процессом установления очередности оказания скорой медицинской помощи в больницах и даже обозначается тем же термином «triage».
44 Интервью с Брэдом Грином, техническим менеджером Google Feedback, можно прочитать в главе 4.
45 Речь идет о текстовом редакторе vim (http://ru.wikipedia.org/wiki/Vim), в котором нужно специально входить в режим ввода текста. — Примеч. перев.
46 OKR (Objectives and Key Results, то есть «цели и ключевые результаты») — это список целей и оценка успеха в достижении этих целей. Google уделяет большое внимание количественно измеряемым метрикам успеха. То есть достижение 70-процентного успеха означает, что вы поставили достаточно высокие цели и усердно работали для их достижения, а 100-процентный успех говорит о том, что вы были недостаточно амбициозны.
47 Смоук-тестирование — это минимальный набор тестов, который проводят, чтобы убедиться, что базовые функции программы работают корректно. Если система не проходит смоук-тестирование, то дальнейшие тесты не имеют смысла. Термин родился в ходе проверки радиоэлектронных устройств — если после пробного включения детали аппарата перегреваются, «идет дым», то все устройство нужно отправлять на доработку. — Примеч. перев.
48 Самые приоритетные обходы выполняются на виртуальных машинах Skytap.com. Это мощная сеть виртуальных машин. Она позволяет разработчику напрямую связаться с той машиной, на которой произошел сбой, и управлять отладкой, даже не выходя из браузера. Время и внимание намного ценнее вычислительных процессов. Skytap позволяет ботам работать полностью на сторонних виртуальных машинах и аккаунтах, открывая им доступ к непубличным промежуточным серверам.
49 Пути XPath похожи на пути к файлам, но используются в веб-страницах, а не в файловых системах. Они идентифицируют отношения «родитель/потомок» и другие сведения, однозначно определяющие элемент в DOM-древе веб-страницы. См.: http://ru.wikipedia.org/wiki/Xpath
50 Сборки Chrome появляются несколько раз в день.
51 О том, что вызвало эту регрессию, можно узнать по URL-адресу http://trac.webkit.org/changeset/81691
52 URL-адрес проблемы WebKit Bugzilla: https://bugs.webkit.org/show_bug.cgi?id=56859. Адрес ошибки в Chromium: http://code.google.com/p/chromium/issues/detail?id=77261
53 Наши друзья из http://www.utest.com помогли в организации этих экспериментов. Тестировщики из этого сообщества чрезвычайно наблюдательны и отзывчивы. Иногда они находили больше ошибок, чем внутренние многократные запуски регрессионных тестов.
54 Термин «сингулярность» часто используется для описания момента, в который компьютеры превзойдут человеческий интеллект. Это будет интересное время, и мы уже сегодня видим его приближение (http://en.wikipedia.org/wiki/Technological_singularity).
55 Ложноположительными (false positives) называются сбои тестирования, вызванные не ошибками самого продукта, а ошибками тестового программного обеспечения. Обычно такие сбои обходятся дорого, раздражают инженеров и быстро снижают производительность их труда из-за безрезультатных исследований.
56 DOM (Document Object Model) — внутреннее представление всего кода HTML, образующего веб-страницу. Модель DOM содержит все маленькие объекты, представляющие кнопки, текстовые поля, изображения и т.д.
57 getElementFromPoint(x,y) возвращал хэш элементов для секции веб-страницы размером 800 1000. С задачей можно было справиться более эффективно, но это решение было простым и хорошо иллюстрировало проблему.
58 Деталь машины времени из фильма «Назад в будущее». — Примеч. перев.
59 Да, получается, что одна способность выского риска может потеряться в темном лесу других, менее рискованных. Это редкая ситуация, но мы умышленно создавали очень простой инструмент, помогающий думать, а не полностью работающий за вас.
60 Одной из таких облачных компании является Salesforce. Фил Валигора из SalesForce.com занимается интеграцией GTA во внутренний инструментарий.
61 Презентация Джеймса Уиттакера на конференции GTAC, посвященная будущему тестирования, доступна на YouTube по адресу http://www.youtube.com/watch?v=Pug_5Tl2UxQ
62 App Engine — облачный сервис Google для размещения сайтов и сервисов. Тестировщики часто используют App Engine для инструментов и инфраструктуры, так как App Engine может очень быстро наладить работу приложения и дать возможность пользоваться Google Scale бесплатно. Можно посмотреть на http://appengine.google.com. В настоящее время поддерживаются языки Java, Python и Go.
63 Спасибо Райану Хоупсу и Томасу Флинну из Allion Test Labs за помощь с тестированием и сертификацией оборудования и сетевой поддержки.
64 Исходный код AS3 Player Helper доступен по адресу http://code.google.com/p/youtube-as3-player-helper/source/checkout
Глава 4. Тест-менеджер
Итак, мы выяснили, что в Google есть инженеры по тестированию и разработчики в тестировании, которые играют на стороне пользователей и разработчиков соответственно. А сейчас мы поговорим о третьей роли, которая связывает и координирует их работу. Речь идет о тест-менеджере. Это в первую очередь инженер, которые вносит технический вклад в проект. В то же время именно через него взаимодействуют все команды, от разработчиков и выпускающих менеджеров до менеджеров продукта и технических писателей. Плюс ко всему тест-менеджер обладает управленческими навыками и помогает своим подчиненным в профессиональном росте. Пожалуй, это самая сложная должность в Google.
Кто такой тест-менеджер
Работа по тестированию проектов в Google на самом деле не выглядит так идеально, как описанная в этой книге ситуация, где каждый инженер занят только своим делом. На помощь приходит менеджер, который координирует работу тестировщиков и разработчиков в тестировании, — тест-менеджер. Немного о его месте в иерархии Google: он подчиняется директору по тестированию, у которого может быть несколько таких подчиненных65, а Патрик Коупленд руководит всеми директорами по тестированию.
На роль тест-менеджера мы редко нанимаем людей снаружи, чаще стараемся вырастить их внутри компании. Сотрудники, пришедшие извне, обычно (но не всегда) стартуют с позиции без подчиненных. Даже Джеймс Уиттакер, который был нанят на позицию директора, почти три месяца не имел подчиненных.
Большая часть тех, кто сейчас руководит тестированием, выросли из тестировщиков, и это неудивительно, учитывая, насколько у них широкий спектр задач. Инженер по тестированию управляет задачами по тестированию, держа в фокусе всю широкую картину проекта. Тут рукой подать до управления людьми. Тестировщик понимает большую часть функциональности продукта и общается с гораздо большим количеством инженеров, чем, к примеру, разработчик в тестировании. Однако успешный инженер вовсе не обязательно станет успешным тест-менеджером. В Google любой успех — дело коллективное. Мы все вместе работаем над тем, чтобы выбрать правильных менеджеров и помочь им добиться успеха.
Итак, наш первый совет — знайте свой продукт. Тест-менеджер должен быть готов ответить на любые вопросы по использованию своего продукта. Допустим, вы — тест-менеджер Chrome. Если вас спросят, как установить расширение, сменить оформление браузера, настроить синхронизацию, изменить настройки прокси-сервера, просмотреть DOM, найти хранилище cookie, поставить новую версию, то ваши ответы должны отскакивать от зубов. Хороший руководитель знает о своем продукте все — от пользовательского интерфейса до внутренних подробностей работы дата-центров.
Однажды я спросил тест-менеджера Gmail, почему моя почта медленно загружается, и я тут же узнал, как работают отдельные части сервера Gmail, и о том, что на этой неделе была проблема с удаленным дата-центром. Объяснение было даже слишком подробным, но я понял, что этот человек точно знает, как функционирует Gmail, и владеет самыми свежими данными о его производительности. Это именно то, чего мы ожидаем от всех тест-менеджеров: знать о своем продукте больше всех участников проекта.
Второй совет — знайте ваших людей. Конечно, тест-менеджер — эксперт своего продукта и отлично понимает работу, которую нужно выполнять, но все-таки ее непосредственно выполняют инженеры по тестированию и разработчики в тестировании. Чтобы работа выполнялась быстро и эффективно, невероятно важно хорошо знать своих людей и их навыки.
