Прослушав вебинар «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 используют эту систему и поэтому мы хотим рационально распределять время между ними. Система попеременно вставляет маленькие тесты между большими и в результате работает непрерывно.
Маленькие тесты:
Средние тесты:
Большие тесты:
Мы стремимся автоматизировать все проверки. Если результат может быть проверен машиной, мы автоматизируем ее. Если нет необходимости в человеческой оценке, мы автоматизируем этот тест. Если проверку нужно осуществить несколько раз мы автоматизируем ее. Если что-то нельзя оставить на волю случаю, мы автоматизируем это. Только в случае если эти условия неприменимы, мы позволяем разработчикам тестировать вручную. Но даже когда тест выполняется вручную мы записываем его при помощи js приложения. Это позволяет нам воспроизводить такие тесты и многократно использовать их. Позже я расскажу об этом приложении.
Мы тестируем даже читабельность кода. Каждая строчка на c++, phyton, java и java script проверяется на читабельность внутри нашего процесса разработки.
И инженеры, и тестировщики используют одно и то же окружение. Все используют одну и ту же версию linux, независимо от задачи, будь то в датацентре на серверах или на десктопе у разработчика. Однородность среды очень важна для воспроизведения ошибок. Для нас local = test = staging = production. Если у вас не так, предлагаю вам над этим серьезно подумать.
Когда я только пришел в 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. BITE тоже был выпущен, как opensource приложение. Оно позволяет записывать действия в браузере, а затем воспроизводить этот материал. Этим инструментом пользуются все гуглеры, тестеры наших внутренних dogfood релизов. Они помогают нам создавать проверочные тесты. Подробнее об этом вы можете почитать в нашем блоге.
Для меня не важно как много книжек по созданию тестов вы прочли. Более того я даже являюсь автором одной из таких книг. Я убежден, что пользы от ваших тестов будет меньше чем от настоящих пользователей. Они работают в реальной среде, а не в той, которую вы воссоздаете. У них есть настоящие данные, а не те, что вы выдумали. Они используют свои собственные сценарии работы, а не те, которые подражают таковым. Вы тестер, который всего лишь претендует быть пользователем. Пользователи не претендуют на это звание, они и есть пользователи. Поэтому мы решили превратить пользователей в тестеров. Если вы подумаете о google maps, а это еще один продукт, которому я посвятил немало времени. Вы поймете, что только пользователи могут достоверно проверить данные окружающей их действительности. Как мы вообще можем проверять такие вещи? Серьезно, это задача мирового масштаба, буквально. Только тот, кто живет на этой улице способен распознать, что на карте ошибка. Хоть мы и google, мы не можем нанять тестеров, чтобы перепроверить всю землю. Мы должны доверять своим пользователям и мы должны опираться на их знания. В результате получается, что это хорошая мысль, ведь они лучше нас. В данный момент эта утилита не открыта. Она напрямую подключена к нашей базе данных ошибок. Когда вы кликаете по карте эта утилита делает снэпшоты dom структуры, собирает информацию о бразуре, операционной системе, словом все то, что необходимо для воспроизведения ошибок.
И на последок я расскажу о еще одной утилите, которую мы используем для тестирования браузера Chrome. Когда мы только приступили к тестированию хрома, мы делали много проверок вручную. На самом деле они для меня были лишены всякого смысла. Для нас было важно не «поломать интернет». Для нас было важно, чтобы Chrome продолжал правильно отображать популярные сайты. Мы не хотели выпустить браузер, который бы не отрисовывал cnn, facebook или другие популярные сервисы. Конечно, лекго сделать тест на загрузку популярной сотни сайтов и узнать вызывают ли они крах браузера. Правда, это не совсем то, что нам нужно. В действительности мы хотим проверять 10 тысяч самых популярных сайтов и сверять так ли они выглядят в старой версии нашего браузера и как они выглядят сейчас в Firefox, Safari, и IE. Приложение, которое мы сделали называется Quality Bots, о нем мы тоже рассказали в нашем блоге. Приложение делает две вещи. Сравнивает DOM и проверяет расположение всех управляющих элементов на странице. Конечно, сайты на которых есть реклама каждый день будут выглядеть по разному. Для нас важно, чтобы они были приблизительно похожими. Если это так, то мы считаем тест пройденным.
Те кто заинтересован в подробностях, могут зафоловить твиттер Джэймса, загруглить его в плюсах или почитать блог, где регулярно появляются статьи по данной тематике.
Его ведет Джэймс Витакер, который в данный момент занимает пост технического директора по тестированию ПО в 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 и проверяет расположение всех управляющих элементов на странице. Конечно, сайты на которых есть реклама каждый день будут выглядеть по разному. Для нас важно, чтобы они были приблизительно похожими. Если это так, то мы считаем тест пройденным.
Эпилог
Те кто заинтересован в подробностях, могут зафоловить твиттер Джэймса, загруглить его в плюсах или почитать блог, где регулярно появляются статьи по данной тематике.
