Пользователь
0,0
рейтинг
6 января 2012 в 15:44

Разработка → Как Google тестирует ПО

Прослушав вебинар «How Google Tests Software» я был так вдохновлен, что решил записать некоторые тезисы. Эта статья и есть мой конспект. Прежде всего, я должен внести ясность относительно ее содержания. Это не дословный перевод. Здесь описаны только те вещи, которые показались мне важными. Проще говоря, здесь описано не все, что прозвучало в вебинаре. Так же существует вероятность, что я понял что-то не до конца или даже понял неправильно. Поэтому горячо рекомендую прослушать вебинар самостоятельно.
Его ведет Джэймс Витакер, который в данный момент занимает пост технического директора по тестированию ПО в Google. Джэймс совместно с коллегами готовится выпустить одноименную книгу. В ней можно будет получить исчерпывающую информацию о том, как проводят тестирование GoogleMaps, Google+, ChromeOS, Android и т.д…

* Дальше, для простоты изложения, повествование будет вестись от первого лица, будто бы я это Джэймс.

Философия


По большей части Google проповедует культуру инженеров, здесь совсем мало перспектив для менеджеров. А вот каждый инженер может посвятить 20% рабочего времени на собственные проекты. Именно это время является наиболее урожайным для интересных идей. Например, gmail вырос как раз из подобной идеи и стал популярным веб сервисом. Сhrome был 20% проектом и стал популярным приложением. Этими примерами я хотел подчеркнуть одну важную особенность google — мобильность. Мы быстро создаем новые приложения. А сотрудники легко мигрируют из одной группы разработчиков в другую.

Философия тестирования в google гласит, что тестирование нужно не для качества. Тестирование, это часть инженерной культуры. Тестирование, это часть разработки, тестирование, это то, что мы делаем перед релизами. Но мы не тестируем для того, чтобы поднять качество. Высокое качество закладывается разработчиками, менеджерами проектов и тестировщиками, а не тестами. Мне кажется, что наша особенность заключается в том, что мы сделали тестирование, абсолютно неотъемлемой частью нашей работы. Ни один разработчик не может закомитить код, который был бы не покрыт тестами. Это все происходит автоматически, как часть рабочего процесса. Должности тестировщика у нас нет, у нас есть роли. О них мы поговорим чуть позже. Тестирование, это работа для каждого. Но мы не видим себя тестерами мы называем себя отделом продуктивности инженеров. Ведь идея заключается не в создании тестов как таковых, а в ускорении разработки. Как выяснилось, ошибки и просчеты являются основными причинами задержек. Тестирование помогает нам массивно сокращать их количество. Поэтому мы можем разрабатывать значительно быстрее. Именно поэтому мы смогли создать Google+ за 100 дней. На протяжении лета, то есть в течении следующих 3 месяцев, мы смогли добавить еще сотню новых возможностей в функционал. Это поразительная скорость разработки. И знаете что? Этот продукт соответствует мировым стандартам качества. Конечно, программное обеспечения всегда не идеально. Google+ не является исключением. Однако, мы создали его быстро и качественно.

Продуктивность


Как вы понимаете, наша роль заключается в ускорении google, а не в обязательном тестировании всего и вся. Для повышения продуктивности инженеров у нас есть специальные инструменты. Есть общий инструментарий (IDE, компиляторы, системы сборок, тесты) и есть специфический для отдельных продуктов. Мы совместно прорабатываем релизы продуктов, обучаем инженеров и конечно тестируем. У нас есть три роли для тестеров: SWE, SET, TE.

SWE — наши основные разработчики, которые работают над функционалом. На них лежит разборка кода (code review), TDD, Unit тестирование и приемочные испытания. Они так же ответственны за качество каждого участка кода. Это важно. Тестеры не отвечают за качество. SWE не может написать немного кода, а потом сказать тестеру, попробуй улучшить этот код. Это его собственная работа.

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

Первые две роли на 100% связаны с кодом. Третья роль напротив, от него абстрагирована. Роль TE связана с пользователями. Такое разделение имеет смысл по многим причинам, главная из которых, заключается в разном типе мышления. Одни отстаивают код, другие пользователей. Мы хотим, чтобы каждый фокусировался на своем деле. Вы не подумайте, что TE это те, кто делает тесты вручную. TE пишут много кода. Их код посылает что-то на ввод, затем валидирует результат на выходе. Это другой уровень тестов. Они так же пишут сценарии для тестов.



Стратегия


Одна из важнейших составляющих нашей стратегии по выпуску высококлассного программного обеспечения, называется «ползи, иди, беги». Идея сводится к быстрому созданию продукта, быстрому выпуску, быстрому получению отзывов и быстрому реагированию на них. Google преуспел в этом. Чего мы точно не хотим видеть у нас, так это двухлетнего цикла разработки. Когда кто-то вбегает и размахивая руками рассказывает, что у него появилась гениальная идея, которая изменит весь мир! И что если мы ее реализуем, то это будет клево, и что все непременно полюбят ее. Этот номер не проходит у нас. Если у тебя есть такая идея, набросай код. Реализуй наиболее важный функционал. Познакомь с результатом как можно более широкий круг людей. Узнай не ошибался ли ты. И если ты оказался прав, то у тебя появятся пользователи, и появится возможность перейти к следующему этапу. Этот подход мы применяем даже на очень больших проектах. Если вы взгляните на Chrome, которому я посвятил 18 месяцев, вы узнаете, что мы каждый день собираем новый релиз. Мы называем такие релизы канареечными. Каждый, кто связан с проектом может взять такой релиз и поиграться с новыми возможностями. В конце недели отбирается лучший канареечный релиз. С этим еженедельным кандидатом, который мы называем dogfood релиз, должен поработать каждый участник команды. Очень важно, чтобы все тестировали один и тот же последний релиз. Для того чтобы избегать обнаруживания уже решенных ошибок. Каждый месяц автоматически отбирается лучший dogfood Chrome, он предназначен для наших сотрудников. Позже, я подробнее расскажу об инструментах, которые они используют для взаимодействия с разработчиками. Мы обнаружили интересную закономерность. Выяснилось, что пользователи dogfood релизов находят несоизмеримо больше багов чем разработчики и тестеры. Это очень показательный момент. Вместо того, чтобы нанимать армию тестеров, которые будут имитировать поведение пользователей, мы отдаем продукт гуглерам, которые им по настоящему пользуются. От них мы получаем богатые отчеты об ошибках. Наконец мы выпускаем бета релиз, который тестируется преданными пользователями.

Тесты


Мы разделяем тесты на 3 группы, маленькие, средние и большие. Мы не разделяем их на unit/integration/system по нескольким причинам. Во-первых у нас централизированная система выполнения тестов. Если вы скажете этой системе, что собираетесь выполнить маленький тест, она поймет, что он будет длиться не долго и сможет запланировать его выполнение соответственно. Все проекты в google используют эту систему и поэтому мы хотим рационально распределять время между ними. Система попеременно вставляет маленькие тесты между большими и в результате работает непрерывно.

Маленькие тесты:
  • Почти всегда автоматизированы
  • Выполняются в псевдо среде (mocked/facked environment)
  • Проверяют одну функцию или один модуль
  • Сфокусированы на валидации данных и проверке исключений
  • Выполняются в течении миллисекунд
  • В большей степени пишутся SWE


Средние тесты:
  • Обычно автоматизированы
  • Выполняются в псевдо среде
  • Проверяют взаимодействия между функциями
  • Сфокусированы на функциональных проблемах взаимодействия данных
  • Выполняются в течении секунд
  • Пишутся SET и SWE


Большие тесты:
  • Могут быть, как автоматизированными, так и осуществляемыми вручную
  • Выполняются в настоящем окружении
  • Проверяется конечный функционал
  • Могут выполнятся часами
  • Написанием занимаются TE и SET


Еще несколько слов о тестах


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

Мы тестируем даже читабельность кода. Каждая строчка на c++, phyton, java и java script проверяется на читабельность внутри нашего процесса разработки.

И инженеры, и тестировщики используют одно и то же окружение. Все используют одну и ту же версию linux, независимо от задачи, будь то в датацентре на серверах или на десктопе у разработчика. Однородность среды очень важна для воспроизведения ошибок. Для нас local = test = staging = production. Если у вас не так, предлагаю вам над этим серьезно подумать.

ACC — 10 минутный план тестирования


Когда я только пришел в google я занимался утомительным чтением тест планов. У каждого проекта был свой непохожий на другие план. У этих планов была только одна общая черта, они были устаревшими и не отражали действительность. Эти планы писались, потом просматривались, а затем игнорировались. Тестовое планирование это одна из обязанностей TE и я знал, что нам нужно делать это лучше. Вот, что я сделал. Я собрал нескольких моих инженеров в комнате, дал им одно приложение, сказал у вас есть 10 минут, составьте план тестирования и оставил их. Конечно я вернулся через 10 минут и услышал: «Чувак, мы думали ты шутил, ведь 10 минут не хватит для полноценного плана». Надо сказать, что в google не смотря на отсутствие менеджеров есть понимание ответственности и обязанностей, поэтому они в общем должны были сделать, что я им поручил. Я сказал им, что они могут с этим справится, пусть стараются усерднее. Затем дал им другое приложение и новые 10 минут. В этот раз у них наметился определенный прогресс. Я снова дал им другое приложение и снова отвел всего 10 минут. Это продолжалось на протяжении полутора часов, до тех пор пока у одного из инженеров не получилось что-то ценное. В следствии эта техника вылилась в методологию. Вот чему мы научились:
  • Отказывайтесь от прозы в пользу списков
  • Не заморачивайтейсь на продажах
  • Не лейте воды, это не сочинение
  • Если это не воспроизводимо, забудьте
  • Создайте поток, пусть одно вытекает в другое
  • Сопровождайте мышление тестировщика
  • На выходе должны получится тесты


Мы назвали такое планирование ACC (Attributes Components Capabilities) и даже выпустили open source приложение (есть и лайв версия) облегчающее составление такого плана. Теперь мы можем составить тест для любого приложения в google меньше чем за полчаса. Составление списка важных атрибутов системы это пожалуй наиболее длительный процесс. Обычно, последнее чего хотят разработчики это участвовать в нем. Для того чтобы получить основной список вы можете заглянуть на официальный сайт приложения, скорее всего там уже все написано. Вот какой трюк мы используем в google для вовлечения разработчиков. К примеру, когда мы составляли тест план для ChromeOS, за 20 минут описали все возможности, которые мы только знали. У нас получился список из 304 пунктов. Мы пришли к разработчикам и сказали: «Знаете, ChromeOS так проста, что на самом деле там всего 304 атрибута для теста». Они моментально выпалили, что этого не может быть, что система очень комплексная, что она очень сложная. Разработчики любят все усложнять. Они любят считать что их код самый сложный на свете. Поэтому если вы скажете, что их код примитивен, то они захотят доказать, что вы ошибаетесь, а это именно то, что нам и было нужно. Они собрали 2 часовое совещание, что по меркам google все равно, что отлучить людей на неделю от работы. Они посидели и добавили к этому списку еще несколько важных атрибутов и в итоге список вырос до 320 пунктов. Этот трюк хорошо работает. Составляйте часть атрибутов и вовлекайте разработчиков, если это не выходит, приступайте к тестированию без них. Важные вещи постепенно сами дифференцируют. Подробнее о том как составить 10 минутный план вы можете почитать в нашем блоге.


BITE Record & Playback


Второй инструмент о котором я бы хотел поговорить и который я упоминал ранее называется BITE. BITE тоже был выпущен, как opensource приложение. Оно позволяет записывать действия в браузере, а затем воспроизводить этот материал. Этим инструментом пользуются все гуглеры, тестеры наших внутренних dogfood релизов. Они помогают нам создавать проверочные тесты. Подробнее об этом вы можете почитать в нашем блоге.



BITE Bug Filing


Для меня не важно как много книжек по созданию тестов вы прочли. Более того я даже являюсь автором одной из таких книг. Я убежден, что пользы от ваших тестов будет меньше чем от настоящих пользователей. Они работают в реальной среде, а не в той, которую вы воссоздаете. У них есть настоящие данные, а не те, что вы выдумали. Они используют свои собственные сценарии работы, а не те, которые подражают таковым. Вы тестер, который всего лишь претендует быть пользователем. Пользователи не претендуют на это звание, они и есть пользователи. Поэтому мы решили превратить пользователей в тестеров. Если вы подумаете о google maps, а это еще один продукт, которому я посвятил немало времени. Вы поймете, что только пользователи могут достоверно проверить данные окружающей их действительности. Как мы вообще можем проверять такие вещи? Серьезно, это задача мирового масштаба, буквально. Только тот, кто живет на этой улице способен распознать, что на карте ошибка. Хоть мы и google, мы не можем нанять тестеров, чтобы перепроверить всю землю. Мы должны доверять своим пользователям и мы должны опираться на их знания. В результате получается, что это хорошая мысль, ведь они лучше нас. В данный момент эта утилита не открыта. Она напрямую подключена к нашей базе данных ошибок. Когда вы кликаете по карте эта утилита делает снэпшоты dom структуры, собирает информацию о бразуре, операционной системе, словом все то, что необходимо для воспроизведения ошибок.


Quality Bots


И на последок я расскажу о еще одной утилите, которую мы используем для тестирования браузера Chrome. Когда мы только приступили к тестированию хрома, мы делали много проверок вручную. На самом деле они для меня были лишены всякого смысла. Для нас было важно не «поломать интернет». Для нас было важно, чтобы Chrome продолжал правильно отображать популярные сайты. Мы не хотели выпустить браузер, который бы не отрисовывал cnn, facebook или другие популярные сервисы. Конечно, лекго сделать тест на загрузку популярной сотни сайтов и узнать вызывают ли они крах браузера. Правда, это не совсем то, что нам нужно. В действительности мы хотим проверять 10 тысяч самых популярных сайтов и сверять так ли они выглядят в старой версии нашего браузера и как они выглядят сейчас в Firefox, Safari, и IE. Приложение, которое мы сделали называется Quality Bots, о нем мы тоже рассказали в нашем блоге. Приложение делает две вещи. Сравнивает DOM и проверяет расположение всех управляющих элементов на странице. Конечно, сайты на которых есть реклама каждый день будут выглядеть по разному. Для нас важно, чтобы они были приблизительно похожими. Если это так, то мы считаем тест пройденным.


Эпилог


Те кто заинтересован в подробностях, могут зафоловить твиттер Джэймса, загруглить его в плюсах или почитать блог, где регулярно появляются статьи по данной тематике.
skid @skid
карма
89,4
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (52)

  • 0
    Забавно. уже 40 увели на полочку и никто не сказал СПАСИБО! =)
    • +1
      то были боты
      • +3
        Некультурные боты были.
    • 0
      Спасибо большое! :)
  • +6
    >По большей части Google проповедует культуру инженеров, здесь совсем мало перспектив для менеджеров.

    А для дизайнеров их нет вообще :)

    • 0
      Почему-же, в последнее время как раз наоборот — всё время новые дизайны продуктов (Youtube, главная страница самого Google). По-моему, дизайнерам в Google тоже есть, где разогнаться — правда, только в одном стиле — минимализма- но, тем не менее, и это не мало.
      • +1
        Возможно, толчком для этого как раз и послужил массовый исход лучших дизайнеров из Гугла несколько лет назад. В Google проекты долго обкатываются через горнило A/B тестинга. В результате многие смелые изменения отметаются на стадии тестирования, а изменения становятся мелкими и незаметными. Дизайн проигрывает в угоду эффективности. Достаточно вспомнить, как одно время менялся размер и положение логотипа Google на странице поиска. Можно было сидеть, обновлять страницу и видеть, как она немножко прыгает. Также долгое время размер логотипа зависел от браузера.

        Сейчас вот перешли на другой стиль — стиль Google+. Но сколько он продержится в продуктах компании без существенных изменений? Может, пять лет, а может и десять. И поверьте мне, через десять лет всем будет казаться, что Гугл не меняется и что для хорошего дизайнера там нет ни работы, ни перспектив.

        С другой стороны, во многих компаниях соответствующего калибра — Facebook, Microsoft, Apple — та же проблема: есть определенный стиль, которого надо придерживаться. Просто в случае с Google для дизайнеров устанавливаются гораздо более жесткие рамки.
      • 0
        Я имел в виду не веб-дизайн, а дизайн вообще. У гугла всё делается инженерами для инженеров. С одной стороны это хорошо — мы получаем больше возможностей в их продуктах, они (продукты) функциональней (т.е. для нас, гиков — лучше), чем таковые у конкурентов. А с другой стороны, не инженеру трудно разобраться в этой куче возможностей и функциональностей, если ему нужна одна, максимум две.
  • +1
    Спасибо за конспект!
  • 0
    Это очень интересная тематика. Не секрет, что в такой современной и прогрессивной сфере труда, как разработка ПО, веб-приложений, десктопных и мобильных приложений, тестирование часто ведется допотопным ручным методом: тестеры вручную выполняют однообразные действия. Стоит ли говорить, что эта ситуация требует исправления?

    Мне кажется, необходимо какое-то развитое ПО для автоматизации этого, тот же Selenium весьма сложен и заморочен.
    • –1
      ПО надо. С одной кнопкой — «Сделать хорошо».
  • 0
    Большое спасибо за конспект, почитаю на досуге.
    Тема очень интересная.
  • +15
    Под фразой
    >Для повышения продуктивности инженеров у нас есть специальные инструменты.

    Я представил совершенно другие инструменты)
  • 0
    Спасибо =)
  • –20
    А я пишу код в редакторе, заливаю по фтп, жму F5 в браузере =)) Статью не читал, но озадачен!
    • 0
      И как видно тут одни только мега-спецы собрались без чувства юмора =) Типа Сквидвард cs10059.vkontakte.ru/g23827099/a_1dc122af.jpg =)
      • +5
        Просто иногда юмор бывает не смешной.
        • 0
          Иногда?
          • +2
            Ну да. Юмор бывает смешной. На то он и юмор. Просто иногда шутка не удается. Тогда она не смешная.

            Вот так как-то.
    • +1
      Вам бы подключить ещё FTPFS, чтобы ещё быстрее обновления на сервер попадали.
  • 0
    Все таки автоматизация имеет свои минусы, нередко dev версия хрома выходила с багами, которые легко заметит человек и пропустит машина, например невозможность авторизации на любых сайтах где требуется пароль, или регулярно неработающий менеджер печати.
    • +3
      ну на то она и dev версия, чтобы ее мы с вами тестили :)
  • +7
    Судя по андроиду (особенно по SDK), никак они не тестируют. Глюки переходят из версии в версию, хотя на багтрекерах народ ругается со страшной силой.
    • –1
      например)
      • +6
        Например глюк с обновлением самого SDK, при котором он не может переписать некоторые файлы, потому что они запущены (exe-шники или dll). Не уверен, пофиксили это или еще нет, но несколько версий подряд проблема существовала и решалась либо танцами с бубном в командной строке, либо полным сносом и переустановкой всего SDK.

        Глюки с андроидным календарем и его синхронизацией, насколько я знаю, так и не исправлены. Так что периодически приходится обнулять все данные календаря и вытаскивать их заново с сервера. При этом события, которые были изменены на сервере, в андроид попадают в исходном виде (если нужно, могу дать более подробный алгоритм).

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

        Ну, о том, что андроид (у меня 2.2.1) с завидной регулярностью сам перезагружается, думаю, рассказывать не надо — это достаточно известный факт.

        Эклипс при разработке время от времени наглухо виснет, пытаясь соединиться с эмулятором. Приходится убивать и запускать заново.

        Вобщем, можно еще много рассказывать про то, какой это удобный и стабильный софт.
        • +1
          SDK: Пользуюсь линуксом, нет таких проблем ) Календарем пользуюсь год, все отлично, ни разу такого бага не было. Про перезагрузку вообще смех какой-то) Похоже на какую-то железную проблему у вас. У меня несколько устройств, нигде такой небыло, в т.ч. и на версии 2.2 хотя это было давно )
          • 0
            С календарем проблема возникает, если в нем есть повторяющиеся события (еженедельные, ежемесячные и т.п.). Не умеет андроид с ними работать корректно. Хотя онлайновый календарь и десктопный софт (lightning) все понимают как надо.

            Перезагрузка идет «горячая». То есть, судя по всему, перезагружается только гуй, ядро остается жить. Загрузка начинается сразу с перемигивающейся надписи ANDROID. Так что проблема вряд ли в железе — там бы все уходило в холодную загрузку. Особенно часто случается во время работы аудиоплееров (не важно каких). Гугл в помощь — жалуются люди с совершенно разными девайсами и версиями андроида.
            • 0
              у меня как раз такие события в основном и используются, заполнить недельный отчет, заплатить за квартиру и т.п. Перезагрузки, возможно среди армии девайсов попадаются и плохие? У меня три устройства с кучей разных прошивок, разных версий, разных производителей. Ни разу описанных симптомов не было. Было несколько раз на телефоне уходил сам в полную перезагрузку, но это было на дико кастомной прошивке которая сама глючила. Не повезло вам с железкой. Вот и все. Возможно даже с моделью.
              • 0
                С календарем у меня стандартный сценарий такой. Делаю событие, скажем, на первое число каждого месяца — оплатить какой-нибудь счет. Когда пришло 1 января, я это событие удаляю (только 1 января, остается следующее — в феврале). Удаляю либо в гугле, либо в thunderbird-е. Мне так удобнее. А в телефоне 1 января остается висеть. Надо его и оттуда удалить руками.

                Когда недавно андроидный календарь сильно заглючил (просто падал при запуске), мне пришлось очистить все его данные и пересинхронизировать с сервером. И все события, удаленные в последние несколько месяцев, появились в нем снова. Хотя в гуглокалендаре ими и не пахло.

                Возможно, у вас немного другой способ использования календаря (скажем, вы не удаляете прошедшие события), потому и не сталкивались с глюками.

                Про перезагрузку — она происходит на разных моделях от разных производителей, с разными прошивками, но в похожих ситуациях (аудио, например). Так что это гораздо больше похоже на неисправленные баги в системе, чем на глюки с железом. Так что это вам повезло с комбинацией железо+прошивка.

                Я бы мог привести еще много примеров глюков от гугла, но жалко времени.

                Кстати, эмулятор под линуксом мне в свое время так и не удалось запустить. Он просто вис на загрузке. И на это тоже жаловалось много народу. У некоторых проблема исправлялась отключением чего-то в звуке (уж не та же ли это собака, что и в случае перезагрузок?). Мне не помогло, так что я забил на линукс и работаю под виндой.
        • +1
          > Например глюк с обновлением самого SDK, при котором он не может переписать некоторые файлы, потому что они запущены (exe-шники или dll). Не уверен, пофиксили это или еще нет, но несколько версий подряд проблема существовала и решалась либо танцами с бубном в командной строке, либо полным сносом и переустановкой всего SDK.

          Я думал это сто лет известная проблема Windows.
          • 0
            Это сто лет известная особенность виндовой файловой системы, про которую гугл почему-то забыл и не протестировал как надо обновлялку SDK. В итоге пользователи имеют проблемы.
          • 0
            Вот, кстати, попробовал очередной раз обновить SDK — и снова тот же фейл. Так что гугл, похоже, до сих пор не в курсе. Ну и очевидно, никто этот обновлятор даже не пытался тестировать, хотя уже 16 ревизия пошла.
  • 0
    интересный вебинар, книга я так понимаю еще интереснее…
    пока не нашел… :) буду признателен за наводку
    • +1
      выйдет только в марте этого года.
      Ссылка в официальном блоге на предзаказ на амазоне: goo.gl/Dg3qG
  • +5
    Спасибо за статью, промотивировала посмотреть этот замечательный вебинар. Очень понравилась Q&A session
    Question: — How you motivate developers to write automation tests?
    Answer: — We don’t give them a chance.

    Question: — What you use for measure quality?
    (!) Answer: — How our customers love our products.
    • +3
      Question: — What software development methodology you using in Google?
      Answer: — We don’t name the processes. As soon as you call it Agile, it’s not Agile anymore. We have process that very Agile like, they all modified.
      Очень жду продолжения серии этих вебинаров по performance testing.
  • 0
    Никогда и не сомневался, что все мы для Гугла — лись тестировочное мясо :) Если серьезно, то статья поразила своим взглядом на проблемы. Но вот в чем слабое место Гугла, он оказывает больше внимания алгоритмам, а не пользователям
    • 0
      Согласен с вами, но последнее предложение я бы написал так: «Я бы сказал, он оказывает больше внимания автоматизации выполнения операций, чем их ручному выполнению».
      • 0
        Я немного про другое. Гугл «знаменит» ужасным саппортом — пока все хорошо работает, гугловские сервисы великолепны. Если случается косяк, который требует вмешательства специалистов Гугла, вот тут в полной мере заметно что приоритеты для софта выше. Так же, на мой взгляд, технарский подход ко всему, делает социальные сервисы немного безжизненными что ли. Другими словами, на мой взгляд нельзя чтобы над сервисами работали исключительно технари
  • 0
    сколько раз уже читал, про то, что в гугле люди прям в масле катаются — и 20% времени свободного и график и страховки и питание, и вообще чуть ли не каждый гугло сотрудник может на свою зарплату купить маленькое государство. Но слабо верится в это, конечно есть фотки и отчеты блогеров котрых водят на экскурсии, но сдается, что это маркетинг, как у того же эппла — со стороны — дружная и счастливая организация, а почитаешь историю, так там друг друга подсиживают все кому не лень.
  • +9
    Идея сводится к быстрому созданию продукта, быстрому выпуску, быстрому получению отзывов и быстрому реагированию на них.

    и быстрому закрытию. Хорошая стратегия, мне нравится.
  • –4
    Когда понимаешь, как работают инженеры-программисты крупнейшего поисковика, понимаешь что догнать их, к сожалению, не возможно! Классный конспект и очень поучительный, даже для меня, огромного Чайника...!
  • 0
    Каждый месяц автоматически отбирается лучший dogfood Chrome, он предназначен для наших сотрудников. я подробнее расскажу об инструментах, которые они используют для взаимодействия с разработчиками.

    интересно узнать подробности…
    А так же какие есть практики пользовательского тестирования фич самими разработчиками.
    • 0
      Тут речь шла о BITE Bug Filing tool и Quality Bots. Первый инструмент используется для создания отчетов об ошибках, а второй помогает визуально оценить разницу между отображением сайтов в разных версиях хрома. В вебинаре Джэймс показывает как ими просто пользоваться. Клик, клик, клик и вот уже все готово. Еще он рассказывает о том, что для гуглеров ловля багов так же приоритетна, как и разработка нового функционала. В общем-то он предельно лаконичен и часто ссылается на книгу. Подробности будут там.
  • +1
    <шутка юмора>
    Так и вижу внедрение этой модели в бухгалтерской сфере — «самые преданные» тётушки-бухи сообщают о багах и 1с-ники их быстро правят… а потом пьют валидол…
    </шутка юмора>

    Это я к тому, что, ИМХО, методика живуча только при наличии толпы именно преданных пользователей. Но так хотелось бы внедрять её и в обычных условиях :)
  • 0
    Не знаю, как тестируют, но вчера выпустили глючный падающий YouTube клиент для Android market.android.com/details?id=com.google.android.youtube, причем падает на всех девайсах, да еще и подписки в нем исчезли, хотя зачем они если все равно падает.
  • 0
    Книга Уиттакера «How Google Tests Software» выпущена на русском: habrahabr.ru/post/210634/

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.