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

Глава 8. Использование моделей для планирования

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

КВАДРАТЫ AGILE-ТЕСТИРОВАНИЯ

Квадраты Agile-тестирования построены на матрице, созданной в 2003 году Брайаном Мариком для описания типов тестирований в проектах экстремального программирования (Marick, 2003). Занимаясь планированием на разных уровнях точности, мы можем сказать, что эти квадраты весьма эффективны. Однако некоторые неверно трактуют их назначение. Например, кто-то рассматривает квадраты как последовательные этапы, а не систему. Другие не согласны с распределением действий по квадратам, поэтому не используют их вообще. Мы бы хотели прояснить ситуацию.

Рисунок показывает, как мы обычно объясняем эту модель. Как вы можете заметить, мы несколько изменили терминологию. Теперь, к примеру, вместо «поддержка разработки» мы говорим «управляемая разработка». Надеемся, это понятно.

Квадраты Agile-тестирования

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

• К1: взгляд со стороны технологий.

• К2: взгляд со стороны бизнеса.

• К3: бизнес-направление, нацеленное на обнаружение (оценку) ошибок.

• К4: технологическое направление, нацеленное на обнаружение (оценку) ошибок.

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

Большинство команд Agile начали бы с тестов К2, потому что именно они позволяют получить примеры, которые переходят в спецификации и помогают программировать. В своей статье 2003 года о матрице Брайан Марик окрестил тесты К2 и К1 «контролируемыми примерами». Изначально он называл их «направленными», «тренируемыми», а за слово «контролируемые» нужно благодарить Уорда Каннингема. Команда создает пример того, что должен отражать код, проверяет, не выполняется ли уже эта функция, пишет код, а затем проверяет, верен ли пример (Marick, 2003). Мы включили прототипы и симуляцию в К2, потому что это мелкие эксперименты, помогающие лучше понять идею или суть.

Иногда разумнее начать проверку нового функционала, используя тесты из разных квадратов. Лайза работала над проектом, где ее команда применяла тестирование производительности для определения расхождения структуры, поскольку это было наиболее важным атрибутом качества для функционала. Подобные тесты входят в К4. Если требования вашего клиента не точны, может потребоваться даже проработка истории, и начинать нужно с исследовательского тестирования (К3). Постарайтесь понять, где риски наиболее велики и где тестирование будет максимально эффективным.

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

Майкл Гюттерман добавляет пункт «клиентоориентированное, неограниченное, совместное» тестирование в центр квадратов. В качестве примера неограниченного тестирования он использует разработку через поведение. Эти тесты написаны по единому шаблону given_when_then, доступному для клиентов и разработчиков, что делает возможным диалог между двумя сторонами. Такой формат можно использовать для К1 и К2. В статье Agile Record (Hüttermann, 2011b) или в книге «Управление жизненным циклом Agile» (Agile ALM, Hüttermann, 2011a) вы найдете больше идей использования квадратов.

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

Во время обсуждений вы можете обнаружить необходимые тесты, которые не учли ранее, или понять, что вам не хватает определенных навыков или ресурсов для проведения тестирования в полном объеме. Например, в команде, с которой как-то работала Лайза, увидели, что все были так сосредоточены на тестах К2, что совершенно забыли о производительности и безопасности. Члены команды добавили пользовательскую историю, чтобы узнать, какие еще инструменты и техники понадобятся, а потом рассчитали время, необходимое для тестов К4.

ПЛАНИРОВАНИЕ ТЕСТОВ КВАДРАТА 1

В начале 1990-х годов Лайза работала с командой водопадного типа, где программистам нужно было написать план модульного теста. Это не было необходимо, но модульное тестирование на ранней стадии разработки и полная его автоматизация позволили бы избежать звонков в службу поддержки по поводу критических ошибок. Agile-команды тесты К1 отдельно не планируют. В TDD тестирование – неотъемлемая часть программирования. Программисты могут обсуждать некоторые тесты, но детали возникают непосредственно в процессе написания кода. Такие модульные тесты направляют разработки, помогают всей команде, поскольку их проводят на ранней стадии, а также в процессе непрерывной интеграции во время каждой проверки кода.

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

ПЛАНИРОВАНИЕ ТЕСТОВ КВАДРАТА 2

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

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

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

ПЛАНИРОВАНИЕ ТЕСТОВ КВАДРАТА 3

Тестирование всегда было центральным элементом Agile-разработок, и в Agile-командах раньше других стали использовать клиентоориентированные тесты К2. По мере развития команды перешли и на тесты К3, особенно уделяя внимание исследовательскому тестированию. Все больше компаний нанимают экспертов по исследовательскому тестированию, а тестировщики расширяют свои навыки в данной области.

Планирование тестов К3 может быть трудным. Вероятно, понадобится определить концепцию тестирования до перехода к конечному коду. Элизабет Хендриксон (Hendrickson, 2013) объясняет, как концепция позволяет понять, что именно нужно изучить, какие ресурсы привлечь, что мы надеемся обнаружить. Для повышения эффективности некоторых исследовательских тестов может потребоваться завершение множества мелких пользовательских историй или ожидание завершения проработки определенных характеристик. Вам также может потребоваться рассчитать время на создание пользователей для проведения тестирования, даже если они уже существуют в схеме историй или другом инструменте планирования свойств. Не всегда бывает просто определить концепцию исследовательского тестирования, но это отличный способ поделиться идеями с командой, отследить, какие тесты уже завершены. (Приведем примеры таких концепций в главе 12, где обсудим различные техники.)

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

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

ПЛАНИРОВАНИЕ ТЕСТОВ КВАДРАТА 4

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

Некоторые команды указывают на качественные свойства приемочных критериев для каждой истории. Мы предпочитаем использовать слово «требования». В книге «Открытия для разработки» (Discover to Deliver, Gottesdiener and Gorman, 2012) Эллен Готтесдинер и Мэри Гормен рекомендуют использовать язык программирования Planguage, описывающий эти требования весьма четко. Предложили этот язык Том и Кай Джилб (Gilb, 2013). (Подробнее об этом можно почитать в книгах, указанных в списке литературы к третьей части.)

Если вы хотите, чтобы «все веб-страницы вашего продукта отвечали на запрос в течение трех секунд», не нужно повторять этот критерий для каждой истории отдельно. Найдите способ напоминать команде, что это нужно учитывать и обязательно тестировать. Лиз Кеог сообщает о методе написания тестов, который бы раскрывал возможности мониторинга таких характеристик системы (Keogh, 2014). Организации, как правило, знают, какую операционную систему или браузер они используют на стадии выпуска, так что добавьте их в качестве требований, включите в оценку тестирований. Это обычно первые кандидаты на тестирование на уровне функционала, но если имеет смысл протестировать их и на уровне истории, сделайте это. Помните: прежде всего тестирование! В главе 13 поговорим о некоторых других способах, вызывающих трудности.

КРИТИКА КВАДРАТОВ

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

Вызов Гойко квадратам

Гойко Аджич, автор и консультант по стратегии развития ПО, подвергает критике квадраты в век разработки софта.

В 2008 году квадраты были невероятно мощным интеллектуальным инструментом в разработке софта. Квадраты помогли мне скоординировать многие полезные обсуждения по поводу целостной картины, которая часто упускается программистами. Также они помогли многим тестировщикам понять, на чем cфокусироваться. Теперь же, в 2014 году, мир изменился. В сфере непрерывной разработки, DevOps, анализа больших данных, гибкого запуска и исследовательского тестирования специалистов прибавилось. Поэтому модель квадратов нуждается в серьезном обновлении.

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

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

Еще один аспект тестирования, не в полной мере охваченный квадратами, описанными в первой книге, – увеличение количества специалистов, важность исследовательского тестирования. В старой модели оно представлено как что-то, рассматриваемое с точки зрения бизнеса для оценки продукта (часто путается со стадией постразработки). Во многих случаях, отлично описанных в книге Элизабет Хендриксон «Исследуй это!» (Hendrickson, 2013) и в книге «Как тестируют в Google»[7]7
  Уиттакер Дж., Арбон Дж., Каролло Д. Как тестируют в Google. СПб.: Питер, 2014.


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

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

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

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

Вопросы безопасности можно легко разделить на функциональные тесты совместимости (шифрование, защита данных, аутентификация и т. д.; изначально все проверяемые на ожидаемый результат) и проверки вмешательства / несанкционированного доступа (непредсказуемый результат). Это поможет разработчикам и инвесторам прийти к диалогу об описании функций безопасности.

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

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

Тесты типа Build-Measure-Learn прекрасно впишутся в эту модель, подтверждая, что требуют определенных предположений и гипотез. И это очевидно отличается от простого запуска процесса и ожидания результатов пользовательской аналитики.

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

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

Элизабет Хендриксон также представила свою версию квадратов во время лекции The Thinking Tester (Hendrickson, 2012). Она похожа на вариант Гойко Аджича, но выглядит иначе. Элизабет переименовала вертикальные колонки в «подтверждение» и «исследование», в то время как горизонтальные ряды представляют бизнес и технологии.

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

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

ЧТО ЕЩЕ ВЛИЯЕТ НА ПЛАНИРОВАНИЕ

Существует множество моделей и идей, способных помочь в планировании, и не стоит пренебрегать ими. Как сказали Тим Оттингер и Джефф Лангр (Ottinger and Langr, 2009b), нелишним будет напоминать себе о том, что называется нефункциональными требованиями. Модель FURPS[8]8
  Классификация требований к системе (англ. Functionality, функциональность; Usability, удобство использования Reliability, надежность; Performance, производительность; Supportability, поддерживаемость). Знак + обозначает возможные ограничения. Прим. ред.


[Закрыть] была создана в компании Hewlett-Packard и впервые представлена Грэди и Касвелом («Википедия», 2014f). Она не так широко используется в сфере ПО. Знак «+» был добавлен к названию позднее, после различных кампаний, для расширения значения аббревиатуры.

Джеймс Уиттакер разработал методологию, которую назвал матрицей возможностей, свойств и компонентов (Attribute Component Capability, ACC). Эта модель помогает выявить, что нужно тестировать, основываясь на рисках, и состоит из трех разных частей, определяющих качество системы при тестировании: свойства, компоненты, возможности. Уиттакер определяет их следующим образом:

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

• Компоненты (существительные системы) – составные части, которые вместе образуют заданную систему. Некоторые примеры компонентов: встроенное ПО, печать, файловая система для проекта ОС, база данных, корзина, описание продукта для онлайн-магазина.

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

Создание матрицы высокого уровня с этой моделью заметно облегчит визуализацию вашей системы. На рисунке далее показано, как может выглядеть такая матрица. Гойко Аджич согласен, что прозрачность системных характеристик и визуализация – хорошая идея (Adzic, 2010a), однако предупреждает: хоть мы и можем перенимать опыт других областей, стоит с осторожностью использовать его в качестве метафоры в разработке ПО.

Используйте эвристический подход (Элизабет Хендриксон «Эвристическая шпаргалка», Test Heuristic Cheat Sheet; Hendrickson, 2011) или такие зарекомендовавшие себя техники, как диаграммы или таблицы новых идей. Совмещайте эти методы с квадратами, чтобы извлечь из обсуждений условий или пользовательских пожеланий конкретные примеры. Все эти инструменты помогут повысить качество продукта.

Пример ACC

ПЛАНИРОВАНИЕ ДЛЯ АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ

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

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

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

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

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

РЕЗЮМЕ

Модели помогают в планировании. Вот что мы узнали из этой главы.

• Квадраты Agile-тестирования – это модель, которая позволяет рассматривать тестирование в контексте Agile.

– Квадраты подчеркивают ответственность всей команды за тестирование.

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

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

– Правая сторона относится к обнаружению ошибок в продукте, а также пониманию того, каких возможностей не хватает.

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

• Мы также представили альтернативную версию квадратов Элизабет Хендриксон, которая подчеркивает, что проверочные тесты важнее исследовательских.

• В нашем арсенале уже множество инструментов Agile-тестирования, и мы можем сочетать их с моделью квадратов для максимальной эффективности.

• Модели FURPS и ACC помогут с качественными характеристиками, а также в тестированиях, основанных на рисках.

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