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