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

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

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

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

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

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

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

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

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

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

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

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

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

— организация краудсорс-тестирования; [34] Краудсорсинг (англ. crowd sourcing) — привлечение к работе добровольцев из профессионального сообщества без заключения договора. — Примеч. перев.

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

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

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

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

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

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