Текст книги "Как тестируют в Google"

Автор книги: Джеймс Уиттакер

Соавторы: Джефф Каролло,Джейсон Арбон
сообщить о нарушении

Текущая страница: 11 (всего у книги 26 страниц)

– Простой: удобно создавать и изменять круги.

– Расширяемый: передавать данные о кругах службам и приложениям.

Оповещения:

– Простой: показывать оповещения кратко.

– Расширяемый: отправлять оповещения другим службам и приложениям.

Видеочат:

– Социальный: приглашать свои круги в видеочат.

– Социальный: открыть свой видеочат публике.

– Социальный: оповещать других пользователей в своих лентах о видеочатах.

– Простой: создавать видеочат и принимать в нем участие в несколько кликов.

– Простой: отключить в один клик видео– и аудиоданные.

– Простой: приглашать дополнительных пользователей в существующий видеочат.

– Выразительный: посмотреть, как видеочат будет выглядеть для других.

– Расширяемый: общаться в текстовом чате во время видеочата.

– Расширяемый: включать видеоролики с YouTube в видеочат.

– Расширяемый: настраивать устройства в Настройках.

– Расширяемый: участвовать в видеочатах без веб-камеры, используя аудиоканал.

– Конфиденциальный: ограничивать доступ в видеочат только для приглашенных гостей.

– Конфиденциальный: оповещать только приглашенных гостей о видеочате.

Записи:

– Выразительный: выражать свои мысли.

– Конфиденциальный: ограничивать сообщения выбранной аудиторией.

Комментарии:

– Выразительный: выражать свое мнение с помощью комментариев.

– Расширяемый: передавать данные комментариев для использования другими службами и приложениями.

– Конфиденциальный: ограничивать сообщения выбранной аудиторией.

Фотографии:

– Социальный: делиться фотографиями с контактами и друзьями.

– Простой: легко загружать новые фотографии.

– Простой: легко импортировать фотографии из других источников.

– Расширяемый: интегрироваться с другими фотослужбами.

– Конфиденциальный: ограничивать доступ к фотографиям только для выбранной аудитории.

На рис. 3.6 приведены результаты ACC-анализа в форме электронной таблицы.

Рис. 3.6. Электронная таблица ACC для Google+

А на рис. 3.7 эти же данные представлены в другой форме.

Рис. 3.7. Таблица ACC для Google+

Риск

Риски повсюду. Дома, на дорогах, на работе. Все, что мы делаем, включает в себя элемент риска, и разработка ПО – не исключение. Чтобы обезопасить свою жизнь, мы покупаем безопасные автомобили и водим осторожно. На совещаниях мы следим за своими словами и стараемся попасть на проекты, которые сможем выполнить, – все это для того, чтобы уменьшить риск остаться без работы.

А что сделать, чтобы уменьшить риск выпуска некачественного программного продукта? Как предотвратить опасность возникновения сбоев в выпускаемых нами программах, как уберечь нашу компанию от вероятного ущерба ее репутации? Разумеется, отличный способ минимизировать риски – не выпускать программу. Нет программы – нет риска. Но секрет вот в чем: мы получаем прибыль от выпуска программного обеспечения, если хорошо просчитываем риски.

Именно «просчитываем», не «вычисляем» – мы не гонимся за математической точностью. Мы ходим по тротуарам, а не гуляем по проезжей части, потому что так безопаснее, а вовсе не потому, что чьи-то расчеты показали, будто так мы снизим риск попасть под машину на 59%. Мы покупаем машины с подушками безопасности не потому, что помним точные статистические данные повышения выживаемости, а просто это всем известно: подушка безопасности снизит риск разбить голову о руль. Все. Работа по снижению рисков может быть максимально эффективной и безо всяких трудоемких математических расчетов. Такая работа называется анализом рисков.

Анализ рисков

В осознании и просчитывании рисков, которые следует учитывать при тестировании, главным помощником был и остается здравый смысл. Переключим здравый смысл в режим «включено» и ответим на следующие важные вопросы:

– О каких событиях нам следует беспокоиться?

– Насколько такие события вероятны?

– Каким может быть от них ущерб для нашей компании?

– Каким может быть от них ущерб для будущих пользователей?

– Есть ли в программе защита от возникновения нежелательных событий?

– Какова вероятность того, что такая защита не сработает?

– Во сколько нам обойдется такой сбой защиты?

– Насколько сложно будет восстановиться после такого сбоя?

– Нежелательное событие может случиться вновь или эта проблема может быть одноразовой?

Нет резона использовать математический расчет при анализе рисков просто потому, что количество вероятных переменных настолько велико, что на их точный расчет уйдет больше сил, чем на саму минимизацию рисков. В Google мы сводим все риски к двум факторам: частота сбоеви степень воздействия. Для каждой возможности в разрабатываемом продукте тестировщики присваивают этим двум факторам простые значения. Именно простые, а не идеально точные. Нам ведь нужно просто определить, какие возможности следует тестировать и в каком порядке. Для этого достаточно понять, какая возможность несет в себе больший риск, а какая меньший. В этом нам здорово помогает GTA (рис. 3.8).

GTA использует четыре оценки частоты появления сбоев:

– Очень редко: трудно представить ситуацию, при которой возникнет проблема, но если такое случится, то ее решение будет простым.

Пример:страница загрузки браузера Google Chrome. [37]37
  http://www.google.com/chrome


[Закрыть]В основном содержимое этой страницы статично, автоматика там срабатывает только при определении клиентской ОС. Если произойдет сбой в базовом коде HTML или в сценарии на странице, то его быстро обнаружит мониторинг кода.

– Редко: есть случаи, когда может произойти сбой. Однако из-за невысокой сложности процесса или редкого использования такое случается нечасто.

Пример:кнопка «Вперед» в Chrome. Эта кнопка используется, но гораздо реже, чем ее напарница кнопка «Назад». Так сложилось, что ее работа редко приводит к сбоям, а если такое все-таки случится, то проблема будет быстро перехвачена еще на этапе тестирования раннего выпуска нашими первыми пользователями.

– Иногда: такой сбой легко представить, хотя он и достаточно сложен технически, а возможность продукта, как мы считаем, будет популярна у пользователей.

Пример:Возможности Chrome Sync. Chrome синхронизирует закладки, темы, заполнение форм, историю просмотра страниц и другие данные пользователя между компьютерами. Есть много типов данных и платформ ОС, поэтому слияние изменений – задача непростая. Если произойдет сбой синхронизации данных, пользователь, вероятнее всего, это заметит. Синхронизация выполняется только в том случае, когда происходят изменения в синхронизируемых данных – например, пользователь добавил новую закладку.

Рис. 3.8. Оценка риска по частоте и воздействию в GTA для Google+

– Часто: если в возможности, которая входит в часто используемую фичу, регулярно происходят сбои.

Пример:отображение веб-страниц. Основная задача браузера – отобразить HTML, CSS и код JavaScript любого происхождения и качества. Даже если исходный загружаемый код будет технически неправильным, пользователь решит, что проблема в браузере. Риск сильно возрастает, если мы рассматриваем сайт с высоким уровнем трафика. Проблемы отображения не всегда могут быть обнаружены пользователем: визуально элемент может съехать, но тем не менее остается рабочим. Или он может исчезнуть совсем, но тогда как пользователь узнает, что он вообще был?

Итак, тестировщик выбирает одно из этих значений для каждой возможности. Мы специально сделали четыре варианта оценки, чтобы тестировщик не вздумал постоянно выбирать средний вариант. Здесь нужно серьезно подумать.

Для оценки воздействия мы используем такой же упрощенный метод, с таким же количеством вариантов (снова возьмем браузер Chrome для примера).

Воздействие может быть:

– Минимальным: сбой, который пользователь может не заметить.

Пример: есть такой дополнительный сервис Chrome Labs. Его функциональность необязательна для работы, и сбой при загрузке страницы chrome://labs затронет лишь нескольких пользователей. Эта страница содержит дополнительные, экспериментальные фичи Chrome, о которых большинство людей даже не знают. Сами фичи снабжены пометкой «Используйте на свой страх и риск». Проще говоря, компания не несет ответственности за сбои, но зато и угроз для работы браузера нет.

– Небольшим: сбой, который может вызвать раздражение у пользователя. Если случается – механизмы повтора и восстановления легкодоступны.

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

– Существенным: сбой заблокирует выполнение пользовательских сценариев.

Пример:расширения Chrome. Если пользователь установил расширения в свой браузер, а в новой версии Chrome возник сбой при загрузке этих расширений, это провал.

– Максимальным: сбой нанесет удар по репутации продукта и заставит пользователей отказаться от работы с ним.

Пример:механизм автообновления Chrome. Если эта возможность отвалится, то браузер лишится важных обновлений безопасности или вовсе прекратит работать.

Иногда сбои приводят к разным последствиям у пользователя и компании. Допустим, перестал работать рекламный баннер. Проблема ли это для пользователя? Нет, он даже может не заметить. Проблема ли для Google? Да, конечно. Поэтому, анализируя риски, указывайте, кто пострадает.

Данные, которые присвоил рискам тестировщик, можно наложить на готовую таблицу «атрибут/компонент» для Google Sites. Таким образом мы получим тепловую карту рисков (рис. 3.9).

Рис. 3.9. Тепловая карта рисков для таблицы «атрибут/компонент» (ранняя версия Google+)

Ячейки окрашиваются в красные, желтые или зеленые цвета в зависимости от уровня риска компонентов. Очень просто вычислить примерный уровень риска для каждого значения – мы просто усредняем риски его возможностей. Эта карта была сделана в GTA, но с той же задачей справится и обыкновенная электронная таблица.

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

– Разработчики.Большинство разработчиков присвоят максимальное значение риска функции, которую писали они. Естественно, они хотят, чтобы их код был протестирован! Каждый кулик хвалит свое болото, но наш опыт подсказывает, что «кулик» часто переоценивает те функции, за которые он отвечает.

– Руководитель проекта.Удивительно, но руководители проектов тоже люди, и их оценка тоже может быть субъективной. Для них наиболее важными считаются те функции, которые позволят продукту выделиться на рынке и стать хитом.

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

– Директора и вице-президенты.Топ-менеджеров обычно интересуют те возможности продукта, которые качественно отличают его от главных конкурентов.

Итак, у всех мнений есть погрешность. Чтобы бороться с этим, мы опрашиваем всех заинтересованных в проекте людей по отдельности и просим оценить риски по описанным выше двум факторам. Их не так легко уговорить на эту работу, но мы, кажется, нашли успешную стратегию. Вместо того чтобы вдаваться в объяснения процесса и упрашивать участников нам помочь, мы просто делаем все сами и показываем им уже готовую тепловую карту. Как только они видят наше мнение, они мгновенно выплескивают свое. Разработчики активно принимают участие, если понимают, что мы используем карту для расстановки приоритетов в тестировании. Так же ведут себя и руководители проектов, и менеджеры по продажам. Все они заинтересованы в его качестве.

Есть в этом подходе определенная сила. Когда мы определяем риски самостоятельно, мы несомненно приходим к варианту, с которым другие участники проекта не будут согласны. Так и есть, подготавливая для них наш вариант анализа рисков, мы даем им почву для споров. В этом идея. Мы не спрашиваем их о каких-то абстрактных понятиях, мы даемим конкретные выводы, которые можно оспорить. Люди не всегда могут сказать, каким должен быть правильный ответ, но легко скажут, каким он быть не должен. Такой хитрый подход приносит нам много правдивых данных для вычисления рисков.

Когда риски будут согласованы, можно приступать к их последовательному снижению.

Снижение рисков

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

В разработке программного продукта самое простое – избегать рискованных областей: чем меньше кода, тем меньше риск. Но кроме использования «топора и секиры», мы можем сделать еще много чего, чтобы снизить риски:

– Мы можем проработать пользовательские истории вокруг наиболее рискованных возможностей, определить самые безопасные пути и показать их разработчикам, чтобы те ввели в приложение больше ограничений.

– Мы можем написать регрессионные тест-кейсы, чтобы убедиться, что мы отловим повторные сбои.

– Мы можем написать и запустить тесты, подтверждающие необходимость добавить механизм восстановления и отката.

– Мы можем добавить средства контроля и сторожевой код для оперативного обнаружения сбоев.

– Мы можем добавить инструменты, которые будут отслеживать изменения в поведении продукта в его разных версиях. Мы получим сигнал, если возникнет регрессионный баг.

Конкретное решение зависит от особенностей приложения, от ожиданий пользователя в отношении его безопасности и надежности. Как тестировщики, мы, конечно, можем быть вовлечены и в процесс снижения рисков, но мы безусловно вовлечены в процесс их выявления. Мы начинаем с приоритизации возможностей, отмеченных в таблице красным. Мы хотим тестировать в порядке уменьшения рисков. Это важно: если не можешь протестировать все – протестируй сначала самое важное.А самое важное – это то, что больше всего подвержено самым серьезным рискам.

В некоторых проектах именно тестировщиков спрашивают о готовности продукта к выпуску. Хорошему тестировщику достаточно бросить взгляд на тепловую карту, чтобы определить, стоит еще подержать продукт в духовке или пора подавать его на стол. Если речь о запуске экспериментального Google Labs, то наличие красных зон риска не так существенно, если они не относятся к безопасности, конечно. А если это выпуск новой версии Gmail, тогда даже желтые зоны представляют серьезную опасность. Такая простая цветовая градация понятна всем, даже топ-менеджерам.

Опасения по поводу рисков со временем спадают, а большой объем успешно проведенного тестирования – это хороший признак того, что риски на приемлемом уровне. Здесь мы выигрываем от того, что связываем тест-кейсы с отдельными возможностями продукта, а затем и с атрибутами и компонентами в таблице рисков. Для этого дела идеально подходит «ACC-анализ», и вот почему мы создали этот инструмент именно таким.

Тест-план за десять минут по рецепту Джеймса Уиттакера

Любая задача в разработке ПО, которую можно решить за десять минут, считается простой или не заслуживающей внимания. Предположим, что мы верим в это, – тогда что мы можем сказать о планирования тестирования? Конечно же, то, что оно занимает более десяти минут. Когда я работал директором по тестированию в Google, я руководил несколькими командами, которые создавали огромное количество тест-планов. Ответы на вопрос о том, сколько времени займет его составление, могли быть такими: «завтра», «к концу недели» и лишь пару раз – «к концу дня» (если задача озвучивалась рано утром). О’кей, примем к сведению, что составление тест-плана занимает некоторое количество часов, а то и дней.

Стоит ли такая работа усилий – это уже совсем другая история. Я вижу десятки тест-планов, которые пишут мои команды, и каждый раз это мертворожденные документы – они создаются, рецензируются, обновляются один или два раза (если повезет), а потом уверенно откладываются в долгий ящик, как только проект начинает идти не так, как это было предусмотрено. Возникает вопрос: если план не стоит того, чтобы его обновлять, стоило ли его создавать?

Иногда тест-план нежизнеспособен потому, что содержит слишком много или, наоборот, слишком мало подробностей. Или он способствовал началу работы, а вот процессу – уже нет. И снова вопрос знатокам: стоило ли создавать документ с ограниченной или постоянно уменьшающейся ценностью?

Некоторые тест-планы содержат настолько очевидную информацию, что ее и документировать-то не стоило. Мы просто зря тратим время. Давайте посмотрим правде в глаза: у нас проблема с тест-планами.

Чтобы справиться с этим, я придумал для своей команды простое задание: написать тест-план за десять минут. Если уж он и имеет какую-то ценность, то давайте доберемся до нее как можно скорее.

Когда у вас есть всего десять минут для решения задачи, каждая секунда становится значимой. В этом моя основная идея: ограничение во времени заставляет отсекать при планировании всю шелуху и концентрироваться только на важных моментах. Делайте только то, что абсолютно необходимо, оставьте подробности исполнителям тестов. Я хотел покончить с порочной практикой написания нежизнеспособных тест-планов, и это упражнение показалось мне верным.

Однако я ничего этого я не говорил участникам эксперимента. Я просто сказал: «Вот приложение, составьте тест-план не более чем за десять минут». Имейте в виду, что эти люди получали зарплату за то, что они выполняли мои задачи. И все же я предполагал, что они испытывали ко мне определенное уважение, а следовательно, знали, что я не поручу им невыполнимую задачу.

Они могли потратить некоторое время на знакомство с приложением, но, так как речь шла о приложениях, которые они используют каждую неделю (Google Docs, App Engine, Talk Video и т.д.), я дал им совсем немного времени на это.

Во всех случаях команды изобретали методы, схожие с методами ACC-анализа. Они оформляли решения в форме таблиц и списков, не используя большие объемы текста. То есть предложениям – да, абзацам текста – нет. Они не тратили время на форматирование текста, не вдавались в излишние объяснения. У всех тест-планов было одно общее – команды документировали возможности. Они признали, что это было лучшим решением, куда потратить весьма ограниченное время.

О’кей, ни одна команда не завершила тест-план вовремя. Тем не менее они успели за десять минут пройтись по атрибутам и компонентам и начали вычленять возможности исследуемого продукта. К концу дополнительных двадцати минут большинство моих подопытных записали довольно большой набор возможностей, который мог бы служить отличной отправной точкой при создании тест-кейсов и пользовательских историй.

Мне кажется, что эксперимент удался. Я выделил им десять минут, хотя ориентировался на час. В итоге за полчаса было выполнено 80% работы. Разве этого недостаточно? Мы точно знаем, что не будем тестировать все, ну и зачем нам все документировать? Мы отлично знаем, что в ходе тестирования многие вещи (графики, требования, архитектура) будут изменяться. Настаивать на скрупулезной точности планирования, когда завершенность вовсе не требуется, не имеет смысла.

Восемьдесят процентов работы выполнено за тридцать минут или даже меньше. Вот это я называю десятиминутным тест-планом!

Напоследок о рисках

Google Test Analytics берет за основу описанные выше критерии оценки рисков («очень редко», «редко», «иногда», «часто»). Мы специально не хотим превращать анализ рисков в сложную задачу, иначе она не будет выполнена. Нас не интересуют точные математические подробности, потому что цифры мало что значат. Достаточно знать, что «А» рискованнее «Б», не обращая внимания на точное значение рисков. Простое знание, какая возможность рискованнее другой, позволит тест-менеджеру более эффективно распределять работу тестировщиков. А такие люди, как Патрик Коупленд, смогут легко решать, сколько тестировщиков нужно назначить в каждую команду разработки. Понимание рисков приносит пользу на уровне всей компании.

Анализ рисков – это самостоятельная научная область, уважаемая во многих отраслях. Мы используем упрощенную версию методологии, но это не мешает нам интересоваться новыми исследованиями, чтобы улучшить свой подход к тестированию. Если вы хотите узнать больше об анализе рисков, то начните со статьи «Управление рисками» в Википедии.

GTA помогает обозначить риски, а тестирование помогает их снизить. Тестировщик служит посредником в этом процессе. Он может выполнить внутренние тесты по некоторым наиболее рискованным направлениям или поставить задачу разработчикам и разработчикам в тестировании, чтобы они добавили регрессионные тесты. В его арсенале есть и другие инструменты: исследовательское тестирование, привлечение внутренних и бета-пользователей и силы внешнего сообщества.

В ответственности тестировщика знать все подверженные рискам области. Он должен стараться снизить риски любыми способами, которые ему подвластны. Вот несколько рекомендаций, которые мы считаем полезными в борьбе с рисками.

1. Для самых рискованных возможностей и пар «атрибут/компонент», отмеченных красным, напишите набор пользовательских историй, сценариев использования или руководство по тестированию. В Google ответственность за наиболее рискованные возможности лежит на тестировщике. Он может координировать свою работу с коллегами, использовать разные инструменты, но личная ответственность все равно на нем.

2. Внимательно изучите все то, что делалось по тестированию разработчиками и разработчиками в тестировании до вас. Как результаты повлияли на риски, выявленные с помощью GTA? Хорошо ли это тестирование было организовано с точки зрения управления рисками? Стоит ли добавить новые тесты? Тестировщику может понадобиться дописать эти тесты самому или обратиться к разработчикам. В конечном счете важно, чтобы тесты были написаны, а не кто именно их напишет.

3. Проанализируйте баги, обнаруженные у каждой пары атрибут/компонент высокого риска, и убедитесь в том, что соответствующие регрессионные тесты написаны для каждого из них. Баги имеют свойство возвращаться при изменении кода.

4. Будьте внимательнее к областям высокого риска – поинтересуйтесь механизмами восстановления и отката. Учтите возможное негативное влияние на пользователя, когда он столкнется с наихудшим сценарием. Обсудите такие ситуации с другими инженерами, проверьте реалистичность этих сценариев. К тестировщику, который часто кричит: «Волк!», вскоре перестанут прислушиваться. Громкие предупреждения о вероятных опасностях допустимы только в отношении сценариев с высоким риском, которые к тому же признаны реалистичными и уже были покрыты тестами.

5. Вовлекайте в работу как можно больше людей, заинтересованных в успешности проекта. Внутренних пользователей следует тормошить на тему обратной связи, иначе они будут просто использовать систему, игнорируя те или иные ошибки. Просите их проводить конкретные эксперименты, задавайте им вопросы типа «А как это работает на вашей машине?» или «Как бы вы использовали такую фичу?». Сотрудники Google много участвуют в тестировании, и их нужно активно направлять именно тестировать, а не просто пользоваться продуктами.

6. Если ни один из механизмов не работает, а подверженный риску компонент так и недотестирован, да еще и постоянно падает, постарайтесь добиться удаления элемента. Поздравляем! Вам выпал шанс объяснить руководству концепцию анализа рисков и подчеркнуть важность тестировщиков на проекте.