Как тестируют в Google
Шрифт:
Чтобы быть хорошим тестировщиком, нужно быть проницательным и способным к управлению, поэтому многие топ-менеджеры Google вышли именно из тестировщиков.
Любопытный момент: работа тестировщиков в Google настолько разнообразна, что формализовать процесс их участия почти невозможно. Тестировщик может присоединиться к команде разработки в любой момент, он должен быть способен оценить состояние проекта, кода, архитектуры, пользователей и оперативно решить, на чем следует сосредоточиться в первую очередь. Если проект только начинается, то надо заняться планированием тестирования. Если проект уже в разгаре, то надо оценить
В Google нельзя равнять всех тестировщиков под одну гребенку. Мы часто называем таких ребят «те, кто приходит в середине проекта», а это значит, что тестировщик должен быть гибким, способным быстро интегрироваться в команду разработки и текущую ситуацию. Если уже поздно строить тест-план — к черту тест-план. Если проекту срочно нужны тесты — нужно распланировать самый минимум, чтобы можно было начать. Следует реагировать по ситуации. Не стоит зацикливаться на каких-то догмах в тестировании. Если пришел к середине проекта, то сделай эту середину золотой.
Вот общий список того, в чем тестировщик должен однозначно разбираться:
— планирование тестирования и анализ рисков;
— анализ спецификации, архитектуры, кода и существующих тестов;
— исследовательское тестирование;
— пользовательские сценарии;
— разработка тест-кейсов;
— выполнение тест-кейсов;
— организация краудсорс-тестирования; [34]
— метрики использования;
— работа с обратной связью от пользователей.
34
Краудсорсинг (англ. crowd sourcing) — привлечение к работе добровольцев из профессионального сообщества без заключения договора. — Примеч. перев.
Лучше всех эти задачи решают тестировщики с сильными лидерскими качествами и хорошими навыками общения.
Планирование тестирования
Разработчики имеют важное преимущество перед тестировщиками: ценность их работы очевидна для всех. Разработчик пишет код, код становится приложением, которого жаждет пользователь, и это приложение принесет компании прибыль. Работа разработчика по определению становится самой важной.
Тестировщики же работают с документами и артефактами, которые имеют определенный срок годности: на ранних стадиях они пишут тест-планы, позднее создают и выполняют тест-кейсы, формируют баг-репорты. Еще позже тестировщики составят отчеты о покрытии кода тестами и соберут отзывы у пользователей. Когда проект выпущен, разве кого-то интересует, как было проведено тестирование? Если продукт полюбился пользователю, то хорошее тестирование — это уже данность. Если проект потерпел неудачу, люди могут высказать свое мнение о тестировании, но вряд ли кто-то захочет подробностей.
Тестировщики не могут позволить себе эгоистично зацикливаться на тестовой документации. В муках программирования, просмотра кода, сборки, тестирования и постоянных повторениях этого цикла сложно выделить время на восхищение тест-планом. Плохому тест-кейсу редко уделяют столько внимания,
Среди всех тестовых документов у тест-плана самая маленькая продолжительность жизни. [35] На ранней стадии руководитель проекта часто настаивает на создании тест-плана (в приложении А приведен тест-план для ранней версии Chrome OS). Считается, что написание тест-плана — это отдельная задача со своим сроком и важностью. Но когда такой план создан, становится трудно уговорить того же руководителя проекта регулярно просматривать и обновлять его. Тест-план превращается в любимого плюшевого мишку, которого мы, как в детстве, таскаем с собой, не играя, но обязательно разревемся, если у нас его отберут.
35
Конечно, в случаях когда заказчик участвует в обсуждении тестовых планов или существует некое правительственное распоряжение на этот счет, гибкость, о которой мы пишем, пропадает. Есть некоторые тестовые планы, которые нужно писать и регулярно обновлять!
Тест-план рождается первым, первым же он должен и умереть — отпустите его. На ранней стадии проекта тест-план еще отражает общую идею проекта, но без постоянного ухода и грамотного кормления тест-план быстро чахнет: появляется новый код, фичи изменяются и добавляются, решения, которые хорошо смотрелись на бумаге, переосмысливаются по ходу работы и получения отзывов от пользователей.
Чтобы тест-план оставался жизнеспособным, требуется огромная бюрократическая работа, и она оправданна только в том случае, когда к этому документу регулярно обращаются заинтересованные в проекте люди.
Тест-план рождается первым, и первым же он должен умереть.
Этот пункт — краеугольный камень всей идеи планирования тестирования. Насколько тест-план действительно управляет тестированием на протяжении всей разработки? Обращаются ли к нему тестировщики, распределяя фичи между собой? Настаивают ли разработчики на своевременном обновлении тест-плана? Правда ли, что руководители разработки открывают тест-план на своих компьютерах так же часто, как и свои списки дел? Как часто тест-менеджер ссылается на содержимое тест-плана во время встреч, посвященных статусам и прогрессу? Если план действительно важен, то все это должно происходить каждый день.
Тест-план должен играть центральную роль во время выполнения проекта. Это должен быть документ, который родился одновременно с проектом, живет и взрослеет вместе с ним, обновляется при каждом обновлении кода проекта и описывает продукт в его текущем виде, а не в том, каким он был на старте. Тест-план должен облегчить работу инженеру, примкнувшему к проекту на любой стадии.
Но это идеальный вариант, почти сказочная ситуация, которой мало кому удавалось достичь — будь то в Google или в других компаниях.
Давайте решим, каким мы хотим видеть тест-план:
— он всегда актуален;
— он объясняет назначение продукта и то, почему пользователи его полюбят;
— он описывает структуру проекта с названиями отдельных компонентов и фич;
— он описывает, что будет делать продукт и как именно он это будет делать.
С точки зрения тестирования мы должны беспокоиться об актуальности тест-плана и в то же время не превращать его поддержание в самоцель:
— создание плана должно быть быстрым и должно давать возможность оперативного изменения;