Читаем Как тестируют в Google полностью

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

— И что же ты сделал для инженеров по тестированию?

Джеймс: Мы с Патом создали рабочую группу инженеров по тестированию, которая существует до сих пор. Сначала мы собирались раз в неделю на два часа, постепенно свели к одной часовой встрече в месяц. Пат приходил на первые встречи, а потом оставил меня рулить этим. Команда состояла из двенадцати инженеров по тестированию, отобранных Патом лично. Я еще был новичком и никого из них не знал. На первой встрече мы создали два списка: что в нашей роли круто и что — отстой. Составление списков стало моментом истины для многих участников. Они были единодушны в своем восприятии плохих и хороших факторов в профессии. Меня поразило, насколько они были честны с Патом, — никто даже не пытался сглаживать острые углы! Я видел уйму встреч, на которых все ждали, пока выскажется самый авторитетный участник, или отмалчивались из-за его присутствия. В Google все было иначе. Никого не волновало, что думал Пат, — это была их встреча, и если Пата что-то не устраивало, это была его проблема. Все это сильно воодушевило меня.

Рабочая команда много сделала для определения роли инженера по тестированию. Например, мы переписали рекомендации по карьерному продвижению. Мы выдвинули новый вариант карьерной лестницы на открытое голосование всего сообщества инженеров по тестированию в Google, и ее приняли. Это было здорово — я даже выписал премию всей рабочей группе, чтобы отпраздновать это событие. Наши идеи исходили «снизу», от людей, работающих в специальности, и поэтому принимались легко. Мы написали рекомендации по проведению интервью и разослали их рекрутерам и инженерам, участвующим в собеседованиях. Я думаю, что сейчас роль инженеров по тестированию определена так же четко, как и роль разработчика в тестировании.

— Ты уже достаточно давно работаешь в Google и знаешь всю подноготную. Можешь выдать нам секретный ингредиент Google? Что делает наше тестирование магическим?

Джеймс: Рецепт такой: возьмите высокую квалификацию тестировщиков, добавьте дефицит человеческого ресурса (который заставляет разработчиков помогать, а тестировщиков — оптимизировать), первым делом автоматизируйте (чтобы люди делали только то, в чем компьютеры не сильны), введите способность работать итеративно и быстро внедрять изменения после обратной связи от пользователей. Смешать, но не взбалтывать! Любая компания, которая захочет воспроизвести нашу организацию тестирования, должна начать с этих четырех ингредиентов.

— Как насчет другой книги? У тебя уже задумана следующая книга по тестированию?

Джеймс: Не знаю, я ведь никогда не планирую книги заранее. Моя первая книга родилась из курсовых заметок, которые я использовал для преподавания тестирования в Политехническом университете Флориды. Однажды после презентации на конференции STAR ко мне подошла женщина и спросила, не думал ли я о написании книги. Вопрос оказался с подвохом, так как она была книгоиздателем. Так родилась серия «How to Break Software». Я написал первую книгу сам до последнего слова и был сильно утомлен процессом, поэтому решил больше не писать в одиночку. Над следующими двумя книгами я работал с соавторами. Хью Томпсон написал книгу «How to Break Software Security», Майк Эндрюс написал «How to Break Web Software», а я помогал им обоим. Это действительно их книги. Я всего лишь написал часть материалов и управлял процессом. Мне нравится писать, но ни Хью, ни Майк не стали бы смущать меня, утверждая, что я пишу лучше, чем они. А вы двое? Я так не думаю. Но факт в том, что без меня никто бы не решился писать. В конечном итоге все, что происходит в моей карьере, заканчивается книгой, а окружающие меня люди становятся соавторами. Будете отрицать?

— Вообще-то читатель сейчас держит в руках доказательство твоих слов. Как тут поспоришь!

Перейти на страницу:

Похожие книги

Основы программирования в Linux
Основы программирования в Linux

В четвертом издании популярного руководства даны основы программирования в операционной системе Linux. Рассмотрены: использование библиотек C/C++ и стан­дартных средств разработки, организация системных вызовов, файловый ввод/вывод, взаимодействие процессов, программирование средствами командной оболочки, создание графических пользовательских интерфейсов с помощью инструментальных средств GTK+ или Qt, применение сокетов и др. Описана компиляция программ, их компоновка c библиотеками и работа с терминальным вводом/выводом. Даны приемы написания приложений в средах GNOME® и KDE®, хранения данных с использованием СУБД MySQL® и отладки программ. Книга хорошо структурирована, что делает обучение легким и быстрым. Для начинающих Linux-программистов

Нейл Мэтью , Ричард Стоунс , Татьяна Коротяева

ОС и Сети / Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

Успешная карьера архитектора программного обеспечения требует хорошего владения как технической, так и деловой сторонами вопросов, связанных с проектированием архитектуры. В этой необычной книге ведущие архитекторы ПО со всего света обсуждают важные принципы разработки, выходящие далеко за пределы чисто технических вопросов.?Архитектор ПО выполняет роль посредника между командой разработчиков и бизнес-руководством компании, поэтому чтобы добиться успеха в этой профессии, необходимо не только овладеть различными технологиями, но и обеспечить работу над проектом в соответствии с бизнес-целями. В книге более 50 архитекторов рассказывают о том, что считают самым важным в своей работе, дают советы, как организовать общение с другими участниками проекта, как снизить сложность архитектуры, как оказывать поддержку разработчикам. Они щедро делятся множеством полезных идей и приемов, которые вынесли из своего многолетнего опыта. Авторы надеются, что книга станет источником вдохновения и руководством к действию для многих профессиональных программистов.

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT
Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT