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

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

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

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

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

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

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

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

Было интересно прочитать эту книгу с точки зрения профессионального интереса. Все же хочется знать, а как же там? Как там тестируют? Как там работает менеджмент? Что стоит в приоритете и какое направление задано?
Книга интересная и познавательная. Но я бы сказала, что она скорее подойдет менеджерам проектов для понимания организации работы. Возможно для лидов по той же причине. Тут не будет указания куда лучше смотреть тестировщику, как набираться опыта или на что обращать больше внимания. Надо это просто принять и читать с другой целью.
Советую ее всем, кто интересуется организацией процессов и думает куда нужно стремиться и что искать в компаниях!

Как человек, закончивший курсы тестировщиков не так давно, не могла пройти мимо этой книги.
Читать начала еще во время учёбы) Мучила 10 месяцев, очень туго шла. Начало было еще довольно увлекательным, экскурс в историю, как всё начиналось, какие три типа тестировщиков есть в Google и их роль в тестировании. Но всё это разбавлялось большим количеством интервью, которые были бы гораздо интереснее, если бы все друг друга по кругу не хвалили и не благодарили.
Серьезно, книгу можно вполовину сократить, если убрать все поклоны в сторону друг друга.
Ну и в целом, книга всё же не для тестировщиков, а для менеджеров и руководства, потому что в ней мало о том, как именно тестируют, а больше о том, как построить систему, как склонить людей заниматься тестированием (и вообще чем-либо, если раньше на это в компании не выделяли времени и не считали нужным).
Еще были несколько хороших сравнений, как на собеседовании отвечает на вопросы хороший айтишник и как отвечает лучший.
В целом книга неплохая, но я думала, что будет больше о тестировании, а не о руководстве.

Так как же в Google тестируют ПО? Единственное, что можно сказать после этой книги: увлечённо! И если это действительно так, то можно только порадоваться за сотрудников (да и пользователей) Google. Вот только явные баги всё так же доходят до конечных юзеров, Chrome всё так же ненасытен в отношении оперативной памяти, а проекты у них всё так же закрываются...

Книга будет полезна с менеджерской точки зрения: узнать, как распределяются обязанности в одной из самых успешных компаний мира, как в ней строятся отношения между командами и отдельными сотрудниками. Что в принципе входит в обязанности разработчиков в тестировании (это они так автоматизаторов называют?), инженеров в тестировании, тест-менеджеров и директоров по тестированию. Кстати, мне кажется, что именно интервью удались лучше всего и получились очень интересными, особенно вопросы про самые ужасные баги, коварно пробившиеся к пользователям. Правда, очень уж рьяно директор по тестированию в индийском Google подчёркивал, что офис там открыли вовсе не из-за дешевизны рабочей силы, а из-за исключительных навыков сотрудников. Конечно же, всё так и было.

К сожалению, сразу после выхода книги все три автора ушли из Google, так что вполне возможно предположить, что там уже всё совершенно не так. Но можно порадоваться за Уиттакера: он всё-таки стал IT-евангелистом!

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

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

Что ж. Очень хорошо, что я не прочитала эту книгу год назад. Новичкам без опыта она точно будет неинтересна, а может и вовсе отобьет желание учиться.

В книге описывается система тестирования в компании Google - как устроены внутренние процессы, какие специалисты привлечены, как набирают этих специалистов, каких правил придерживаются, кто за что отвечает, какие инструменты используют.
Честно говоря, книга будет полезна скорее лиду, проект-менеджеру, менее всего - автотестеру. По мануальному тестированию в книге очень мало инфы. Инструменты и программы, которые описываются - почти все внутреннего типа, не openspace. Поэтому вряд ли получится перенять этот опыт себе.

Для развития кругозора, блеснуть интеллектом в беседе, - почитать можно, но не более.

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

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

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

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

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

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

5/5

Любопытно.

Книга выходного дня.

Книга прежде всего менеджерская и маркетинговая.

Менеджерская потому что рассматриваются именно организационные подходы к процессу тестирования на примере авторского опыта в проекте Google Chrome. В основном обсуждаются особенности организации web-тестирования.Приводится иерархия задействованных специалистов и их роли, комментируются особенности корпоративных подходов к разработке и планированию тестирования.

Мало внимания уделяется инфраструктуре корпоративного программного окружения, задействованного в тестировании и разработке.

А маркетинговая эта книга потому что, на мой взгляд, нескромно рекламирует и идеализирует корпорацию и её продукты.

Это не книга по тестированию для тестировщиков. Это пособие по организации работа отдела тестирования с упором на автоматизацию, рекомендации по набору людей в такие команды и еще 1000 мелочей, которые играют роль для тимлидов и менеджеров проектов. Если ваше дело - писать автотесты, тест-кейсы и тест-планы, ничего нового вы не узнаете (как протестировать поле ввода с кнопкой? Ребята, к вам серьезно регулярно приходили собеседоваться чуваки, которые не слышали про граничные значения?! Вы шутите что ли?!!!). Ну, кроме того, что Гугл не мог не выпендрится и не переименовать общие обозначения на свои. Привет очередная путаница в классификации.
А, ну и да, количества поглаживаний друзьям, коллегам, отцам-основателям, начальству и всему Гуглу тут больше чем на пяти церемониях Оскара подряд.)
Так что решайте сами - нужно вам это али нет, для общего развития кое-как пойдет, для чего-то серьезного - нет.