Инженер по тестированию

Инженер по тестированию

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

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

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

На заметку

Работы для тестировщика на ранней стадии разработки немного, так как функциональность еще не устоялась, не определены основные фичи и границы проекта.

Хитрость с подключением тестировщиков к проекту в том, что нужно учитывать риски и степень выгоды от работы тестировщиков. Если потенциальный риск для будущего пользователя (или для всей компании) считается высоким, тогда тестировщиков нужно больше, но затраченные усилия должны быть соизмеримы с возможной выгодой от проекта. Если вы решили подключать тестировщиков, то обязательно соблюдайте правильные пропорции и делайте это в подходящий момент.

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

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

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

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

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

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

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

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

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

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

На заметку

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

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

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

Вот общий список того, в чем тестировщик должен однозначно разбираться:

— планирование тестирования и анализ рисков;

— анализ спецификации, архитектуры, кода и существующих тестов;

— исследовательское тестирование;

— пользовательские сценарии;

— разработка тест-кейсов;

— выполнение тест-кейсов;

— организация краудсорс-тестирования;[34]

— метрики использования;

— работа с обратной связью от пользователей.

Лучше всех эти задачи решают тестировщики с сильными лидерскими качествами и хорошими навыками общения.

Данный текст является ознакомительным фрагментом.