Джеймс Уиттакер: Как тестируют в Google

Тест-план мертв, да здравствует тест-план!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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