Заметки консультанта

Шамрай Александр Владимирович

Archive for Август 2013

Как отследить продвижение изменений рабочего элемента между ветвями?

Posted by Шамрай Александр на Август 20, 2013

<< Перейти в раздел «Team Foundation Work Item Tracking FAQ»

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

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

В результате будет отображена визуализация истории перемещений изменений по рабочему элементу.

Реклама

Posted in Microsoft, Team Foundation Server FAQ, Visual Studio, Work Item Tracking FAQ | Отмечено: | Leave a Comment »

Правильные требования: Топ 10 ловушек

Posted by Шамрай Александр на Август 15, 2013

Перевод: Шамрай А.В.

Источник: Getting requirements right: avoiding the top 10 traps

Содержание

Не попадайтесь

Ловушка 1: расползание границ

Ловушка 2: спрашивать заказчиков, чего они хотят

Ловушка 3: неспособность адаптироваться к изменениям

Ловушка 4: неспособность эффективно общаться

Ловушка 5: нечастое общение

Ловушка 6: громоздкие документы и слишком много информации

Ловушка 7: скрытые артефакты проекта

Ловушка 8: неоднозначные требования

Ловушка 9: неспособность измерить и оценить процесс требований

Ловушка 10: изоляция ваших требований

Заключение

Не попадайтесь

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

К сожалению, ловушки требований являются общими и их влияние является значительным. В исследованиях State of the IT Union Survey изучали методы управления разработкой, которые команды применяют во избежание неприятностей или используют для решения проблемы после их обнаружения. Онлайн-опрос респондентов показывает, как часто команды разработчиков предвидят, что они могут попасть в ловушки. Они дополняют бюджеты и планы. Они изменяют первоначальную смету, чтобы соответствовать фактическим результатам. И они запрашивают дополнительные ресурсы. Рисунок 1 показывает, как команды и руководители групп будут бороться с этими ловушками…

Основные моменты

Слабое Управление требованиями приводит к несогласованным результатам проекта.

Рисунок 1. Команды разработчиков ожидают ловушки управления требованиями и преднамеренно избегают создание точных бюджетов и планов.

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

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

Основные моменты

Фиксирование бизнес-требований может контролировать расползание границ.

Ловушка 1: расползание границ

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

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Уводите обсуждение подальше от возможностей.

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

Ловушка 2: спрашивать заказчиков, чего они хотят

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

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

Планируйте изменений для уменьшения риска.

Ловушка 3: неспособность адаптироваться к изменениям

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

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

Эффективная коммуникация помогает оптимизировать время и трудозатраты.

Ловушка 4: неспособность эффективно общаться

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Заинтересованные лица часто имеют разные приоритеты.

Регулярные общение помогает поставить ценный продукт.

Ловушка 5: нечастое общение

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

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Когда речь заходит о документации, думайте качественно, а не количественно.

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

Сфокусированная документация и обратная связь помогает повысить эффективность и точность.

Ловушка 6: громоздкие документы и слишком много информации

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

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Создайте центральное хранилище для артефактов проекта.

Централизованное управление информацией может способствовать сотрудничеству.

Ловушка 7: скрытые артефакты проекта

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Неопределенность создает риски на следующем этапе проекта.

Отложите первый черновик и вернитесь к нему позже со свежим взглядом.

Ловушка 8: неоднозначные требования

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

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

Что вызывает неопределенность? Бедное описание, неточная информация и предположение, что аудитория понимает так же, как вы и делаете.

Избегание ловушки

  • Используйте руководство по написанию, например, Элементы Стиля Вильяма Странка Младшего и Е.Б. Уайта, которое уже давно считается авторитетным справочным материалом для четкого, понятного текста — до и во время создания требований.
  • Создайте глоссарий и убедитесь, что включен каждый акроним и технический термин.
  • Представьте, что вы пишете для студента, который только что закончил колледж, или для тех, кто недавно присоединился к компании. Не ожидайте, что аудитория будет знать каждый термин и понимать каждое понятие.
  • Дополняйте текст визуальными эффектами. Это отличный способ выразить и простую, и сложную концепцию.
  • Шагните назад. После написания любого проектного документа, закройте его на некоторое время и прочитайте позже. Свежий взгляд может выявить неоднозначности.

Выигрыш

Четкие, понятные требования являются основой вашего программного проекта.

Основные моменты

Измерения результатов позволяют непрерывно улучшать процесс.

Ловушка 9: неспособность измерить и оценить процесс требований

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

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Изменения в одном требовании могут иметь значительное влияние на артефакты ниже.

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

Ловушка 10: изоляция ваших требований

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

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

Избегание ловушки

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

Выигрыш

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

Основные моменты

Решения IBM Rational для требований могут помочь вам избежать общих ловушек в разработке программного обеспечения.

Заключение

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

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

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

Программное обеспечение IBM Rational RequisitePro ® в сфере ИТ и программное обеспечение IBM Rational Doors ® в системной сфере обеспечивают трассировку и анализ влияния, который держит аналитиков, архитекторов, разработчиков и тестировщиков в соответствии потребностям бизнеса и требованиям на протяжении всего жизненного цикла поставки программного обеспечения.

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

Дополнительная информация

Чтобы узнать больше о решениях для требований IBM Rational для разработки программного обеспечения, обратитесь к представителю IBM или бизнес-партнеру IBM или посетите:

ibm.com/software/rational/offerings/irm

Rational Requirements Composer software:

ibm.com/software/awdtools/rrc/

Бесплатная загрузка Rational Requirements Composer:

https://jazz.net/projects/rational-requirements-composer/

Электронный пакет лучший практик поставки программного обеспечения: Сделать больше с меньшими затратами:

ibm.com/services/forms/preLogin.do?lang=en_US&source=swg-rtl_sdekit

Топ 10 секретов поставки программного обеспечения выполняя больше с меньшими затратами:

ftp://ftp.software.ibm.com/common/ssi/sa/wh/n/raw14139usen/RAW14139USEN.PDF

Калькулятор ROI:

ibm.com/software/rational/offerings/testing/roi/

Читайте наш блог RDM:

rationalrdm.wordpress.com

Следуйте за нами на Twitter: @RationalRDM

Стань фаном Rational Requirements Composer на Facebook:

http://www.facebook.com/home.php?#/pages/Rational-Requirements-Composer/47378244431?ref=ts

Posted in Полезное, Разное, Требования | Отмечено: , | Leave a Comment »

Руководство по Закодированным Тестам ИП. Совместное использование Закодированных Тестов ИП для общих компонентов ИП

Posted by Шамрай Александр на Август 13, 2013

Изменение Карты Закодированных Тестов ИП

Добавление объекта ИП в вашу карту ИП

Как только вы добавляете новое действие ИП в вашу Карту ИП, вы также добавляете большое количество объектов в вашу карту компонентов ИП как отображено ниже:

Рисунок 5 – Карта Объектов ИП

Иногда вам может понадобиться несколько карт и вы можете сохранить части конкретных областей в этих картах ИП, чтобы избежать использования одной большой карты. Будьте очень осторожны, не добавляйте слишком много, т.к. столкнетесь с проблемами поддержки и потенциальным дублированием объектов/действий. Вы возможно захотите иметь четкий план или «карту» того, как ваш проект выглядит и как они попадают в вашу карту.

Рисунок 6 – Меню Правой Кнопки Действия ИП

Создание, Обновление, Удаление

Чтобы выполнить эти действия, вы должны сначала добавить новую карту в ваш проект выполняя следующее:

Рисунок 7 – Добавление Карты ИП

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

Рисунок 8 – Новая Карта ИП при добавлении нового элемента

Далее добавьте новую Карту Закодированного теста ИП в проект.

У вас появляется возможность поиска элементов управления в карте пользовательского интерфейса и найти те, которые в настоящее время недоступны. Это можно сделать, щелкнув правой кнопкой мыши и выбрав этот объект, или перейти ко всем объектам, как показано ниже.

Рисунок 9 – Расположение объектов

Рисунок 10 – Нажатие Правой Кнопкой Мыши на Карте ИП

Сохраняя избыточные объекты в Карте ИП вы приведете к раздутию объектов/кода и это станет проблемой для поддержки. Обрезайте регулярно дерево, чтобы убедиться, что Карта ИП является чистой. Убедитесь, что вы обновили ваши действия, если они указывали на эти старые объекты.

Рисунок 11 – Предупреждение Visual Studio

ПРЕДУПРЕЖДЕНИЕМожно столкнуться с множеством проблем при удалении карты. Убедитесь, что нет тестовых случаев, которые зависят от удаляемого кода.

Объекты

Объекты находятся в правой части панели конструктора Карты ИП как отображено ниже.

Рисунок 12 – Расположение Всех Элементов Управления

Все эти объекты имеют свойства, которые помогут вам рассказать больше о них.

Рисунок 13 – Свойства Объектов

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

Рисунок 14 – Свойство Поиска

В данном случае это имя тега равное BODY. Оно также содержит понятное имя Bing и Id для UIBingDocument. При поиске 2-ух объектов или замены ссылок между ними – убедитесь, что имеете правильный объект и что в свойствах указывается ссылка на него.

Действия ИП

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

Рисунок 15 – Действие ИП

Проверки

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

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

Рисунок 16 – Построитель Закодированных Тестов ИП

Обновление Закодированных Тестов ИП на Основе Данных

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

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

Дружественные именования объектов

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

Рисунок 17 – Удаление Объекта

В некоторых случаях, Ctrl + F поможет вам найти все ссылки в вашем проекте и можно быстро обновить их с Быстрой Заменой. Есть также некоторые тонкие настройки в разделе Параметров поиска, если требуется учитывать регистр или использовать регулярные выражения, или подстановочные знаки.

Рисунок 18 – Поиск и Замена (Быстрая Замена)

Также помните, что это же применимо к Карте Элементов Управления ИП как отражено ниже:

Рисунок 19 – Переименование Элемента Управления

Разделение вашего текущего метода тестирования

Рисунок 20 – Разделение Тестового Метода

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

Создание собственных тестовых случаев

Модульное проектирование

Ниже небольшой пример веб-узла, который имеет 2 страницы. На странице 1 есть 2 элемента, которые вы собираетесь заполнить и проверить. На второй странице будет один элемент для заполнения и одна проверка.

В модульной конструкции мы бы разбили это так:

Рисунок 21 – Модель Тестового Случая

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

Рисунок 22 – Модульное Проектирование

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

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

Сцепление против связанности

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

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

Обратная сторона этой монеты находится около Связанности, где это то же, как и звучит, и вы берете 2 части автоматизации тестирования, которые были отдельными и объединяете их. Если вы когда-нибудь видели устройство сцепления труб, это та же концепция, где вы их сцепляете вместе, образуя жесткий трубопровод. Хотя на первый взгляд это кажется хорошей вещью «Эй, я люблю это, Мои тестовые случаи как трубы!» Такой призыв, я должен признать, звучит здорово на первый взгляд, но быстро теряет свой блеск, когда я скажу вам, что вы должны перекопать весь ваш передний двор для замены Дырявой сломанной трубы. Более того, вам придется делать это для каждого канала в районе, где вы объединили их также, как и этот. Не столь хорошо в ретроспективе.

Поэтому держите их раздельно – связывайте их вместе, чтобы сформировать то, что вам нужно, и оставляйте себе возможность связывать их вместе, быстро менять их или добавлять еще.

Свести к минимуму дублирование

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

Так как вы можете минимизировать дублирование? Опять же перейдем к нашему примеру приведенному ранее в этой главе, где мы хотим попытаться сохранить наши общие элементы общими. Вы можете начать с заполнения страниц и их разбиения, сопоставления вашего приложения в Библиотеке Классов Страницы или даже с помощью UML или другого решения, которое будет содержать эти страницы и объекты. Карта ИП помогает, но когда команды становятся больше и более разрозненными, вам нужно будет иметь несколько Карт ИП.

Смотрите документацию о нескольких Картах ИП.

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

Построение Закодированных Тестов ИП, которые можно совместно использовать в тестовой команде

Организация Проекта

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

Название проекта:
<Приложение или элемент управления для теста>.Coded UITests

Папка Карты ИП: Поместите все ваши Карты ИП в этой папке или в древовидной структуре в этой папке. Назовите ваши Карты ИП как <страница/название элемента управления>Map

Папка утилит: Поместите весь код утилит в этой папке

Закодированные тесты ИП: Положите ваши закодированные тесты ИП в корне проекта. Назовите ваши закодированные тесты ИП что-то вроде <Область>UITest.

Рисунок 23 – Структура Проекта

Несколько проектов

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

Карты ИП

Каждая Карта ИП представляет собой сочетание 3 файлов:

  • FileName.uitest – это XML-файл, который следует редактировать только с двойным щелчком на этом файле и используя редактор Карт ИП
  • FileName.cs – этот файл содержит пользовательский код и может редактироваться вручную. Он будет пустым при первоначальном создании.
  • FileName.Designer.cs – этот файл содержит сгенерированный код. Не редактируйте этот файл, т.к. все изменения могут быть перезаписаны в любое время, Visual Studio обновляет этот файл.

Рисунок 24 – Структура Карты ИП

ПРЕДУПРЕЖДЕНИЕНЕ следует изменять код в файле UIMapName.designer.cs. Ваши изменения могут быть перезаписаны, когда в следующий раз будет генерироваться файл конструктора. Файл конструктора обновляется при каждом сохранении файла UITest, и когда вы щелкаете на Создать Код в Построителе Закодированных тестов ИП.

Зачем разделять Карты ИП

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

Генерирование Кода Карты ИП

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

Создание методов и утверждений

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

Рисунок 25 – Генерирование Кода

Добавляйте сообщения при добавлении утверждения, это сделает понимание сбоя теста проще, если сообщение о провале подробное:

Рисунок 26 – Генерирование Проверки

ПРИМЕЧАНИЕИспользование стиля Паскаля и подробное именование методов, добавление комментариев и пользовательские методы утверждения делают разработку, отладку и обслуживание закодированных тестов ИП проще.

Добавление элементов ИП без утверждений

Вы можете добавлять элементы управления в карту ИП без добавления утверждения, развернув Построитель Закодированных Тестов ИП и нажав кнопку Добавить элемент управления (Alt+C) к Карте Элементов ИП.

Рисунок 27 – Добавление элемента контроля к Карте ИП

Связывание Карт ИП вместе

Мы можем ссылаться и вызывать каждую из этих карт по отдельности и успешно тестировать все наши сценарии без каких-либо проблем. Слабым местом при этом является то, что у нас будет дублирующий код в наших сгенерированных картах ИП. Критерий поиска для каждого элемента управления начинается с окна верхнего уровня. Эти критерии поиска используются модулем выполнения тестов во время выполнения для поиска правильного окна, в котором находиться каждый из элементов управления (предок верхнего уровня). Одно изменение в окне может разорвать кучу вещей в Карте ИП и заставить нас восстанавливать весь код. Вместо этого мы можем создать новый класс под названием TestRunUtility. Роль этой утилиты будет в связывании всех карт ИП вместе и заставить их использовать один алгоритм поиска одного предка верхнего уровня. Это может быть достигнуто с помощью метода UITestControl.CopyFrom или BrowserWindow.CopyFrom.

ПРИМЕЧАНИЕРассмотрите возможность использования метода UITestControl.CopyFrom или BrowserWindow.CopyFrom, чтобы заставить все сложные элементы управления или страницы браузера использовать критерии поиска одного предка верхнего уровня.

Закодированный Тест ИП

Рефакторинг с использованием редактора Карт ИП

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

Переименование

Если вам не нравится наименование вашего утверждения или метода, вы можете дважды щелкнуть на файл uitest для открытия Карты ИП и выделить метод, который вы хотите изменить. Нажмите клавишу F2 или щелкните кнопку на панели инструментов Переименовать и введите новое имя.

Рисунок 28 – Разделение метода

Разделение Методов

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

ПРИМЕЧАНИЕНаличие большого количества небольших универсальных методов с несколькими действиями в каждом методе способствует повторному использованию кода.

Редактирование Кода

Используйте редактор Карт ИП для перемещения утверждений и другого кода, который вы хотите изменить, из конструктора и в файл кода, чтобы ваши изменения не перезаписывались в следующий раз, когда генерируется Карта ИП. Дважды щелкните на файле uitest, который содержит код, который вы хотите изменить. В редакторе Карты ИП выделите метод, который вы хотите изменить-> нажмите кнопку переместить код (Ctrl + Alt + C)-> нажмите кнопку Сохранить все или клавиши ctrl + shift + S.

Рисунок 29 – Перемещение Кода

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

ПРЕДУПРЕЖДЕНИЕНЕ следует изменять код в файле UIMapName.designer.cs.

Редактирование Утверждения

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

Лучшие практики

Тест для ошибок

Хотя ошибки как часть нормального потока программирования обычно не одобряются, есть моменты, когда они уместны. Методами Закодированного Теста ИП можно и следует проверять, что ошибка возникает правильно. Для этого нужно использовать либо блок try-catch и выполнять утверждение для ошибки или использовать атрибут тестового метода ExpectedException.

Использовать обработку ошибок

Используйте блоки try-catch-finally в вашем тестовом методе так же, как и в вашей программе, чтобы сделать тестовый метод надежным.

Использование привязки данных

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

Управление тестируемым процессом

Как правило вы открываете и закрываете тестируемое приложение как часть закодированного теста ИП. Представьте себе, что вы автоматизируете десятки закодированный тестов ИП как часть процесса автоматической сборки и что каждый тест запускает тестируемое приложение, чтобы гарантировать известное хорошее состояние. Если тесты не закрывают приложение после завершения каждого теста, у сервера в конечном итоге закончится память, т.к. десятки экземпляров приложения остаются открытыми на агенте построения. Еще одна проблема с оставлением открытым теста является то, что он может установить состояние, которое будет использовать другой экземпляр тестового приложения (как сессия в приложении браузера) и которое может создать проблемы в навигации. Например, в тестовом сценарий веб-приложения предположим запущен браузер и требуется пользователь для проверки подлинности, но если есть уже сессия из другого браузера, приложение может предположить, что пользователь уже прошел проверку подлинности и перенаправить на домашнюю страницу. Чтобы избежать такой сценарий, каждый тест должен запускать и закрывать тестируемое приложение. Кроме того, это должно быть сделано надежно, так что даже если тестовый случай неожиданно упадет, приложение все равно закроется. Для достижения этого оберните ваш код теста в блоки try/catch/finally или используйте шаблон «using».

[TestMethod]

public void CUITMultUsingLAunch()

{

    TestRunUtility utility = new TestRunUtility();

    using (ApplicationUnderTest.Launch( @»C:\Program Files\Internet Explorer\iexplore.exe»))

    {

utility.HomePage.NavigateToTailSpinToys();

utility.HomePage.ClickModelAirplanes();

utility.ModelAirplanePAgeObject.ViewTreyResearch();

utility.TreyRocketPageObject.ValidateHeight();

utility.TreyRocketPageObject.ValidateWeight();

utility.TreyRocketPageObject.AddTreyToCart();

    }

}

Поддержка Internet Explorer 10 и HTML 5

Начиная с Visual Studio 2012, будет добавлена поддержка для закодированных тестов ИП веб-приложений, основанных на Internet Explorer 10. Internet Explorer 10 будет иметь надежную поддержку для зрелого стандарта HTML5 и CSS3. Закодированные тесты ИП будут также поддерживать эти новые функции. Смотрите статью MSDN с полным списком новых возможностей: http://msdn.microsoft.com/en-us/library/bb385901(v=vs.110).aspx

Posted in Coded UI Testing Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , | Leave a Comment »

Руководство по Закодированным Тестам ИП. Управление Закодированными Тестами ИП в процессе ЖЦРПО

Posted by Шамрай Александр на Август 7, 2013

Жизненный Цикл Разработки Программного Обеспечения (ЖЦРПО)

ЖЦРПО или жизненный цикл разработки программного обеспечения охватывает огромное множество различных процессов таких как: «Водопад», «Agile», «Scrum», «XP»; это некоторые из них.

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

Рисунок 1 – Пример фаз ЖЦРПО Водопад

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

Инициирование поставки

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

Требования

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

Проектирование

Тут ваши объекты начинают вступать в игру. Надеемся, что вы можете получить демонстрацию концепции или предварительные объекты/экраны, с которыми вы можете начинать планировать вашу карту объектов.

Построение

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

Стабилизация

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

Развертывание

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

Закрытие

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

Влияние на автоматизацию

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

ПРЕДУПРЕЖДЕНИЕ

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

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

Рисунок 2 – Пример общего тестового случая

В Visual Studio это будет выглядеть примерно так:

Рисунок 3 – Общий Сценарий Тестирования Закодированных Тестов ИП

Рисунок 4 – Пример UIMap.uitest

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

Итоги

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

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

Posted in Coded UI Testing Guide, Microsoft, Team Foundation Server, Visual Studio | Отмечено: , , | Leave a Comment »

 
%d такие блоггеры, как: