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

Книга представляет собой компиляцию множества интервью и сообщений в блогах, посвящённую подходам к тестированию ПО в Google. Из изложенных в книге идей можно выделить следующие:

• Автоматизируйте всё, что подлежит автоматизации.

• Не молитесь на программу-методику испытаний, она – фальшивая библия тестировщика

• Тестировщик и программист – по сути, одна и та же специальность, требующая постоянной работы с кодом

В книге описано очень интересных технологий, в частности, описан BITE – встроенный в Chrome компонент помогающий сформировать обращение в bugtracking-систему.

Из не имеющей непосредственного к теме книги, но занятной информации, я бы отметил описание роли и места Индии (Хайдарабада) в успехе Google. Так же пикантным моментом, связанным с автором книги является факт его ухода из Google в 2012 году (вернулся в Microsoft) из-за конфликта с руководством по поводу Google+.

Я бы рекомендовал эту книгу как обязательную к прочтению всем, кто серьёзно озабочен проблемой обеспечения качества программного обеспечения. Лично меня эта книга вдохновила на автоматизацию тестирования ПО с использованием Python в нашей компании.

Описание органицации контроля качества в мировом лидере IT – корпорации Google. Авторы – руковолители и ведущие специалисты корпорации Google.

Достоинства: поэтапно рассказывается, за счёт чего компания, работающая с колоссальным объёмом данных, регулярно выпускает высококачественные релизы своих продуктов при жёстком дефиците людей и времени. Хорошо описаны базовые методики разработки и тестирования, детально описан специфичный для Google подход к взаимодействию различных групп специалистов.

Недостаток: изобилие взаиморекламы авторов.

Резюме: Обязательно к прочтению для работников IT-индустрии.

Последние 7 лет своей профессиональной деятельности я посвятил тестированию программного обеспечения. Как известно, имеется не так много книг на русском языке посвященной данной тематике. Увидев эту книгу, мне стало интересно выяснить, отличаются ли методы тестирования компании Google от общеизвестной практики инжиниринга ПО. Теперь я смог ответить на этот вопрос.

Читая эту книгу, я сначала получал ответы на совсем другие вопросы. Например, Почему некоторые "продвинутые" специалисты в разработке ПО зарабатывают миллионы, а другие — нет? Какие такие особенные обязанности имеет специалист по тестированию ПО, если он зарабатывает, например 300 000 долларов в год?

В одном блоге я прочитал вот такую поучительную историю, резюмирующую мои представления об организации программного инжиниринга в данной компании:

Представьте, что вы рабочий, который снабжает деревню водой, и вас, естественно, очень ценят. Можно выделить два типа рабочих: Рабочий 1: Берёт одно-два пустых ведра, идёт к озеру, наполняет их, возвращается и радует двадцать жителей деревни. По пути он утоляет жажду набранной из озера водой, а часть оставшейся воды потом забирает себе. Рабочий 2: Ему не важно, достанется ли ему «заслуженная» доля воды, которую он добудет. Вместо того чтобы взять ведро, он берёт лопату, маленькую чашку и исчезает на некоторое время. Он роет канал от озера к деревне и разочаровывает многих жителей деревни тем, что возвращается с пустой чашкой. Но старшее поколение по какой-то причине верит в него и хочет, чтобы он продолжал работать (они даже подкармливают рабочего, чтобы он не умер с голоду). Однажды он приходит в деревню и показывает непрекращающийся поток воды. Теперь рабочие первого типа лишаются доли в бизнесе. Им нужно искать новый вид деятельности и новую команду. Рабочий же второго типа, в зависимости от того, какая часть канала ему принадлежит, получает львиную долю ресурсов. Так как деревня хочет завладеть каналом и интегрировать его в свою систему, то со временем они выкупают его у Рабочего 2, предоставляя взамен собственность в самой деревне, обычно это участок земли. Средства массовой информации следят за рабочим второго типа и его нежеланием расстаться с накопленным богатством в обмен на высокое положение в иерархии деревни (этот график «удержания» сотрудника называют «золотыми наручниками»). СМИ преподносят это таким образом, будто другая компания решила переманить Рабочего 2, но ей оказали неожиданное сопротивление. В глазах Рабочего 1, который видит ситуацию так, как преподносят СМИ, его несправедливо недооценили. Рабочий первого типа ожидал равное вознаграждение, потому что провел за работой ровно столько же времени и был верен деревне.

Треть книги состоит из взаиморекламы сотрудников компании, которые между делом рассказывают нам в своих интервью, как создавались те или иные проекты по тестированию гугловских приложений и как создавались особые роли специалистов по тестированию. Приблизительно вторая треть книги описывает организационную структуру и взаимодействие сотрудников в проектах по тестированию. Хоть и специалисты выдают свои мысли и считают, что компания имеет особые решения в области тестирования ПО, всякий специалист по программному инжинирингу, знакомый с ведущими технологиями разработки ПО (RUP, агильное программирование, TDD, Scrum и др.), легко приходит к выводу, что в компании не придумали ничего абсолютно нового, все процессы тестирования схожи с общепринятыми техниками (хотя и взаимодействие между различными группами работников проекта, возможно, и построена нестандартно).

Книгу, правда, в любом случае прочитать специалистам в разработке и тестировании ПО очень полезно. Ну, хотя бы для того, чтобы знать, как можно презентировать на высоком уровне свои наработки. Многие компании, уделяющие небольшое время тестированию своих выпускаемых программных продуктов, найдут в книге много полезных советов и убеждений в вопросе, зачем и как лучше тестировать программы. Книга может быть полезна также начинающим руководителям проектов

ТОП-3 тем, которые меня очень заинтересовали при чтении книги: 1) Идея внутренней тестовой сертификации специалистов 2) Пример отличного кандидата от Джейсона Арбона (как должен уметь себя преподнести на собеседовании стоящий программист) 3) Что такое краудсорсинг и в каких случаях его интересно применять

P.S. Я бы не отказался от внедрения в моей компании правила 20%, когда один рабочий день недели каждый сотрудник работает в проекте компании, который сам для себя выбрал. Прекрасная мотивация для роста над собой!

Меня больше интересует поиск и усовершенствование поискового алгоритма Google, но тестирование тоже подойдёт. Хорошо, что в книге описана организационная структура службы тестирования и даны примеры тест-плана и тестовых туров Chrome. Однако, если вы о тестировании только слышали, как я, это не лучший способ знакомиться с тестированием. После заявления авторов, что многие книги о тестировании полезнее переработать в памперсы для взрослых, я даже боюсь браться за другие книги о тестировании. Выписала для себя несколько книг, которые упоминаются, и подписалась на обновления Google testing blog. Буду разбираться дальше.

Когда-то в Google работало лишь три тестировщика, а само тестирование считалось чем-то необязательным. Поначалу это не сказывалось на продуктивности небольшой компании, однако с увеличением масштабов пошло и увеличение количества багов. Джеймс Уиттакер и Патрик Коупленд - парни, которые первыми распознали угрозу такой ситуации для имиджа Google и фактически с нуля выстроили самую совершенную тестовую инфраструктуру планеты.

Вот об этом, если коротко, в книге и рассказывается. Введение и первая глава объясняют, зачем вообще тестирование нужно и кто им должен заниматься. Отдельно несколько раз проговаривается тезис о том, что тестировать продукт должна вся команда, в первую очередь - сами разработчики.

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

Отдельный интерес представляет глава о том, как в Google проходят собеседования. Оживляет книгу и большое количество интервью с топовыми специалистами. Радует и большое количество юмора - например, Уиттакер заявляет, что "лучший способ не пропустить баги в продакшн - вообще не писать код".

Немного удивляет последняя глава, в которой авторы рассуждают о том, куда все это будет развиваться. Один из основных выводов заключается в том, что автоматизация и краудсорс-тестирование продолжат наступать по всем фронтам и в конечном итоге профессия тестировщика окажется где-то рядом с профессиями фонарщика и трубочиста. Согласитесь, странный вывод для книги, в которой каждые 20 страниц говорится, какая же у нас классная профессия. Частично эту странность снимает то, что классные специалисты, по мнению авторов, все равно останутся при деле.

В книге много полезных иллюстраций и очень информативное приложение.

5/5