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

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

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

План тестирования

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

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

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

Тестирование и кодинг

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

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

Непрерывная интеграция

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

Обработка дефектов

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

Множество типов тестирования

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

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

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

Наглядность

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

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

Источник: http://www.agileconnection.com/print/art[...]e-your-agile-development-traceable-tests

Автор: Лайза Криспин

Лайза Криспин в соавторстве с Дженет Грегори написала «Еще больше Agile-тестирования: исследуем всей командой» (More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley 2014)), «Agile-тестирование: практическое руководство для тестеров и Agile-команд» (Agile Testing: A Practical Guide for Testers and Agile Teams (Addison-Wesley, 2009)), она соавтор книги «Введение в экстремальное тестирование» (Tip House of Extreme Testing (Addison-Wesley, 2002)) и внесла свой вклад в «Опыт автоматизированного тестирования» (Experiences of Test Automation) Дороти Грэм и Марка Фьюстера (Addison-Wesley, 2011) и «Прекрасное тестирование» (Beautiful Testing (O’Reilly, 2009)). Лайза была отмечена за свои заслуги, будучи выбранной «Наиболее влиятельным профессионалом Agile-тестирования» в «Agile Testing Days» в 2012. Лайза работает тестировщиком в прекрасной Agile-команде. Она делится своим опытом, рассказывая в статьях, обучая и участвуя в коммьюнити Agile-тестирования по всему миру.

Перевод: Александра Родсет

Еще интересные статьи на эту тему:

• Что за тестировщик без команды по контролю качества?
• Две стороны тестирования: проверка и исследование
• Повышение отдачи от тестировщиков на ранних этапах
• Тестирование: ручное или автоматизированное
• Переход к гибкому (Agile) тестированию