Эппл: Мы анализируем, сколько раз и какие видеоролики просматриваются, их связи друг с другом и много других переменных. Мы изучаем, как справляется буфер с данными, ошибки кэша, и на основании полученных данных оптимизируем свою глобальную инфраструктуру.
У нас есть юнит-тесты для проверки качества видео. После моего прихода наша команда написала инструмент AS3 Player Helper для углубленного тестирования этого аспекта. Приложение распространяется с открытым кодом.[64] Оно построено на тестах FlexUnit, которые используют встроенный проигрыватель YouTube, воспроизводят им тестовые видеоролики и выдают информацию о состоянии проигрывателя и свойствах ролика. В тестовые ролики зашиты большие штрихкоды, они помечают кадры и отрезки времени. Их легко распознать даже после сжатия и потери качества. Еще один прием, чтобы оценить состояние видео, — это делать снимки видеокадров и анализировать их. Мы проверяем правильность пропорций и кадрирования, ищем деформации, искажения цвета, пустые кадры, белые экраны, проблемы синхронизации и т.д. Так эти проблемы оказываются в наших баг-репортах.
— Какой совет ты бы дала другим тестировщикам веб, приложений на базе Flash и веб-служб, управляемых данными?
Эппл: Работая с тестовыми фреймворками или тест-кейсами, делайте их простыми. Изменяйте архитектуру итеративно вместе с развитием проекта. Не пытайтесь сразу решить все проблемы. Смело выбрасывайте то, что вам не подходит. Если тесты или инструменты слишком сложны в сопровождении, выбросьте их и постройте более гибкие. Следите за тем, сколько вы тратите на сопровождение и диагностику тестов. Соблюдайте правило 70-20-10: 70% малых юнит-тестов, которые проверяют один класс или функцию, 20% средних тестов, которые проверяют интеграцию одного или нескольких модулей приложений, и 10% больших тестов (тех, что обычно называют системными или сквозными), работающих на верхнем уровне и проверяющих работу приложения в целом.
А дальше — назначайте приоритеты и ищите простые средства автоматизации с наибольшим эффектом. Всегда помните, что автоматизация не решит всех проблем, особенно это касается интерфейсных проектов или устройств. Всегда с умом подходите к исследовательскому тестированию, не забывайте отслеживать тестовые данные.
— Скажи честно, тестирование для YouTube — шикарная работа? Целый день смотреть видеоролики с котиками…
Эппл: Да, мы любим повеселиться, не буду врать. У нас как-то была первоапрельская шутка, когда мы выводили все заголовки видеороликов перевернутыми. Я просматриваю много интересного контента, и это моя работа! И даже после всего этого я все еще смеюсь над видеороликами с котиками!
Итак, мы выяснили, что в Google есть инженеры по тестированию и разработчики в тестировании, которые играют на стороне пользователей и разработчиков соответственно. А сейчас мы поговорим о третьей роли, которая связывает и координирует их работу. Речь идет о тест-менеджере. Это в первую очередь инженер, которые вносит технический вклад в проект. В то же время именно через него взаимодействуют все команды, от разработчиков и выпускающих менеджеров до менеджеров продукта и технических писателей. Плюс ко всему тест-менеджер обладает управленческими навыками и помогает своим подчиненным в профессиональном росте. Пожалуй, это самая сложная должность в Google.
Работа по тестированию проектов в Google на самом деле не выглядит так идеально, как описанная в этой книге ситуация, где каждый инженер занят только своим делом. На помощь приходит менеджер, который координирует работу тестировщиков и разработчиков в тестировании, — тест-менеджер. Немного о его месте в иерархии Google: он подчиняется директору по тестированию, у которого может быть несколько таких подчиненных,[65] а Патрик Коупленд руководит всеми директорами по тестированию.
На роль тест-менеджера мы редко нанимаем людей снаружи, чаще стараемся вырастить их внутри компании. Сотрудники, пришедшие извне, обычно (но не всегда) стартуют с позиции без подчиненных. Даже Джеймс Уиттакер, который был нанят на позицию директора, почти три месяца не имел подчиненных.
Большая часть тех, кто сейчас руководит тестированием, выросли из тестировщиков, и это неудивительно, учитывая, насколько у них широкий спектр задач. Инженер по тестированию управляет задачами по тестированию, держа в фокусе всю широкую картину проекта. Тут рукой подать до управления людьми. Тестировщик понимает большую часть функциональности продукта и общается с гораздо большим количеством инженеров, чем, к примеру, разработчик в тестировании. Однако успешный инженер вовсе не обязательно станет успешным тест-менеджером. В Google любой успех — дело коллективное. Мы все вместе работаем над тем, чтобы выбрать правильных менеджеров и помочь им добиться успеха.
Итак, наш первый совет — знайте свой продукт. Тест-менеджер должен быть готов ответить на любые вопросы по использованию своего продукта. Допустим, вы — тест-менеджер Chrome. Если вас спросят, как установить расширение, сменить оформление браузера, настроить синхронизацию, изменить настройки прокси-сервера, просмотреть DOM, найти хранилище cookie, поставить новую версию, то ваши ответы должны отскакивать от зубов. Хороший руководитель знает о своем продукте все — от пользовательского интерфейса до внутренних подробностей работы дата-центров.
Однажды я спросил тест-менеджера Gmail, почему моя почта медленно загружается, и я тут же узнал, как работают отдельные части сервера Gmail, и о том, что на этой неделе была проблема с удаленным дата-центром. Объяснение было даже слишком подробным, но я понял, что этот человек точно знает, как функционирует Gmail, и владеет самыми свежими данными о его производительности. Это именно то, чего мы ожидаем от всех тест-менеджеров: знать о своем продукте больше всех участников проекта.
Второй совет — знайте ваших людей. Конечно, тест-менеджер — эксперт своего продукта и отлично понимает работу, которую нужно выполнять, но все-таки ее непосредственно выполняют инженеры по тестированию и разработчики в тестировании. Чтобы работа выполнялась быстро и эффективно, невероятно важно хорошо знать своих людей и их навыки.
У нас в Google работают очень умные ребята, но их количество не бесконечно. Каждый тест-менеджер, приходящий извне, жалуется, что в его проекте недостаточно людей. Мы лишь дружно улыбаемся в ответ. Мы знаем это и не собираемся ничего менять. Хорошо зная своих людей и их навыки, руководитель может маленькой командой добиться тех же результатов, что и большим количеством людей. В этом сила тест-менеджера.
Мы уже писали, что дефицит приносит ясность и умножает чувство ответственности у всех участников проекта. Представьте, что вы растите ребенка и у вас семь нянек: одна кормит, другая меняет подгузники, третья развлекает малыша и т.д. Никто из них не сможет дать ребенку больше, чем один любящий, пусть и перегруженный родитель. Когда ресурсов не хватает, приходится оптимизировать весь процесс. Вы быстро находите свои ошибки и учитесь не повторять их. Вы создаете график кормления, размещаете запасные подгузники поближе, чтобы облегчить себе работу.
В тестировании программных продуктов в Google работает такая же схема. Руководитель не может просто бросить всех людей на задачу, поэтому все действия оптимизируются. Автоматизация, не приносящая пользы, уничтожается. Тесты, не выявляющие регрессию, не пишутся. Если разработчики требуют от тестировщиков определенной деятельности, они должны сами в ней участвовать. Люди не придумывают себе работу, чтобы просто не сидеть без дела. Не нужно делать то, что сейчас не принесет ценности.
Задача руководителя — поставить всех на свои места. Если он хорошо знает свой продукт, то легко определит приоритетное направление и те части, которые должны получить нужное покрытие в первую очередь. Если менеджер хорошо знает команду, то он сможет правильно распределить людей по областям работы для максимальной эффективности. Конечно, какие-то задачи останутся невыполненными. Но если все сделано правильно, это будут низкоприоритетные задачи или задачи достаточно простые, чтобы их можно было доверить внешнему подрядчику, краудсорсерам или внутренним пользователям.
Конечно, руководитель тоже может принять неправильное решение, правда, из-за важности его роли любая ошибка будет дорого стоить. К счастью, у нас сплоченное сообщество тест-менеджеров, его участники хорошо знают друг друга и регулярно обмениваются полезным опытом, повышая общий уровень знаний. Это еще одно преимущество дефицита ресурсов — небольшое количество людей, которые на «ты» друг с другом и могут регулярно встречаться.
