Отчет о баге начинается с рассылки по электронной почте всем заинтересованным лицам, и для исправления создается список изменений кода. Он ставится в очередь на рецензирование, а после утверждения отправляется в очередь на сборку. Это лекарство от багов, и подобно тому, как родители наблюдают за реакцией своего ребенка на антибиотики, тестировщик получает по электронной почте оповещения о готовности новой тестовой сборки. Он устанавливает сборку и заново запускает проблемный тест-кейс.
Этот тест становится частью регрессионного пакета приложения. Его стремятся автоматизировать, чтобы проще было ловить регрессионные баги. Или, как минимум, создают ручной тест-кейс и заносят в систему управления тестами. Так формируется иммунитет системы к будущим заражениям — подобно тому, как ребенок получает иммунитет к тому виду бактерий, от которого он когда-то заболел.
Как мы нанимаем инженеров по тестированию
Мы в Google серьезно подходим к найму людей. У большинства наших инженеров высшее образование в области компьютерных технологий. В очень немногих учебных заведениях учат тестированию, поэтому до сих пор есть проблемы с наймом хороших тестировщиков. Сложно найти нужное сочетание навыков программирования и тестирования.
Найти специалиста на роль инженера по тестированию особенно тяжело, потому что лучшие из них не просто технари. Тестировщики в Google разрушают привычное представление об инженерах, на котором основан процесс найма разработчиков и разработчиков в тестировании. Откровенно говоря, мы не всегда все делали правильно и приносим извинения всем тестировщикам, которые пострадали от наших опытов совершенствования процесса собеседования. Инженеры по тестированию — редкие птицы. Они технически подкованы, заботятся об интересах пользователя, понимают продукт на всех уровнях от системной архитектуры до внешнего представления. Они неунывающие и общительные, и, что самое важное, изобретательные и умеют работать в условиях неопределенности. Только чудом можно объяснить, как Google (да и любая другая компания) умудряется поймать таких редких особей.
Часто забывается, что тестирование — это по сути проверка. Делает ли приложение то, что должно делать? Большая часть работы по тестированию сводится к планированию и выполнению проверок. Да, приложение может падать в процессе, но добиться сбоя — не цель тестировщика. Давить на программу, пока она не сломается, интересно, но куда интереснее давить на нее понемногу, снова и снова, имитируя ее реальную эксплуатацию пользователем. А как приятно убедиться в том, что она не сломается при таких условиях! Мы ищем именно такой позитивный взгляд на тестирование, когда проводим собеседование.
Мы опробовали несколько стилей собеседования для инженеров по тестированию.
— Сначала мы собеседовали их так же, как разработчиков в тестировании. Если мы находили умного и изобретательного кандидата, который недостаточно хорошо для нас умел программировать, мы рассматривали его на роль тестировщика. Такой подход привел к проблемам, возникала неформальная иерархия в команде. Что еще хуже, таким способом мы бы никогда не добрались до кандидатов, которые ориентированы больше на пользовательские аспекты — насколько удобно использовать продукт или как он решает задачи пользователей. Таких ребят нельзя было пропускать.
— Потом мы снизили требования к умению программировать. Мы подумали, что если сосредоточиться только на пользовательском и функциональном тестировании, круг потенциальных тестировщиков увеличится. Если кандидат не может написать код решения головоломки «Судоку» или оптимизировать алгоритм быстрой сортировки, это не значит, что из него не вырастет тестировщик. Это мог быть шанс привлечь в компанию больше тестировщиков, но внутри компании им было бы непросто вырасти. Культура программирования в Google настолько сильна и большинство инженеров настолько технически круты, что карьера у такого высокоуровневого тестировщика просто бы не сложилась.
— Мы пришли к смешанному подходу. Сегодня мы на собеседованиях ищем общие знания в области компьютерных технологий и технические навыки, при этом требуем от кандидатов хорошо разбираться в тестировании. Умение программировать необходимо, но только в рамках обязанностей тестировщиков, которые мы описывали выше: модифицировать чужой код и уметь написать скрипт для сквозного пользовательского сценария. Плюс к этому мы ждем от кандидатов сильных навыков общения, умения мыслить системно и эмпатии к пользователю. Только с таким миксом навыков можно эффективно работать и расти в Google.
Найти хороших тестировщиков трудно, потому что они должны быть хорошими во многих вещах одновременно. Не хватает хотя бы одной — собеседование окончено. Тестировщик и есть тот самый «и швец, и жнец». Самые крутые из них часто принимают окончательное решение о том, выпускать или не выпускать продукт. Если бы мы не относились к качеству этих людей так серьезно, у нас бы давно были неприятности.
В результате инженер по тестированию, которого самого протестировали по полной программе, может адаптироваться почти к любому продукту в любой роли. Начав с создания инструментов, привлечения пользователей, координации работы с другими командами и т.д., тестировщик часто начинает руководить разработчиками в тестировании, потому что шире смотрит на задачи и видит больше проблем и рисков.
Приложения становились все более сложными, пользовательские интерфейсы становились сложнее, чем google.com, поэтому армия тестировщиков в Google росла. Пользователей становилось больше, и наши продукты стали занимать важное место в их жизни. Поэтому роль тестировщиков стала более значительной в культуре Google.
Как отличить тестировщика от разработчика в тестировании
Джейсон Арбон
Роли разработчика в тестировании и инженера по тестированию взаимосвязаны, но между ними есть фундаментальные различия. Я был на обеих позициях и управлял обеими ролями. Взгляните на списки, которые я привожу ниже, и выберите, какое описание больше подходит вам, — может, вам стоит сменить профессию.
Вам больше подходит роль разработчика в тестировании, если вы:
— Можете взять спецификацию и запрограммировать надежное и эффективное решение с чистого листа.
— Программируя, вы вините себя, что не написали все юнит-тесты, которые могли бы. Вы обнаруживаете себя за раздумьями, как бы сгенерировать тестовый код, чтобы не писать юнит-тесты вручную.
— Вы думаете, что конечный пользователь — это тот, кто вызывает функцию API.
— Вас раздражает плохо написанная документация API, но вы иногда забываете, зачем этот API вообще нужен.
— Вы с увлечением болтаете с другими людьми об оптимизации кода или о выявлении ошибок совместного доступа потоков.
— Вы предпочитаете общаться с другими человеческими существами через мессенджер или в комментариях к коммитам.
— Вы предпочитаете командную строку графическому интерфейсу и редко прикасаетесь к мыши.
— Вы мечтаете о том, как ваш код выполняется на тысячах машин, тестируя алгоритмы, подтверждая правильность их работы только через количество тактов процессора и сетевых пакетов.
— Вы никогда не замечали и не меняли обои своего рабочего стола.
— Вы переживаете, когда видите предупреждения компилятора.
— Когда вас просят протестировать продукт, вы открываете исходный код и начинаете думать, где прикрутить заглушку.
— Успех для вас — это построить прекрасный низкоуровневый фреймворк юнит-тестирования, который используют все и который запускается на тестовом сервере миллионы раз в день.
— Когда вас спрашивают, готов ли продукт к выпуску, вы можете просто ответить: «Все тесты прошли».
Вам больше подходит роль инженера по тестированию, если вы:
— Можете взять существующий код, поискать в нем ошибки и немедленно понять, где могут быть сбои, но вас не особенно привлекает идея писать код с нуля или даже менять его.
— Вы лучше почитаете Slashdot или News.com, чем будете весь день читать чужой код.
— Если вы читаете недописанную спецификацию, вы сами заполняете все пропуски в документе.
— Вы мечтаете поработать над продуктом, который сильно повлияет на жизнь людей и будет у всех на слуху.
— Вам становится плохо при виде пользовательских интерфейсов некоторых веб-сайтов. Вы не понимаете, как с ними вообще кто-то работает.
— Визуализация данных вызывает у вас радостное возбуждение.
— Вы ловите себя на желании пообщаться с людьми из реального мира.
— Вы не понимаете, почему вам нужно ввести «i», чтобы набрать текст в одном известном текстовом редакторе.[45]
