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

Глава 7. Уровни точности планирования

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

РАЗНЫЕ ТОЧКИ ЗРЕНИЯ

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

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

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

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

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

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

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

• Задача. Работа, являющаяся частью истории, которая может быть завершена менее чем за день.

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

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

УРОВЕНЬ ВЫПУСКА ПРОДУКТА

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

На этом этапе также стоит подумать, какие дополнительные тесты потребуются на завершающей фазе, до того, как продукт будет запущен в продакшн. На этом этапе к обсуждению могут привлекаться операторы, специалисты службы поддержки, тренеры и маркетологи, особенно если нужно провести заключительное пользовательское приемочное тестирование (User Acceptance Testing, UAT) или протестировать совместимость с внешней системой. Об этом подробнее читайте в первой книге, а также смотрите источники из списка литературы к третьей части.

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

Цикл разработки продукта одной командой

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

Цикл разработки продукта несколькими командами

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

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

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

Если вам кажется полезным иметь записанный план выпуска до начала цикла разработки, советуем поддерживать его максимально простым и понятным. Данные не должны дублироваться в стратегии тестирований или методической документации (Crispin and Gregory, 2009). В этих документах содержатся сведения, общие для всех тестов. В текущем проекте останавливайтесь лишь на том, что выходит за рамки общего подхода. Принимайте во внимание аудиторию и ее интересы. Чем меньше будет воды, тем вероятнее, что нужная информация о потенциальных рисках будет адекватно воспринята.

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

УРОВЕНЬ ФУНКЦИОНАЛА

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

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

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

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

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

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

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

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

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

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

План тестирования свойств фитнес-приложения при добавлении калькулятора индекса массы тела (ИМТ)

Объемы тестов

• Калькулятор ИМТ был добавлен в приложение для индивидуального расчета процента жира в теле. Данные, вводимые пользователем, хранятся в облаке и передаются в калькулятор для того, чтобы вводить новые сведения и делать другие расчеты. Начальное тестирование будет проходить на устройствах iPhone, iPad и планшете Nexus.

Метод тестирования

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

Риски

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

Регрессия

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

Свойства для тестирования

• Калькулятор ИМТ (функциональное тестирование).

• Строка ИМТ (функциональное тестирование).

• Предварительный отчет о текущих результатах по калькулятору (комплексное тестирование).

• Калькулятор обмена веществ и подкожного жира (регрессионное тестирование).

• Тестирование на разных устройствах, основанное на удобстве пользовательского экрана.

Свойства не для тестирования

• Калькулятор соотношения окружности талии и бедер.

• Отслеживание веса и отчеты.

• Отслеживание плана питания.

• Настройки.

Проверка корректности данных

• Соответствие метрической системе, использующейся для роста и веса.

• Обозначения и ограничения (недостаточный вес, нормальный, избыточный, а также ожирение и возрастные особенности) для определения данных теста.

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

Общий подход

• Свойства, не обозначенные для тестирования, должны пройти «дымовой тест» (smoke test) до интеграционного и исследовательского тестирования.

УРОВЕНЬ ИСТОРИИ

Работая на уровне истории, мы начинаем углубляться в детали. Тут даже не важно, используете ли вы определенные временные этапы или потоковые методы. Для каждой истории необходимо высокоуровневое приемочное тестирование: пример ожидаемых характеристик, хотя бы один пример сбоев работы этих характеристик, который бы определял объемы истории. В главе 11 мы поговорим об этом. Точное планирование на уровне истории происходит на стадии готовности (иногда называемой предпланированием, уточнением списка требований).

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

УРОВЕНЬ ЗАДАЧ

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

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

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

ПЛАНИРОВАНИЕ РЕГРЕССИОННОГО ТЕСТИРОВАНИЯ

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

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

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

ВИЗУАЛИЗАЦИЯ ТЕСТИРОВАНИЯ

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

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

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

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

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

РЕЗЮМЕ

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

• На уровне выпуска продукта думайте о системном подходе, о том, какие именно тесты требуются на завершающем этапе, включая (но не исключая) UAT, тестирование производительности и нагрузочное тестирование.

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

• С точки зрения разработчиков подумайте над отношениями функционала и историй, рисками, ограничениями и тестовой средой на стадии выпуска продукта.

• На уровне функционала учитывайте, что оказывает влияние на конкретные свойства, приемочные тесты и необходимые тестирования, включая проверки качественных свойств, юзабилити и UAT-тестирование.

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

• На уровне задач планирование обычно происходит во время их постановки (например, TDD), когда сначала пишется тест, а потом код.

• Автоматизированное регрессионное тестирование не происходит случайно. Его необходимо планировать и расширять, делая частью ежедневного процесса.

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