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

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

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

Приложения становились все более сложными, пользовательские интерфейсы становились сложнее, чем google.com, поэтому армия тестировщиков в Google росла. Пользователей становилось больше, и наши продукты стали занимать важное место в их жизни. Поэтому роль тестировщиков стала более значительной в культуре Google.

Роли разработчика в тестировании и инженера по тестированию взаимо­связаны, но между ними есть фундаментальные различия. Я был на обеих позициях и управлял обеими ролями. Взгляните на списки, которые я привожу ниже, и выберите, какое описание больше подходит вам, — может, вам стоит сменить профессию.

Вам больше подходит роль разработчика в тестировании, если вы:

— Можете взять спецификацию и запрограммировать надежное и эффективное решение с чистого листа.

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

— Вы думаете, что конечный пользователь — это тот, кто вызывает функцию API.

— Вас раздражает плохо написанная документация API, но вы иногда забываете, зачем этот API вообще нужен.

— Вы с увлечением болтаете с другими людьми об оптимизации кода или о выявлении ошибок совместного доступа потоков.

— Вы предпочитаете общаться с другими человеческими существами через мессенджер или в комментариях к коммитам.

— Вы предпочитаете командную строку графическому интерфейсу и редко прикасаетесь к мыши.

— Вы мечтаете о том, как ваш код выполняется на тысячах машин, тестируя алгоритмы, подтверждая правильность их работы только через количество тактов процессора и сетевых пакетов.

— Вы никогда не замечали и не меняли обои своего рабочего стола.

— Вы переживаете, когда видите предупреждения компилятора.

— Когда вас просят протестировать продукт, вы открываете исходный код и начинаете думать, где прикрутить заглушку.

— Успех для вас — это построить прекрасный низкоуровневый фреймворк юнит-тестирования, который используют все и который запускается на тестовом сервере миллионы раз в день.

— Когда вас спрашивают, готов ли продукт к выпуску, вы можете просто ответить: «Все тесты прошли».

Вам больше подходит роль инженера по тестированию, если вы:

— Можете взять существующий код, поискать в нем ошибки и немедленно понять, где могут быть сбои, но вас не особенно привлекает идея писать код с нуля или даже менять его.

— Вы лучше почитаете Slashdot или News.com, чем будете весь день читать чужой код.

— Если вы читаете недописанную спецификацию, вы сами заполняете все пропуски в документе.

— Вы мечтаете поработать над продуктом, который сильно повлияет на жизнь людей и будет у всех на слуху.

— Вам становится плохо при виде пользовательских интерфейсов некоторых веб-сайтов. Вы не понимаете, как с ними вообще кто-то работает.

— Визуализация данных вызывает у вас радостное возбуждение.

— Вы ловите себя на желании пообщаться с людьми из реального мира .

— Вы не понимаете, почему вам нужно ввести «i», чтобы набрать текст в одном известном текстовом редакторе. [45] Речь идет о текстовом редакторе vim (http://ru.wikipedia.org/wiki/Vim), в котором нужно специально входить в режим ввода текста. — Примеч. перев.

— Успех для вас — помочь реализоваться идеям других инженеров, а потом испытать эти идеи в боевых условиях.

— Когда вас спрашивают, готов ли продукт к выпуску, вы можете сказать: «Я думаю, да».

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