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

— Расскажи о самом успешным и самом неуспешном моментах тестирования YouTube .

Эппл:Самым успешным был инструмент для получения и проверки проблемных URL-адресов. Эти простые тесты очень сильно помогли нам быстро отлавливать критические баги. Мы добавили фичу, которая упрощала отладку тем, что выдавала данные трассировки стека. Разработчикам стало проще выявлять причины проблем и исправлять их. Этот инструмент стал нашим первым флангом защиты при развертывании и сэкономил тестировщикам очень много времени. После небольшой доработки мы настроили его для самых популярных URL-адресов из наших логов и для добавочного списка URL-адресов, отобранных вручную. Это принесло много пользы.

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

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

Эппл:Мы анализируем, сколько раз и какие видеоролики просматриваются, их связи друг с другом и много других переменных. Мы изучаем, как справляется буфер с данными, ошибки кэша, и на основании полученных данных оптимизируем свою глобальную инфраструктуру.

У нас есть юнит-тесты для проверки качества видео. После моего прихода наша команда написала инструмент AS3 Player Helper для углубленного тестирования этого аспекта. Приложение распространяется с открытым кодом64. Оно построено на тестах FlexUnit, которые используют встроенный проигрыватель YouTube, воспроизводят им тестовые видеоролики и выдают информацию о состоянии проигрывателя и свойствах ролика. В тестовые ролики зашиты большие штрихкоды, они помечают кадры и отрезки времени. Их легко распознать даже после сжатия и потери качества. Еще один прием, чтобы оценить состояние видео, — это делать снимки видеокадров и анализировать их. Мы проверяем правильность пропорций и кадрирования, ищем деформации, искажения цвета, пустые кадры, белые экраны, проблемы синхронизации и т.д. Так эти проблемы оказываются в наших баг-репортах.

— Какой совет ты бы дала другим тестировщикам веб , приложений на базе Flash и веб-служб, управляемых данными?

Эппл:Работая с тестовыми фреймворками или тест-кейсами, делайте их простыми. Изменяйте архитектуру итеративно вместе с развитием проекта. Не пытайтесь сразу решить все проблемы. Смело выбрасывайте то, что вам не подходит. Если тесты или инструменты слишком сложны в сопровождении, выбросьте их и постройте более гибкие. Следите за тем, сколько вы тратите на сопровождение и диагностику тестов. Соблюдайте правило 70-20-10: 70% малых юнит-тестов, которые проверяют один класс или функцию, 20% средних тестов, которые проверяют интеграцию одного или нескольких модулей приложений, и 10% больших тестов (тех, что обычно называют системными или сквозными), работающих на верхнем уровне и проверяющих работу приложения в целом.

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

— Скажи честно, тестирование для YouTube — шикарная работа? Целый день смотреть видеоролики с котиками…

Эппл:Да, мы любим повеселиться, не буду врать. У нас как-то была первоапрельская шутка, когда мы выводили все заголовки видеороликов перевернутыми. Я просматриваю много интересного контента, и это моя работа ! И даже после всего этого я все еще смеюсь над видеороликами с котиками!

33 Это довольно общее описание. На самом деле многие тестировщики в Google делают почти то же, что и разработчики в тестировании, и тогда они пишут много кода. Других можно приравнять к релиз-менеджерам, они пишут очень мало кода.

34 Краудсорсинг (англ. crowd sourcing) — привлечение к работе добровольцев из профессионального сообщества без заключения договора. — Примеч. перев.

35 Конечно, в случаях когда заказчик участвует в обсуждении тестовых планов или существует некое правительственное распоряжение на этот счет, гибкость, о которой мы пишем, пропадает. Есть некоторые тестовые планы, которые нужно писать и регулярно обновлять!

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

37 http://www.google.com/chrome

38 Подробнее о турах можно почитать у Джеймса Уиттакера в «Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design» (Addison Wesley, 2009).

39 Программа «Платим за баги» для Chrome обсуждается по адресу: http://blog.chromium.org/2010/01/encouraging-more-chromium-security.html

40 «Огурцами» называют поведенческие тест-кейсы. Подробнее — на http://cukes.info

41 Интервью с Тедом Мао приведено во второй главе.

42 Как и во многих багтрекинговых системах, для определения приоритета ошибки мы используем запись PX (где P — от слова priority, X — целое число). Ошибки P0 — самые сложные, ошибки P1 менее серьезны и т.д.

43 Процесс, по которому мы устанавливаем, в каком порядке рассматривать баги, и принимаем решения о том, кто и в каком порядке будет ими заниматься. Схож с процессом установления очередности оказания скорой медицинской помощи в больницах и даже обозначается тем же термином «triage».

44 Интервью с Брэдом Грином, техническим менеджером Google Feedback, можно прочитать в главе 4.

45 Речь идет о текстовом редакторе vim ( http://ru.wikipedia.org/wiki/Vim), в котором нужно специально входить в режим ввода текста. — Примеч. перев.

46 OKR (Objectives and Key Results, то есть «цели и ключевые результаты») — это список целей и оценка успеха в достижении этих целей. Google уделяет большое внимание количественно измеряемым метрикам успеха. То есть достижение 70-процентного успеха означает, что вы поставили достаточно высокие цели и усердно работали для их достижения, а 100-процентный успех говорит о том, что вы были недостаточно амбициозны.

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