Как тестируют в Google - Уиттакер .
Шрифт:
Интервал:
Закладка:
27 CamelCase — стиль написания составных слов, при котором несколько слов пишутся слитно без пробелов, при этом каждое слово пишется с заглавной буквы. Стиль получил cвое название из-за того, что заглавные буквы внутри слова напоминают горбы верблюда.
28 MapReduce — технология распределенных вычислений, при которой вычислительная задача разбивается на небольшие части, которые затем собираются вместе. См. http://en.wikipedia.org/wiki/MapReduce.
29 Сегментация (sharding) — разновидность распределения базы данных. Горизонтальная сегментация позволяет проектировать базы данных: строки таблицы базы данных хранятся по отдельности (в отличие от вертикального разбиения по столбцам). См. http://en.wikipedia.org/wiki/Shard_(database_architecture)
30 Версия Buganizer с открытым кодом, которая называется Issue Tracker, доступна в проекте Chromium по адресу http://code.google.com/chromium/issues/list
31 ThoughtWorks, Inc —IT-компания, основанная в 1983 году в Чикаго. Сейчас ее офисы открыты в 11 странах мира. Компания считается мировым лидером по разработке ПО для гибкой разработки. — Примеч. перев.
32 World Wide Web Consortium (сокращенно W3C) — Консорциум Всемирной паутины, который разрабатывает и внедряет технологические стандарты для всего интернета. — Примеч. перев.
Глава 3. Кто такой инженер по тестированию
Разработчики в тестировании в Google создают, настраивают, поддерживают и развивают инфраструктуру для автоматического тестирования. Инженеры по тестированию играют другую роль — они ориентированы на «человеческую сторону»: как пользователи будут взаимодействовать с приложением и какие проблемы при этом могут возникнуть. Им, как и большинству технических специалистов в Google, нужно уметь программировать. Но все-таки для решения многих задач тестировщикам не нужно писать код33.
Тестирование, обращенное к пользователю
В предыдущей главе мы описали инженера по тестированию как своеобразного «разработчика во имя пользователя», и это действительно так.
В Google есть особое, ставшее уже частью культуры компании, почтение к программированию. Принято считать, что любой, кто входит в команду разработки, должен знать, как писать код. Поэтому тестировщики должны уметь программировать, если хотят работать наравне с разработчиками. Тестировщик в Google, с одной стороны, обладает техническими навыками, которые так уважают разработчики, а с другой — умеет фокусироваться на потребностях пользователей, что постоянно держит программистов в тонусе. Вот такое вот раздвоение личности!
На заметку
Тестировщики должны уметь программировать, если хотят работать наравне с разработчиками. Тестировщик в Google, с одной стороны, обладает техническими навыками, которые так уважают разработчики, а с другой — умеет фокусироваться на потребностях пользователей, что постоянно держит программистов в тонусе.
Должностные обязанности тестировщиков сложно описать однозначно. Они отслеживают все, что связано с качеством, на протяжении всего процесса разработки, по мере того как одиночные сборки постепенно складываются в один большой продукт. Поэтому многие из них вовлекаются в самую низкоуровневую работу, где требуется еще одна пара опытных глаз и инженерный опыт. Это вопрос рисков: тестировщики находят самые уязвимые места в продукте и делают то, что принесет максимум ценности конкретно в этом случае. Иными словами, тестировщик будет выполнять задачи разработчика в тестировании, если именно эта работа принесет сейчас наибольшую пользу. Если нужно провести, например, код-ревью, он сделает это. Если тестовая инфраструктура хромает — тестировщик займется ею. Один и тот же тестировщик может сегодня заниматься исследовательским тестированием, а завтра в тестовых целях сам будет использовать продукт как обычный пользователь.
Иногда распределение работы зависит от времени: на ранних стадиях проекта надо решать задачи в роли разработчика в тестировании, а позже возникает потребность поработать именно тестировщиком. В других случаях тестировщик сам выбирает, какую работу ему выполнять здесь и сейчас. Здесь нет четких правил. То, что мы опишем в следующем разделе, по сути, является идеальным случаем.
Инженер по тестированию
Инженеры по тестированию появились в Google позже разработчиков и даже позже разработчиков в тестировании, поэтому эта роль до сих пор находится в процессе становления. Сегодняшние тестировщики определяют ориентиры, которыми будут руководствоваться следующие поколения. В этой части мы расскажем о новейших процессах, которые используют такие инженеры в Google.
Не все проекты требуют внимания инженеров по тестированию. Некоторые проекты находятся в начальной стадии и не имеют четкой задачи или описанных пользовательских сценариев. Таким проектам вряд ли будет уделяться особое (да и любое другое) внимание тестировщиков. Если есть большая вероятность закрытия проекта (например, он создавался для проверки гипотезы и не выдержал испытания), если в нем еще нет пользователей или четкого набора фич, то тестирование должны выполнять сами разработчики.
Даже если продукт точно будет выпущен, то работы для тестировщика на ранней стадии разработки не много, так как функциональность еще не устоялась, не определены основные фичи и границы проекта. Если разработчик в тестировании уже задействован, привлечение инженера по тестированию может стать лишней тратой сил и времени. К тому же в самом начале для планирования тестирования нужно намного меньше тестировщиков, чем для исследовательского тестирования на финальных циклах, когда разработка продукта близка к завершению и охота за пропущенными дефектами становится самой важной задачей.
На заметку
Работы для тестировщика на ранней стадии разработки немного, так как функциональность еще не устоялась, не определены основные фичи и границы проекта.
Хитрость с подключением тестировщиков к проекту в том, что нужно учитывать риски и степень выгоды от работы тестировщиков. Если потенциальный риск для будущего пользователя (или для всей компании) считается высоким, тогда тестировщиков нужно больше, но затраченные усилия должны быть соизмеримы с возможной выгодой от проекта. Если вы решили подключать тестировщиков, то обязательно соблюдайте правильные пропорции и делайте это в подходящий момент.
К моменту, когда в дело вступают тестировщики, разработчики и разработчики в тестировании уже выполнили большой фронт работ, связанных с организацией тестирования и обеспечением качества. Поэтому тестировщикам не нужно начинать все с нуля. Их работа в проекте начинается с ответов на вопросы:
— Где у продукта слабые места?
— Есть ли проблемы с безопасностью, конфиденциальностью, производительностью, надежностью, пригодностью использования, совместимостью?
— Работают ли первичные пользовательские сценарии как следует? Подходят ли они для международной аудитории?
— Взаимодействует ли продукт с другими (аппаратными и программными) продуктами?
— Хорошо ли работают средства диагностики проблем?
На самом деле вопросов, на которые предстоит ответить тестировщикам, гораздо больше, и все они связаны с выявлением рисков при выпуске продукта. И совсем не обязательно тестировщики выполняют всю работу сами, их задача в том, чтобы работа была выполнена. Для этого они могут привлекать других людей там, где это нужно. Так или иначе, тестировщикам платят за то, чтобы они защищали пользователей и бизнес от плохого проектирования, запутанного интерфейса, багов, проблем с безопасностью, конфиденциальностью и т.д. В Google только эти специалисты тратят все свое рабочее время на то, чтобы искать слабые места в приложениях. Поэтому эта роль намного меньше формализована, чем, например, роль разработчика в тестировании. К тестировщикам обращаются за помощью на всех стадиях проекта: и на этапе идеи, и во время выпуска восьмой версии, и даже когда проект уже считается древним, «законсервированным». Часто один такой инженер работает над несколькими проектами одновременно, особенно если его умения сфокусированы на безопасности, защите конфиденциальности и нюансах интернационализации.
Конечно, работа тестировщиков зависит от проекта. Одни много программируют, но держат фокус скорее на средних и больших тестах (например, сквозных пользовательских сценариях), чем на малых. Другие берут уже существующий код и ищут слабые места, которые могут привести к появлению дефектов. Занимаясь такой работой, тестировщики даже могут изменять код проекта (но не писать его с нуля!), но прежде всего они должны исполнять свою роль, то есть смотреть на всю систему целиком, фокусироваться на ее полноценном использовании. У тестировщиков есть своя суперсила: поиск неоднозначностей в требованиях и умение грамотно обосновывать свои сообщения о всевозможных существующих и вероятных проблемах.
