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

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

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

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

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

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

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

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

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

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

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