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

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

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

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

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

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

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

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

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

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

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

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

— он описывает, что будет делать продукт и как именно он это будет делать.

С точки зрения тестирования мы должны беспокоиться об актуальности тест-плана и в то же время не превращать его поддержание в самоцель:

— создание плана должно быть быстрым и должно давать возможность оперативного изменения;

— план должен описывать то, что надо протестировать;

— план должен помогать оценивать тестирование и выявлять пробелы в покрытии.

В Google история планирования тестирования почти такая же, как и в других компаниях. Каждая команда сама определяла то, как будет выглядеть и функционировать тест-план, исходя из принятых и удобных для нее форматов работы. Например, некоторые писали тест-планы в Google Docs в виде текстовых документов или электронных таблиц с общим доступом для своей команды. Другие хранили планы прямо на странице своего продукта. Третьи добавляли его на внутренние страницы Google Sites и включали ссылки на них в инженерную документацию и внутренние вики-системы. Были и те, кто предпочитал классику и пользовался документами Microsoft Word, которые рассылались по почте участникам команд. У кого-то тест-планов не было вообще, а были лишь наборы тест-кейсов, которые, должно быть, и представляли такой план.

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