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

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

— Где у продукта слабые места?

— Есть ли проблемы с безопасностью, конфиденциальностью, производительностью, надежностью, пригодностью использования, совместимостью?

— Работают ли первичные пользовательские сценарии как следует? Подходят ли они для международной аудитории?

— Взаимодействует ли продукт с другими (аппаратными и программными) продуктами?

— Хорошо ли работают средства диагностики проблем?

На самом деле вопросов, на которые предстоит ответить тестировщикам, гораздо больше, и все они связаны с выявлением рисков при выпуске продукта. И сов­сем не обязательно тестировщики выполняют всю работу сами, их задача в том, чтобы работа была выполнена. Для этого они могут привлекать других людей там, где это нужно. Так или иначе, тестировщикам платят за то, чтобы они защищали пользователей и бизнес от плохого проектирования, запутанного интерфейса, багов, проблем с безопасностью, конфиденциальностью и т.д. В Google только эти специалисты тратят все свое рабочее время на то, чтобы искать слабые места в приложениях. Поэтому эта роль намного меньше формализована, чем, например, роль разработчика в тестировании. К тестировщикам обращаются за помощью на всех стадиях проекта: и на этапе идеи, и во время выпуска восьмой версии, и даже когда проект уже считается древним, «законсервированным». Часто один такой инженер работает над несколькими проектами одновременно, особенно если его умения сфокусированы на безопасности, защите конфиденциальности и нюансах интернационализации.

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

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

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

На заметку

Чтобы быть хорошим тестировщиком, нужно быть проницательным и способным к управлению, поэтому многие топ-менеджеры Google вышли именно из тестировщиков.

Любопытный момент: работа тестировщиков в Google настолько разнообразна, что формализовать процесс их участия почти невозможно. Тестировщик может присоединиться к команде разработки в любой момент, он должен быть способен оценить состояние проекта, кода, архитектуры, пользователей и оперативно решить, на чем следует сосредоточиться в первую очередь. Если проект только начинается, то надо заняться планированием тестирования. Если проект уже в разгаре, то надо оценить готовность проекта к выпуску или искать какие-то дефекты, которые еще можно поймать до выхода проекта в бета-тестирование. Если в руки тестировщика попадает продукт, который Google только что приобрел, как правило, проводится исследовательское тестирование с минимальным планированием (или вообще без него). Некоторые проекты не выпускались довольно долгое время, и с них нужно смахнуть пыль, подлатать систему безопасности или немного изменить пользовательский интерфейс — здесь нужен уже другой подход.