Как тестируют в google pdf
Книга «Как тестируют в Google» — бесплатная электронная версия
Привет, Хаброжители!
В книге описано тестирование программных продуктов в Google: как устроены процессы, как организованы команды, какие техники используются, кто ответственен за качество. Принципы, на которых построено тестирование в Google, применимы в проектах и компаниях любого размера. Авторы книги сами работали над продуктами Google, создавая инструменты тестирования, настраивая процессы и занимаясь непосредственно тестированием.
Книга рассчитана на профессионалов из индустрии разработки программного обеспечения: специалистов по тестированию, программистов, менеджеров.
Отрывок. Снижение рисков
Редко удается полностью устранить риски. Мы водим машину, хоть это и опасно, но ведь нужно добираться до работы? Вообще возможность несчастного случая не означает, что он обязательно произойдет, да и, скорее всего, ничего страшного не случится. Почему? Потому что своими действиями мы снижаем возможный риск. Например, не садимся за руль в нетрезвом состоянии и не водим в условиях недостаточной видимости. Таким образом мы снижаем риски.
В разработке программного продукта самое простое — избегать рискованных областей: чем меньше кода, тем меньше риск. Но кроме использования «топора и секиры», мы можем сделать еще много чего, чтобы снизить риски:
В некоторых проектах именно тестировщиков спрашивают о готовности продукта к выпуску. Хорошему тестировщику достаточно бросить взгляд на тепловую карту, чтобы определить, стоит еще подержать продукт в духовке или пора подавать его на стол. Если речь о запуске экспериментального Google Labs, то наличие красных зон риска не так существенно, если они не относятся к безопасности, конечно. А если это выпуск новой версии Gmail, тогда даже желтые зоны представляют серьезную опасность. Такая простая цветовая градация понятна всем, даже топ-менеджерам.
Опасения по поводу рисков со временем спадают, а большой объем успешно проведенного тестирования — это хороший признак того, что риски на приемлемом уровне. Здесь мы выигрываем от того, что связываем тест-кейсы с отдельными возможностями продукта, а затем и с атрибутами и компонентами в таблице рисков. Для этого дела идеально подходит «ACC — анализ», и вот почему мы создали этот инструмент именно таким.
Тест-план за десять минут по рецепту Джеймса Уиттакера
Любая задача в разработке ПО, которую можно решить за десять минут, считается простой или не заслуживающей внимания. Предположим, что мы верим в это, — тогда что мы можем сказать о планирования тестирования? Конечно же, то, что оно занимает более десяти минут. Когда я работал директором по тестированию в Google, я руководил несколькими командами, которые создавали огромное количество тест-планов. Ответы на вопрос о том, сколько времени займет его составление, могли быть такими: «завтра», «к концу недели» и лишь пару раз — «к концу дня» (если задача озвучивалась рано утром). О’кей, примем к сведению, что составление тест-плана занимает некоторое количество часов, а то и дней.
Стоит ли такая работа усилий — это уже совсем другая история. Я вижу десятки тест-планов, которые пишут мои команды, и каждый раз это мертворожденные документы — они создаются, рецензируются, обновляются один или два раза (если повезет), а потом уверенно откладываются в долгий ящик, как только проект начинает идти не так, как это было предусмотрено. Возникает вопрос: если план не стоит того, чтобы его обновлять, стоило ли
его создавать?
Иногда тест-план нежизнеспособен потому, что содержит слишком много или, наоборот, слишком мало подробностей. Или он способствовал началу работы, а вот процессу — уже нет. И снова вопрос знатокам: стоило ли создавать документ с ограниченной или постоянно уменьшающейся ценностью?
Некоторые тест-планы содержат настолько очевидную информацию, что ее и документировать-то не стоило. Мы просто зря тратим время. Давайте посмотрим правде в глаза: у нас проблема с тест-планами.
Чтобы справиться с этим, я придумал для своей команды простое задание: написать тест-план за десять минут. Если уж он и имеет какую-то ценность, то давайте доберемся до нее как можно скорее.
Когда у вас есть всего десять минут для решения задачи, каждая секунда становится значимой. В этом моя основная идея: ограничение во времени заставляет отсекать при планировании всю шелуху и концентрироваться только на важных моментах. Делайте только то, что абсолютно необходимо, оставьте подробности исполнителям тестов. Я хотел покончить с порочной
практикой написания нежизнеспособных тест-планов, и это упражнение показалось мне верным.
Однако я ничего этого я не говорил участникам эксперимента. Я просто сказал: «Вот приложение, составьте тест-план не более чем за десять минут». Имейте в виду, что эти люди получали зарплату за то, что они выполняли мои задачи. И все же я предполагал, что они испытывали ко мне определенное уважение, а следовательно, знали, что я не поручу им невыполнимую задачу.
Они могли потратить некоторое время на знакомство с приложением, но, так как речь шла о приложениях, которые они используют каждую неделю (Google Docs, App Engine, Talk Video и т. д.), я дал им совсем немного времени на это.
Во всех случаях команды изобретали методы, схожие с методами ACC-анализа. Они оформляли решения в форме таблиц и списков, не используя большие объемы текста. То есть предложениям — да, абзацам текста — нет. Они не тратили время на форматирование текста, не вдавались в излишние объяснения. У всех тест-планов было одно общее — команды документировали возможности. Они признали, что это было лучшим решением, куда потратить весьма ограниченное время.
О’кей, ни одна команда не завершила тест-план вовремя. Тем не менее они успели за десять минут пройтись по атрибутам и компонентам и начали вычленять возможности исследуемого продукта. К концу дополнительных двадцати минут большинство моих подопытных записали довольно большой набор возможностей, который мог бы служить отличной отправной точкой
при создании тест-кейсов и пользовательских историй.
Мне кажется, что эксперимент удался. Я выделил им десять минут, хотя ориентировался на час. В итоге за полчаса было выполнено 80% работы. Разве этого недостаточно? Мы точно знаем, что не будем тестировать все, ну и зачем нам все документировать? Мы отлично знаем, что в ходе тестирования многие вещи (графики, требования, архитектура) будут изменяться. Настаивать на скрупулезной точности планирования, когда завершенность вовсе не требуется, не имеет смысла.
Восемьдесят процентов работы выполнено за тридцать минут или даже меньше. Вот это я называю десятиминутным тест-планом!
Напоследок о рисках
Google Test Analytics берет за основу описанные выше критерии оценки рисков («очень редко», «редко», «иногда», «часто»). Мы специально не хотим превращать анализ рисков в сложную задачу, иначе она не будет выполнена. Нас не интересуют точные математические подробности, потому что цифры мало что значат. Достаточно знать, что «А» рискованнее «Б», не обращая внимания на точное значение рисков. Простое знание, какая возможность рискованнее другой, позволит тест-менеджеру более эффективно распределять работу тестировщиков. А такие люди, как Патрик Коупленд, смогут легко решать, сколько тестировщиков нужно назначить в каждую команду разработки. Понимание рисков приносит пользу на уровне всей компании.
Анализ рисков — это самостоятельная научная область, уважаемая во многих отраслях. Мы используем упрощенную версию методологии, но это не мешает нам интересоваться новыми исследованиями, чтобы улучшить свой подход к тестированию. Если вы хотите узнать больше об анализе рисков, то начните со статьи «Управление рисками» в Википедии.
GTA помогает обозначить риски, а тестирование помогает их снизить. Тестировщик служит посредником в этом процессе. Он может выполнить внутренние тесты по некоторым наиболее рискованным направлениям или поставить задачу разработчикам и разработчикам в тестировании, чтобы они добавили регрессионные тесты. В его арсенале есть и другие инструменты: исследовательское тестирование, привлечение внутренних и бета-пользователей и силы внешнего сообщества.
В ответственности тестировщика знать все подверженные рискам области. Он должен стараться снизить риски любыми способами, которые ему подвластны. Вот несколько рекомендаций, которые мы считаем полезными в борьбе с рисками.
Пользовательские сценарии
Пользовательские истории описывают реальные или смоделированные способы, которыми пользователи используют приложение. Они описывают, чего хотят пользователи, смотрят на продукт их глазами, не учитывая архитектуру приложения и детали реализации.
Истории могут быть связаны с возможностями, но лишь поверхностно, поскольку все-таки подчинены действиям пользователя. Пользователю что-то нужно, а история описывает, как он использует приложение, чтобы это получить. Истории намеренно описаны в общем виде, без конкретных шагов, без жестко заданных входных данных. Только то, что будет делать пользователь, и как это воспроизвести во время тестирования приложения.
Создавая пользовательскую историю, мы смотрим на продукт только через пользовательский интерфейс, мы не включаем в описание технические подробности. Тогда тестировщик будет каждый раз проходить этот путь по-разному, как и разные пользователи по-разному решают одну и ту же задачу в нашем приложении — вот в чем главная идея!
Главное в пользовательских историях — ценность продукта для пользователя. Это не тест-кейсы с их определенными вводными данными и ожидаемыми результатами. Хорошая практика — создавать отдельные учетные записи. Мы в Google часто создаем помногу тестовых учетных записей для пользователей, описанных в историях. Старые аккаунты могут быть полезны по-другому: при тестировании Google Documents мы выявили самые интересные баги как раз для старых учетных записей — при загрузке в новой версии документов, созданных в предыдущих версиях.
Мы стараемся, чтобы тестировщики, исполняя такие сценарии, менялись. Чем больше разных способов прохождения — тем лучше.
Мы не будем слишком придираться к возможностям с низкими рисками. Мы можем решить, что писать тест-кейсы для этих областей — слишком затратное занятие. Вместо этого мы можем ограничиться исследовательским тестированием или оставить на откуп краудсорс-тестированию. Чтобы управлять работой тестировщиков из внешнего сообщества, мы часто пользуемся концепцией туров — это высокоуровневые инструкции для исследовательского тестирования. Проще говоря, такой подход дает вашему запросу нужную конкретику. Например, попросив сообщество: «Проведите FedEx-тур для такого-то набора возможностей», — мы получим намного лучший результат, чем просто отдав приложение и понадеявшись на лучшее. Мы сразу определяем фичи, которые нужно протестировать, и даем инструкции, как это делать.
Краудсорсинг
Краудсорсинг— это новое явление в тестировании. Если тестировщиков не хватает, а их ресурсы ограничены, то краудсорс-тестирование спешит на помощь! Пользователей с разными наборами устройств и программных конфигураций намного больше, чем тестировщиков. О таком количестве тестовых окружений нам остается только мечтать. Наверняка ведь найдутся желающие помочь нам?
Представим, что есть группа опытных пользователей, которые разбираются в тестировании и согласились нам помочь за разумную плату. Все, что им нужно, — это доступ к среде, где они могут работать с приложением, и отлаженный механизм предоставления обратной связи и баг-репортов. Для таких проектов, как наш опенсорсный Chromium, тестирование при помощи большой группы людей подходит идеально. Однако для проектов, открытых только внутри компании, это более проблематично. Нужно отбирать тестировщиков, пользующихся особым доверием.
Еще одна ключевая ценность краудсорсинга (кроме множества конфигураций) — это более широкий взгляд на приложение. Вместо того чтобы один тестировщик имитировал действия тысячи пользователей, у нас есть тысяча пользователей, работающих как тестировщики. Есть ли лучший способ найти сценарии, приводящие приложение к сбою, чем сразу выдать эти сценарии пользователям и получить обратную связь? Разнообразие и масштаб — вот в чем ценность краудсорсинга.
Людей, желающих протестировать программный продукт, в избытке, и доступны они круглосуточно. Допустим, дано: топ-1000 сайтов, задача: протестировать их в последней версии Chrome, тогда решение: 1 тестировщик = 1000 итераций или 20 тестировщиков = 50 итераций. Математика на стороне краудсорсинга.
Главный недостаток тестирования сообществом в том, что им нужно время, чтобы разобраться с приложением и понять, с какой стороны лучше подойти к тестированию. Большая часть этого времени теряется впустую изза количества людей, но мы придумали, как с этим справляться. Для Chrome, например, мы написали туры, и внешние тестировщики следовали им при исследовательском тестировании и при выполнении пользовательских сценариев (примеры есть в приложении Б «Туры тестов для Chrome»). Туры сразу направляли тестировщиков к нужным частям приложения и давали необходимые инструкции. Фокус в том, чтобы сделать разные наборы туров и распределить их между участниками. Так мы избежали варианта «принеси то, не знаю что» и получили именно то, о чем просили.
Краудсорс-тестирование — это следующий этап развития стандартных каналов Google: канареечного канала, канала разработки, тестового канала и канала внутреннего продукта. Это наш способ привлечения ранних пользователей и людей, которым просто нравится искать баги и сообщать о них. Мы уже попробовали набирать тестировщиков внутри компании среди наших коллег, которые любят работать со свежим продуктом, подключать к командам людей из компаний поставщиков, пользоваться услугами коммерческих компаний краудсорсинга (например, uTest). Мы даже запустили программу поощрения лучших искателей багов.
Итак, сила ACC-анализа в том, что мы получаем список возможностей продукта, который можно упорядочить по риску и закрепить за разными исполнителями. Тестировщики, работающие над одним проектом, могут получить разные наборы возможностей для проверки. Внутренние пользователи, «двадцатипроцентные» участники, тестировщики-подрядчики, тестировщики из сообщества, разработчики, разработчики в тестировании — все получат свои списки возможностей, и, к радости тестировщика, важные области будут покрыты с меньшим перекрытием, чем если бы мы просто раздали приложение для тестирования всем желающим.
Работа тестировщика, в отличие от работы разработчика в тестировании, с впуском продукта не заканчивается.
Как тестируют в Google
Программисты Google предпочитают качество широте функциональности.
Качество ≠ Тестирование
Фраза «тестирование не определяет качество» уже настолько избита, что просто обязана быть правдой. В любой области разработки, от автомобилей до софта, не получится отточить продукт до совершенства, если он изначально неправильно сконструирован. Спросите любого автопроизводителя, который хоть раз отзывал партию своих машин, чего стоят запоздалые попытки прикрутить качество на готовое изделие. Делайте все правильно с самого начала, не создавайте себе лишних трудностей. Тем не менее это только звучит просто. С одной стороны, качество и не создается тестированием, с другой — без тестирования сделать качественный продукт невозможно. Как вы узнаете, насколько качественный ваш продукт, не проводя тестирование?
Эта головоломка решается легко: перестаньте рассматривать разработку и тестирование по отдельности. Тестирование и разработка идут рука об руку. Напишите немного кода и протестируйте его. Затем напишите еще чуть-чуть и снова протестируйте. Тестирование не отдельная практика, это часть самого процесса разработки. Одним только тестированием качества не добиться. Рецепт получения высокого качества: смешивайте разработку и тестирование в блендере, пока они не станут единой субстанцией.
В издательстве «ПИТЕР» вышла книга «Как тестируют в Google». Книга издана ограниченным тиражом.
В книге описано тестирование программных продуктов в Google: как устроены процессы, как организованы команды, какие техники используются, кто ответственен за качество. Принципы, на которых построено тестирование в Google, применимы в проектах и компаниях любого размера. Авторы книги сами работали над продуктами Google, создавая инструменты тестирования, настраивая процессы и занимаясь непосредственно тестированием.
Всего несколько дней вы можете приобрести ее в электронном виде по самым низким ценам.
Книга доступна в бумажном виде — 613 рублей
В формате PDF — 99 рублей
В формате EPUB — 99 рублей
Как 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 используют эту систему и поэтому мы хотим рационально распределять время между ними. Система попеременно вставляет маленькие тесты между большими и в результате работает непрерывно.
Еще несколько слов о тестах
Мы стремимся автоматизировать все проверки. Если результат может быть проверен машиной, мы автоматизируем ее. Если нет необходимости в человеческой оценке, мы автоматизируем этот тест. Если проверку нужно осуществить несколько раз мы автоматизируем ее. Если что-то нельзя оставить на волю случаю, мы автоматизируем это. Только в случае если эти условия неприменимы, мы позволяем разработчикам тестировать вручную. Но даже когда тест выполняется вручную мы записываем его при помощи js приложения. Это позволяет нам воспроизводить такие тесты и многократно использовать их. Позже я расскажу об этом приложении.
Мы тестируем даже читабельность кода. Каждая строчка на c++, phyton, java и java script проверяется на читабельность внутри нашего процесса разработки.
И инженеры, и тестировщики используют одно и то же окружение. Все используют одну и ту же версию linux, независимо от задачи, будь то в датацентре на серверах или на десктопе у разработчика. Однородность среды очень важна для воспроизведения ошибок. Для нас local = test = staging = production. Если у вас не так, предлагаю вам над этим серьезно подумать.
ACC — 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 и проверяет расположение всех управляющих элементов на странице. Конечно, сайты на которых есть реклама каждый день будут выглядеть по разному. Для нас важно, чтобы они были приблизительно похожими. Если это так, то мы считаем тест пройденным.