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

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

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

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

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

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

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

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

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

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

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

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

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

Планирование тестирования

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

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

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

Среди всех тестовых документов у тест-плана самая маленькая продолжительность жизни35. На ранней стадии руководитель проекта часто настаивает на создании тест-плана (в приложении А приведен тест-план для ранней версии Chrome OS). Считается, что написание тест-плана — это отдельная задача со своим сроком и важностью. Но когда такой план создан, становится трудно уговорить того же руководителя проекта регулярно просматривать и обновлять его. Тест-план превращается в любимого плюшевого мишку, которого мы, как в детстве, таскаем с собой, не играя, но обязательно разревемся, если у нас его отберут.

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

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

На заметку

Тест-план рождается первым, и первым же он должен умереть.

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

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

Но это идеальный вариант, почти сказочная ситуация, которой мало кому удавалось достичь — будь то в Google или в других компаниях.

Давайте решим, каким мы хотим видеть тест-план:

— он всегда актуален;

— он объясняет назначение продукта и то, почему пользователи его полюбят;

— он описывает структуру проекта с названиями отдельных компонентов и фич;