Как тестируют в 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