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

Сноски из книги

· #1

Не поняли, о чем речь? Погуглите!

· #2

Разработка через тестирование — процесс разработки программного обеспечения, который основан на том, что тесты пишутся до того, как будет написан код. Таким образом, функциональные обязанности кода определяются заранее. — Примеч. перев.

· #3

Предыдущие книги Джеймса Уиттакера по тестированию «How to Break Software: A Practical Guide to Testing» («Как сломать программу: практическое пособие по тестированию») и «Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design» («Исследовательское тестирование: советы, хитрости, туры и техники тест-дизайна») на русский язык не переводились. — Примеч. перев.

· #4

В начале 2012 года Джеймс Уиттакер перешел из Google в Microsoft. — Примеч. перев.

· #5

http://googletesting.blogspot.com/2011/01/how-google-tests-software.html

· #6

GTAC — Конференция Google по автоматизации тестирования (Google Test Automation Conference, www.GTAc.biz).

· #7

http://googletesting.blogspot.com/2007/01/introducing-testing-on-toilet.html

· #8

Код-ревью (или рецензирование кода) — систематическая проверка исходного кода с целью обнаружения и исправления ошибок, допущенные при его написании. Эта практика позволяет находить ошибки раньше и способствует улучшению общего качества кода. — Примеч. перев.

· #9

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

· #10

Классификация на малые, средние и большие тесты была выбрана для стандартизации. Многие тестировщики пришли к нам из разных компаний, в которых понятия «смоук-тестирования», BVT (Build Verification Test), интеграционных тестов и т.д. имели разные, часто противоположные значения. Старые термины приносили с собой столько хаоса, что я решил ввести новую терминологию.

· #11

Кстати, концепция громадных тестов формализована, и инфраструктура автоматизации Google использует понятия малых, средних тестов (и далее по списку) для определения последовательности автоматизированного выполнения. Эта тема более подробно рассматривается в главе, посвященной разработчикам в тестировании.

· #12

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

· #13

Заметим, что даже для клиентских продуктов Google старается делать частые и надежные обновления с помощью автообновления, встроенного во все клиентские приложения.

· #14

Речь идет о Ларри Пейдже и Сергее Брине — основателях Google.

· #15

О том, как появилась роль разработчика в тестировании, Патрик Коупленд рассказывает в предисловии.

· #16

В Google есть официальная система распределения графика, благодаря которой любой сотрудник может тратить 20% своего рабочего времени на любой другой проект Google. Иными словами, четыре дня в неделю вы занимаетесь своей основной работой, а один день экспериментируете и изобретаете. Необязательно именно так распределять свое время, многие бывшие сотрудники Google вообще считали такой рабочий график мифическим. Однако каждый из авторов этой книги участвовал в «двадцатипроцентных проектах», значит, они — реальность. Более того, многие инструменты, описанные в книге, — результат «двадцатипроцентной» работы, которая со временем воплотилась в полноценные финансируемые проекты. Правда, многие сотрудники Google в свое «двадцатипроцентное время» просто работают с другими проектами, а не занимаются экспериментами, поэтому от такой концепции рабочего времени выигрывают многие. (К моменту издания книги на русском языке Google официально отменил эту систему. — Примеч. перев.)

· #17

Самым распространенным механизмом такого поощрения в Google является премия «от коллег». Любой инженер, которому помогла работа другого инженера, может назначить ему премию в благодарность. У руководителей тоже есть свои способы поощрения сотрудника. Смысл в том, что работу на благо сообщества нужно подпитывать! Конечно, не стоит забывать, что есть и неформальный способ поблагодарить коллегу — «услуга за услугу».

· #18

Это правило в Google нарушено только в лабораториях локального тестирования Android и Chrome OS, где для проверки новых сборок нужно иметь широкий спектр оборудования.

· #19

Protocol Buffer Google имеет открытую спецификацию, которая представлена тут: http://code.google.com/apis/protocolbuffers/

· #20

Версия Mondrian с открытым кодом на базе App Engine доступна по адресу: http://code.google.com/p/rietveld/

· #21

Руководство Google по стилю для C++ доступно по адресу: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

· #22

http://labs.google.com/papers/bigtable.html

· #23

http://labs.google.com/papers/gfs.html

· #24

http://code.google.com/apis/protocolbuffers/docs/overview.html

· #25

«Тестирование в туалете» (Testing on The Toilet) упоминалось ранее в этой книге. О нем часто пишут в блоге Google Testing по адресу googletesting.blogspot.com

· #26

«Починялки» (fixits) — еще один элемент культуры Google: это мероприятие собирает людей для починки чего-то сломанного или работающего неправильно. Например, группа может устроить «починялки» для сокращения количества ошибок. Или для тестирования безопасности. Или для расширения использования #include в коде C или рефакторинга. Цель встречи не ограничивается технической областью, и «починялки» могут проводиться для улучшения качества блюд в кафе или схемы проведения собраний. По сути, это любое мероприятие, на котором люди собираются для решения общей проблемы.

· #27

CamelCase — стиль написания составных слов, при котором несколько слов пишутся слитно без пробелов, при этом каждое слово пишется с заглавной буквы. Стиль получил cвое название из-за того, что заглавные буквы внутри слова напоминают горбы верблюда.

· #28

MapReduce — технология распределенных вычислений, при которой вычислительная задача разбивается на небольшие части, которые затем собираются вместе. См. http://en.wikipedia.org/wiki/MapReduce.

· #29

Сегментация (sharding) — разновидность распределения базы данных. Горизонтальная сегментация позволяет проектировать базы данных: строки таблицы базы данных хранятся по отдельности (в отличие от вертикального разбиения по столбцам). См. http://en.wikipedia.org/wiki/Shard_(database_architecture)

· #30

Версия Buganizer с открытым кодом, которая называется Issue Tracker, доступна в проекте Chromium по адресу http://code.google.com/chromium/issues/list

· #31

ThoughtWorks, Inc —IT-компания, основанная в 1983 году в Чикаго. Сейчас ее офисы открыты в 11 странах мира. Компания считается мировым лидером по разработке ПО для гибкой разработки. — Примеч. перев.

· #32

World Wide Web Consortium (сокращенно W3C) — Консорциум Всемирной паутины, который разрабатывает и внедряет технологические стандарты для всего интернета. — Примеч. перев.

· #33

Это довольно общее описание. На самом деле многие тестировщики в Google делают почти то же, что и разработчики в тестировании, и тогда они пишут много кода. Других можно приравнять к релиз-менеджерам, они пишут очень мало кода.

· #34

Краудсорсинг (англ. crowd sourcing) — привлечение к работе добровольцев из профессионального сообщества без заключения договора. — Примеч. перев.

· #35

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

· #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

· #65

Когда мы писали книгу, в Google было шесть директоров по тестированию, у каждого в подчинении находилась небольшая группа тест-менеджеров. Последние обычно руководят рядовыми сотрудниками, но ведущие инженеры часто подчиняются непосредственно своему директору. Такая иерархия должна упрощать совместную работу. Кроме того, многие директора Google (а может, и все) иногда выполняют задачи как рядовые участники проектов.

· #66

В этом может помочь концепция «20%», о которой мы говорили ранее. Переходя из проекта A в проект Б, инженер занимается проектом Б в свое «двадцатипроцентное» время около квартала, а в следующем квартале меняет пропорции: 80% времени отводится проекту B, а 20% — проекту A.

· #67

TiVo — компания, которая разработала цифровое устройство для записи видео — TiVo. Устройство по сети связывается с сервером и записывает выбранные пользователем телепередачи или сериалы, которые он может просмотреть в любое время на своем телевизоре.

· #68

Почитать подробнее о PyAuto можно по адресу: http://www.chromium.org/developers/testing/pyauto

· #69

Про Autotest можно почитать по адресу http://autotest.kernel.org/

· #70

Песочница (от англ. sandbox) — отдельное пространство для тестирования программ или приложений. Любые игры в ней не повредят ОС, так как песочница изолирована от системы.

· #71

The Web Works (you’re welcome) — с английского можно перевести как «Интернет работает (не стоит благодарности)». — Примеч. перев.

· #72

«Следуй за солнцем» (от англ. — follow the sun) — модель рабочего графика межнациональных компаний, при котором руководитель, находящийся на одном континенте, в конце своего рабочего дня связывается с руководителем на другом континенте (где день только начинается) и передает ему дела, а тот в конце своего рабочего дня передает ему их обратно. Таким образом работа не прерывается, а просто двигается «вслед за солнцем».

· #73

NeXT — американская компания, основанная в 1985 году Стивом Джобсом. Занималась разработкой платформ для вузов и бизнеса. В 1996 году была куплена Apple.

· #74

Как оказалось, это неправда: http://ru.wikipedia.org/wiki/Эскимосские_названия_снега.

· #75

В Google есть программа подготовки инженеров по эксплуатационной надежности (SRE, Service Reliability Engineer), которая называется Mission Control. Разработчик, прошедший шестимесячную программу в роли SRE, получал приличную премию и кожаную куртку с эмблемой Google Mission Control.

· #76

Пост в тестовом блоге Google по поводу Native Driver: http://google-opensource.blogspot.com/2011/06/introducing-native-driver.html