Текст книги "Agile-тестирование. Обучающий курс для всей команды"

Глава 9. Тем ли мы заняты?

Большинство думают, что времени на тестирование всегда не хватает. Дело в том, что тестирование ПО – лишь часть общей задачи. К сожалению, мы часто тратим время на создание софта, который не соответствует приоритетам клиента, или программного обеспечения, которое никогда не будет использоваться, или разрабатываем продукт, затраты на который превышают все сметы.

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

СПРОСИТЕ «ЗАЧЕМ?»

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

Спрашивая «Зачем?», мы с большей вероятностью поймем детали, о которых клиент зачастую не знает. Если бы мы просто делали то, что просит заказчик, это могло бы только ухудшить дело. Приведем пример.

История Лайзы

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

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

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

Как только нам стали понятны цели, которым должна была соответствовать история, мы переписали ее. «Как представителю третьей стороны, у которой имеются свои правила выдачи кредитов, мне необходима возможность запросить от лица участника пенсионной программы 401(k)[9]9
  401(k) – наиболее популярная пенсионная накопительная программа частной пенсионной системы США. Названа по номеру статьи Налогового кодекса США «401(k)». Прим. перев.


[Закрыть] кредит, не попадающий под стандартные условия, чтобы человек мог его получить и выплатить».

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

Ключевые компоненты бизнес-ценности софта – это функциональность, окупаемость инвестиций. Постоянно думайте, тем ли вы заняты, задавайте правильные вопросы, которые помогут в поддержании высоких стандартов качества. Для оптимизации процессов используйте свое право принимать решения. Если ваши разработчики достаточно опытны и способны быстро внедрять новые элементы, можете позволить себе потратить чуть больше времени на выяснение потребностей клиента (Matts and Maassen, 2007).

ИНСТРУМЕНТЫ ДЛЯ ВЗАИМОДЕЙСТВИЯ С КЛИЕНТАМИ

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

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

СХЕМЫ ВЛИЯНИЯ

В своей книге о схемах влияния (Adzic, 2012) Гойко Аджич объясняет принципы сотрудничества команды разработчиков и заинтересованных сторон для быстрого определения наиболее успешных путей разработки. Отвечая на вопросы «Зачем?», «Кто?», «Как?» и «Что?», команды выстраивают план, помогающий быстро определить, что именно гарантирует желаемый результат при неизбежных изменениях.

Схемы влияния сформировались из других инструментов, используемых в мозговых штурмах и планировании, таких как построение диаграмм и схемы историй. Этот простой структурированный метод помогает всей команде концентрироваться на том, что необходимо спроектировать, а также определять элементы, которые нужно разработать в первую очередь. Таким образом, от вопроса «Что делать?» мы переходим к более конструктивному: «Зачем мы делаем это, каковы наши цели, кто может нам помочь, а кто, наоборот, мешает?». Эти схемы также помогают понять, не лежит ли решение проблемы за рамками софта. К примеру, может оказаться, что требуется более основательная подготовка пользователей системы.

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

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

Пусть клиенты по завершении покупки создают аккаунт, чтобы мы могли сохранять информацию о сумме, способе оплаты и доставке.

Нам нужно разобраться, что же для этого необходимо. Чтобы создать схему влияния, мы собираем вместе бизнес-экспертов и разработчиков. Первым делом спрашиваем экспертов, зачем им нужна эта опция, и узнаем, что они хотят удержать клиентов. Вместе мы работаем над постановкой конкретных, измеримых, действенных, реалистичных и ограниченных по времени целей. В данном случае – за три месяца достичь доли удержания клиентов в 90 %.

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

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

Когда мы определились с влиянием, нужно понять, что требуется от нас и от других игроков, то есть обозначить средства для достижения цели. В нашем случае это могут быть купоны на повторную покупку, разработанные отделом маркетинга. Отличным средством может служить безопасный простой интерфейс, позволяющий сохранять информацию о способах оплаты для упрощения последующих покупок. На примере ниже – impact map для этой опции.

Типовая схема влияния

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

И тут самое время подумать о рисках тестирования. Можно ли уберечь клиента от переплат в дальнейшем? У кого запрашивать данные тестов? Что еще нужно учитывать? Мнение экспертов в конкретной области поможет найти пути достижения целей без разработки новых свойств ПО. Схемы влияния – один из способов творчески подойти к тестированию, понять, на каких элементах необходимо сосредоточиться. Говоря о тестировании, мы стараемся найти способы сотрудничества внутри команды и спланировать процессы так, чтобы их было легко обновлять.

Схемы влияния сами по себе могут быть планом тестирования, а, как мы говорили в главе 7, графические схемы – отличные инструменты планирования. Форма не так важна. Значение имеет то, что мы прогнозируем необходимые тесты и закладываем на них достаточно времени и других ресурсов. Альтернативные варианты, которые можно увидеть посредством схем влияния, помогают удостовериться, что все возможные риски учтены.

СХЕМЫ ИСТОРИЙ

Схемы историй – это практический способ смоделировать свойства высокого уровня и разбить их на двухмерные пользовательские истории. Джефф Паттон впервые написал об этом в январе 2005 года в статье «Как это разделить» (How You Slice It, Patton, 2005) в журнале Better Software. Процесс создания и изучения схем историй помогает определить, с чего начать разработку новых свойств, как визуализировать продукт с минимальным функционалом (Minimum Viable Product, MVP). Схема историй также позволяет команде заниматься нужными областями разработки, отслеживать прогресс и корректировать курс. Начните изучение со схемы влияния, а когда определитесь со свойствами (опциями), переходите к более детальному анализу.

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

Как только схема будет готова, разделите ее на высокоуровневые пользовательские истории, спланируйте этапы, на которых они появляются, выпуск. Самые важные действия размещайте сверху. Они могут стать вашим продуктом с минимальным функционалом. Некоторые называют это «ходячим скелетом» (Freeman and Pryce, 2009) – наименьшее количество функций, которые можно разработать, чтобы повысить отдачу для клиента. Изучите схему историй вместе с представителями заказчика, посмотрите, стоит ли еще что-то учесть. Не углубляйтесь в детали на этом уровне, просто определите наиболее полезные элементы свойств.

Составление схем историй помогает клиентам и разработчикам определить мельчайшие выпуски, рассчитать их объемы, выстроить согласно приоритетам. Если хотите подробнее изучить эту тему, рекомендуем почитать книгу Джеффа Паттона «Схемы пользовательских историй» (User Story Mapping, Patton, 2004). Ссылки на полезные источники вы также найдете в списке литературы к четвертой части.

Схемы историй и тестирование

Стив Рогальски, специалист Agile из Виннипега (Канада), рассказывает, почему, по его мнению, тестировщикам стоит обратить внимание на схемы историй.

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

Тестирование того, что нужно создать

Схемы пользовательских историй – способ представления информации. Они помогают визуализировать возможную систему, оценить ее жизнеспособность прежде, чем вкладывать в ее разработку время и деньги. Опыт, о котором рассказали на недавней конференции Agile в Виннипеге, отлично иллюстрирует это. Некая компания использовала схемы историй для тестирования идей перед тем, как создавать какой-либо софт. У команды были мысли по поводу проекта, который отлично подошел бы заказчику. После создания схемы историй ее представили клиенту. Вскоре стало ясно, что с идеей вышла промашка. Однако тестировщики смогли обсудить некоторые моменты и скорректировать схему, чтобы она наконец отражала необходимые задачи. Получается, схема была инструментом, благодаря которому удалось протестировать идею (а затем скорректировать ее) и продолжить работу над проектом.

Тестирование областей приложения

Для тестирования Agile-проектов важно определить тонкие грани и маленькие участки. Схемы историй помогают различить эти зоны, но, что, возможно, они помогают понять, как разделенные истории формируют кусочки целого приложения. Во время работы над Agile-проектами от тестировщиков требуется перестроить мышление и проверять маленькие отрезки. Несмотря на значительные изменения, важно убедиться, что первые несколько фрагментов сочетаются, позволяют провести комплексное тестирование как можно раньше. Схема историй помогает определить и выделить первый участок приложения. Он может основываться на пользовательском сценарии или на череде историй, которые представляют собой еще меньшие истории, с помощью которых можно читать карту слева направо.

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

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

Схемы сценариев – инструмент тестирования

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

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

СЕМЬ КРИТЕРИЕВ ПРОДУКТА

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

Один из аналитических инструментов мы считаем особенно эффективным. Семь критериев продукта (Gottesdiener and Gorman, 2012) помогают выявить, что конкретно необходимо на всех уровнях планирования. Назовем эти критерии.

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

• Интерфейс. Что необходимо для взаимодействия пользователя с продуктом? Как продукт будет посылать или принимать данные или сообщения? Схемы отношений, контекстные диаграммы, прототипы и макеты – все это способы визуализации.

• Действие. Каковы возможности продукта? Как и в какой последовательности совершаются действия? Как отвечает продукт? Как действия влияют на данные? Диаграммы процессов, схемы историй и карты потока создания ценностей отражают действия и их последовательность.

Представьте сценарии, где определенные шаги пропущены или выстроены неправильно.

• Данные. Какие данные получает продукт, откуда и каким образом? Сортируются ли они? Как хранятся? Какая информация нужна пользователям, в каком контексте и как долго она остается актуальной? Модели данных используются для визуализации потоков информации. Статичные диаграммы показывают переход данных из одного состояния в другое.

• Контроль. Какие условия необходимо задать для продукта? Правила, ограничения, деловые стандарты. Каковы риски в случае их несоблюдения? Таблицы решений помогают в организации правил.

• Среда. Подумайте о физических качествах продукта. Где его будут использовать? Поразмышляйте об установке, конфигурации, лицензии и возможностях. Как насчет среды разработки? Какое оборудование, ПО и какие стандарты необходимы? У компании может быть не одна среда, так что определите, какая именно подходит для конкретного продукта.

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

Все семь критериев важны в планировании выпуска, свойств и этапов разработки. Часто ли вы осознаете, что упустили какую-то деталь и теперь вам необходимы дополнительные истории или ресурсы. Например, анализируя данные, понимаете, что ваше приложение будет получать их от третьей стороны. Известны ли вам условия? Участвует ли эта третья сторона в тестировании? Когда должна начаться проверка? Что делать с неверными данными? Получит ли отправитель соответствующее сообщение об ошибке? Безопасно ли для третьей стороны отправлять данные? Необходимо ли подтверждение их получения? Предоставила ли третья сторона образец данных для тестирования? Применяются ли ограничения? Нужно ли раскрывать пользователям какую-либо информацию? Где будут сохраняться данные? Повлияет ли объем данных на работу системы? Это те вопросы, которые следует задавать как можно раньше. Включайте мозги тестировщиков в игру!

Конструктивный диалог с использованием семи критериев продукта

Мэри Гормен и Эллен Готтесдинер, авторы книги «Открытия для разработки» (Discover to Deliver, Gottesdiener and Gorman, 2012) рассказывают о клиенте, который переживал глобальный переход на Agile, и о роли конструктивного диалога.

Организации нужно было быстро поднять уровень методов тестирования и анализа. Руководители подошли к вопросу так же, как подходили к прояснению требований, коммуникации и тестированию Agile-условий. Задача выглядела сложной, поскольку более сорока тестировщиков и аналитиков фактически не разбирались в таких областях, как качество и бизнес-аналитика.

Руководители отделов тестирования, ведущие бизнес-аналитики не сомневались, что обладают необходимыми качествами. Несмотря на то что они прошли основные тренинги Agile, научились использовать Kanban для визуализации работы коллектива, писать истории и применять грубую форму метода given_when_then для уточнения требований, члены команды все еще действовали по старинке. Они не проговаривали требования ни во время рабочего цикла (сейчас), ни на этапе выпуска (подготовка). Они обнаруживали дефекты поздно, чего можно было бы избежать при грамотном анализе. Тестировщики были буквально деморализованы, ведь изо всех сил старались завершить истории во время установленного цикла.

Руководство нуждалось в лидерах, которые бы своим примером показали разработчикам и представителям бизнеса, как эффективно сотрудничать в рамках Agile.

Мэри Гормен курировала всех тестировщиков и аналитиков в процессе обучения и применения модели «Открытия для разработки». Переломным моментом стало собрание, во время которого все сотрудники были вовлечены в процесс определения наиболее значимых свойств системы и историй для следующего выпуска и рабочего цикла. Сообща команда продумала варианты для всех семи критериев продукта (пользователь, интерфейс, действие, данные, контроль, среда, качественные свойства).

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

• Исследуй варианты.

• Оценивай варианты в рамках семи критериев продукта и выявляй наиболее успешные решения.

• Подтверждай решение, формулируя приемочные критерии. Помимо пересекающихся обязанностей разных отделов, существует и работа, в которой задействована вся команда.

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

Руководитель продукта: «Чувствую, что за последние полтора дня наша команда продвинулась дальше, чем за всю прошлую неделю (цикл 1). В результате сотрудники больше не ощущают себя потерянными из-за недопонимания. Наоборот, они воодушевлены очевидным прогрессом, что создает позитивную рабочую атмосферу».

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

• Мы не стремимся все сделать безупречно.

• Мы больше не сконцентрированы на том, чтобы заполнить карты историй. Теперь истории стали сопутствующим продуктом обсуждений.

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

• Метод семи критериев здорово помогает в обсуждениях».

Мэри и Эллен недавно связались с руководителями бизнес-аналитиков и тестировщиков. Вот что они рассказали.

• Команды используют семь критериев продукта во время обсуждений. Они повесили картинки с изображением семи критериев на свои Kanban-доски. Это продвигает исследования и анализ. В результате мы имеем более продуктивные дискуссии и высококачественные требования.

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

• Они используют так называемые «прощупывающие» вопросы для каждого из семи критериев. Это нечто среднее между конкретными вопросами конструктивного диалога, о которых говорится в книге «Открытия для разработки», и анализом тестовой эвристики.

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

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

Чтобы помочь своей команде определить необходимые для разработки свойства, применяйте практики экспертов бизнес-аналитиков Agile, такие как семь критериев продукта и конструктивный диалог. Не забывайте задавать вопросы, стремитесь к пониманию того, над чем работает коллектив.

ДОПОЛНИТЕЛЬНЫЕ ИНСТРУМЕНТЫ И ТЕХНИКИ ДЛЯ ИССЛЕДОВАНИЙ НА РАННЕЙ СТАДИИ

Эрик Рис (Ries, 2010) рассказывает, какой образ мышления должен быть у компаний, использующих инновации. Его идеи по поводу гибкого запуска могут быть полезны во многих ситуациях. Метод Build-Measure-Learn (BML) основан на разделении процесса на маленькие участки, их оценке и изучении с помощью ранней обратной связи и актуальных идей. Похоже на тестирование, не так ли?

Тестировщики помогают здесь тем, что задают вопросы, определяют, что именно можно оценить. Иногда достаточно просто просмотреть модели и отчеты, подготовленные программистами или дизайнерами пользовательского интерфейса.

С помощью A/B-тестирования можно проверить предположения. Суть в том, чтобы создать два отдельных этапа реализации для активного использования клиентами, а потом оценить результаты. Пользователи участвуют на других этапах. Компания отслеживает статистику кликов покупателей, действия, ведущие и не ведущие к покупке. Это позволяет определить, что больше нравится покупателям, основываясь на реальных данных. Один из наших соавторов поделился опытом применения A/B-тестирования в главе 13.

Как мы уже говорили в главе 7, визуализация разных точек зрения с помощью схем выявляет скрытые предположения.

ПРАВИЛЬНЫЕ ИНВЕСТИЦИИ

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

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

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

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

РЕЗЮМЕ

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

• Начинайте с вопросов «Зачем?», чтобы выяснить задачи софта, который собираетесь разрабатывать.

• Пробуйте различные инструменты, которые помогают клиентам сформулировать свои мысли. Среди них:

– схемы влияния;

– схемы историй;

– семь критериев продукта;

– методы гибкого запуска.

• Экспериментируйте с разными техниками для более плодотворного сотрудничества клиентов и разработчиков.

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