Уиттакер . - Как тестируют в Google
— Небольшим: сбой, который может вызвать раздражение у пользователя. Если случается — механизмы повтора и восстановления легкодоступны.
Пример: нажмем на кнопку «Обновить». Если она не обновляет страницу, то можно заново ввести URL-адрес или открыть новую вкладку и попробовать ввести его там, а можно просто перезапустить браузер. Самые худшее в этой ситуации — раздражение пользователя.
— Существенным: сбой заблокирует выполнение пользовательских сценариев.
Пример: расширения Chrome. Если пользователь установил расширения в свой браузер, а в новой версии Chrome возник сбой при загрузке этих расширений, это провал.
— Максимальным: сбой нанесет удар по репутации продукта и заставит пользователей отказаться от работы с ним.
Пример: механизм автообновления Chrome. Если эта возможность отвалится, то браузер лишится важных обновлений безопасности или вовсе прекратит работать.
Иногда сбои приводят к разным последствиям у пользователя и компании. Допустим, перестал работать рекламный баннер. Проблема ли это для пользователя? Нет, он даже может не заметить. Проблема ли для Google? Да, конечно. Поэтому, анализируя риски, указывайте, кто пострадает.
Данные, которые присвоил рискам тестировщик, можно наложить на готовую таблицу «атрибут/компонент» для Google Sites. Таким образом мы получим тепловую карту рисков (рис. 3.9).
Рис. 3.9. Тепловая карта рисков для таблицы «атрибут/компонент» (ранняя версия Google+)
Ячейки окрашиваются в красные, желтые или зеленые цвета в зависимости от уровня риска компонентов. Очень просто вычислить примерный уровень риска для каждого значения — мы просто усредняем риски его возможностей. Эта карта была сделана в GTA, но с той же задачей справится и обыкновенная электронная таблица.
Такая диаграмма показывает возможности продукта, которые можно тестировать, вместе с присвоенными значениями рисков их сбоев. Трудно проставить эти значения объективно, тем более что у тестировщиков весьма специфическая точка зрения на продукт. Чтобы подстраховаться, мы опрашиваем и других заинтересованных в проекте лиц. Вот список тех людей, которые могут помочь с определением рисков, и несколько советов, как работать с их мнениями.
— Разработчики. Большинство разработчиков присвоят максимальное значение риска функции, которую писали они. Естественно, они хотят, чтобы их код был протестирован! Каждый кулик хвалит свое болото, но наш опыт подсказывает, что «кулик» часто переоценивает те функции, за которые он отвечает.
— Руководитель проекта. Удивительно, но руководители проектов тоже люди, и их оценка тоже может быть субъективной. Для них наиболее важными считаются те функции, которые позволят продукту выделиться на рынке и стать хитом.
— Специалисты по продажам. Эти парни зарабатывают на привлечении клиентов, поэтому их оценка возможностей смещена к тем, которые помогают продукту хорошо смотреться в демоверсии.
— Директора и вице-президенты. Топ-менеджеров обычно интересуют те возможности продукта, которые качественно отличают его от главных конкурентов.
Итак, у всех мнений есть погрешность. Чтобы бороться с этим, мы опрашиваем всех заинтересованных в проекте людей по отдельности и просим оценить риски по описанным выше двум факторам. Их не так легко уговорить на эту работу, но мы, кажется, нашли успешную стратегию. Вместо того чтобы вдаваться в объяснения процесса и упрашивать участников нам помочь, мы просто делаем все сами и показываем им уже готовую тепловую карту. Как только они видят наше мнение, они мгновенно выплескивают свое. Разработчики активно принимают участие, если понимают, что мы используем карту для расстановки приоритетов в тестировании. Так же ведут себя и руководители проектов, и менеджеры по продажам. Все они заинтересованы в его качестве.
Есть в этом подходе определенная сила. Когда мы определяем риски самостоятельно, мы несомненно приходим к варианту, с которым другие участники проекта не будут согласны. Так и есть, подготавливая для них наш вариант анализа рисков, мы даем им почву для споров. В этом идея. Мы не спрашиваем их о каких-то абстрактных понятиях, мы даем им конкретные выводы, которые можно оспорить. Люди не всегда могут сказать, каким должен быть правильный ответ, но легко скажут, каким он быть не должен. Такой хитрый подход приносит нам много правдивых данных для вычисления рисков.
Когда риски будут согласованы, можно приступать к их последовательному снижению.
Снижение рисков
Редко удается полностью устранить риски. Мы водим машину, хоть это и опасно, но ведь нужно добираться до работы? Вообще возможность несчастного случая не означает, что он обязательно произойдет, да и, скорее всего, ничего страшного не случится. Почему? Потому что своими действиями мы снижаем возможный риск. Например, не садимся за руль в нетрезвом состоянии и не водим в условиях недостаточной видимости. Таким образом мы снижаем риски.
В разработке программного продукта самое простое — избегать рискованных областей: чем меньше кода, тем меньше риск. Но кроме использования «топора и секиры», мы можем сделать еще много чего, чтобы снизить риски:
— Мы можем проработать пользовательские истории вокруг наиболее рискованных возможностей, определить самые безопасные пути и показать их разработчикам, чтобы те ввели в приложение больше ограничений.
— Мы можем написать регрессионные тест-кейсы, чтобы убедиться, что мы отловим повторные сбои.
— Мы можем написать и запустить тесты, подтверждающие необходимость добавить механизм восстановления и отката.
— Мы можем добавить средства контроля и сторожевой код для оперативного обнаружения сбоев.
— Мы можем добавить инструменты, которые будут отслеживать изменения в поведении продукта в его разных версиях. Мы получим сигнал, если возникнет регрессионный баг.
Конкретное решение зависит от особенностей приложения, от ожиданий пользователя в отношении его безопасности и надежности. Как тестировщики, мы, конечно, можем быть вовлечены и в процесс снижения рисков, но мы безусловно вовлечены в процесс их выявления. Мы начинаем с приоритизации возможностей, отмеченных в таблице красным. Мы хотим тестировать в порядке уменьшения рисков. Это важно: если не можешь протестировать все — протестируй сначала самое важное. А самое важное — это то, что больше всего подвержено самым серьезным рискам.
В некоторых проектах именно тестировщиков спрашивают о готовности продукта к выпуску. Хорошему тестировщику достаточно бросить взгляд на тепловую карту, чтобы определить, стоит еще подержать продукт в духовке или пора подавать его на стол. Если речь о запуске экспериментального Google Labs, то наличие красных зон риска не так существенно, если они не относятся к безопасности, конечно. А если это выпуск новой версии Gmail, тогда даже желтые зоны представляют серьезную опасность. Такая простая цветовая градация понятна всем, даже топ-менеджерам.
Опасения по поводу рисков со временем спадают, а большой объем успешно проведенного тестирования — это хороший признак того, что риски на приемлемом уровне. Здесь мы выигрываем от того, что связываем тест-кейсы с отдельными возможностями продукта, а затем и с атрибутами и компонентами в таблице рисков. Для этого дела идеально подходит «ACC-анализ», и вот почему мы создали этот инструмент именно таким.
Тест-план за десять минут по рецепту Джеймса Уиттакера
Любая задача в разработке ПО, которую можно решить за десять минут, считается простой или не заслуживающей внимания. Предположим, что мы верим в это, — тогда что мы можем сказать о планирования тестирования? Конечно же, то, что оно занимает более десяти минут. Когда я работал директором по тестированию в Google, я руководил несколькими командами, которые создавали огромное количество тест-планов. Ответы на вопрос о том, сколько времени займет его составление, могли быть такими: «завтра», «к концу недели» и лишь пару раз — «к концу дня» (если задача озвучивалась рано утром). О’кей, примем к сведению, что составление тест-плана занимает некоторое количество часов, а то и дней.
Стоит ли такая работа усилий — это уже совсем другая история. Я вижу десятки тест-планов, которые пишут мои команды, и каждый раз это мертворожденные документы — они создаются, рецензируются, обновляются один или два раза (если повезет), а потом уверенно откладываются в долгий ящик, как только проект начинает идти не так, как это было предусмотрено. Возникает вопрос: если план не стоит того, чтобы его обновлять, стоило ли его создавать?
Иногда тест-план нежизнеспособен потому, что содержит слишком много или, наоборот, слишком мало подробностей. Или он способствовал началу работы, а вот процессу — уже нет. И снова вопрос знатокам: стоило ли создавать документ с ограниченной или постоянно уменьшающейся ценностью?
