Jira как инструмент управления тестовыми примерами

Ответ 1

Проведя последние несколько недель, пытаясь настроить Jira для управления тестовыми записями, я могу предложить преимущества моего опыта. Инструкции, упомянутые выше (Настроить JIRA для управления тестовыми примерами) являются ошибочными и неполными, поэтому следует предупредить. тема Jira Test Case на форумах Atlassian очень полезна.

Изменить: Эта ссылка не работает, Atlassian "Форумы" больше не используются. Используйте эту ссылку: Настроить Jira для управления тестовыми примерами.

• Инструкции для Jira 3.x. Самая последняя версия - 4.2. Существуют различия.
• Шаг 5, "Пользовательские поля" имеют неправильные имена полей. Первый экземпляр "Шаги к завершению" должен иметь название "Фактический результат".
• Шаг 8.2 требует, чтобы вы назначили шаг "Создать проблему" на "Создать экран тестового примера". Поскольку вы не создали никаких рабочих процессов или шагов, это будет сложно. Вам нужно будет вернуться к этому шагу после завершения этапа 9.
• Шаг 9, "Пользовательский рабочий процесс" очень запутан. Вам предлагается создать новые состояния дважды (шаг 9.1 и шаг 9.4/5). На шаге 9.1 вы хотите создать новые "статусы", а не "государства". На шаге 9.4/5 вы хотите создать новые "Шаги", а не "Штаты". Шаг
• Для создания новых шагов требуется создание новых переходов. Каждый переход будет связан двумя шагами. Вам нужно будет создать переходы при создании шагов.

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

Ответ 2

В настоящее время мы используем TestLodge test case tool для управления нашими тестовыми примерами и требованиями и объединяемся с Jira для создания тикетиков неудачных тестовых случаев.

Ответ 3

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

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

Ответ 4

В нашей команде у нас есть отдел QA, который использует QC (и по-прежнему использует его для некоторых проектов), и мы используем организацию проблем следующим образом:

Верхний уровень

• Требование - захват фактической истории пользователя. Создано BA, присвоенное DEV lead, принадлежащее BA.
• Инцидент - захват проблемы, возникшей с производственной системой. Создано BA/operations, присвоенное QA, принадлежащее BA.
• Двоичный пакет - создан и принадлежит команде Deployment для отслеживания жизненного цикла каждого созданного бинарного пакета. Пока мы отслеживаем развертывания и изменяем задачи как комментарии, но если мы хотим быть более мелкомасштабными, мы могли бы использовать и отдельные дочерние проблемы.
• Test Round - верхний уровень - обычно для целей отчетности вы хотите отделить артефакты, созданные каждым тестовым прогоном/фазой вашей команды QA. Проблемы с тестовым запуском - это контейнеры для дефектов.
• Test Case - создан, назначен и принадлежит менеджеру QA. Здесь у вас есть выбор:
  • определяется как проблема верхнего уровня - вы можете связать ее с требованием, несколькими требованиями или создать автономный (например, для захвата сценария регрессии, не отслеживаемого в JIRA.
  • определяемый как подзадача, ограничивает вас одним родителем, но вы все равно можете связать связанные требования/инциденты. Большая разница заключается в том, что это заставляет вас отслеживать причину каждого теста в JIRA.
  • для многих проектов мы по-прежнему сохраняем тестовые примеры в QC и отслеживаем только дефекты в JIRA.

подзадачи

• Разработка (по требованию) - создана ведущим DEV, назначенным команде DEV, принадлежащей команде DEV. Описание части работы или части использования, которая оценивается и присваивается одному человеку.
• Дефект (при тестировании или инциденте), созданный QA/DEV, назначенный команде DEV, принадлежащей QA. Описание изолированного дефекта. Для большинства целей он обрабатывается так же, как и Разработка, за исключением того, что он должен быть подтвержден и закрыт QA.
• Test Run - документирование результатов одного тестового прогона. Мы по-прежнему считаем QC лучшим инструментом для этого, хотя JIRA также может быть работоспособным, особенно если мы напишем несколько плагинов.

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

Ответ 5

это может быть то, что вы хотите:

http://blogs.atlassian.com/jira/bonfire/

Ответ 6

Попробуйте дополнения Kanoah Tests.

Это комплексное решение для управления тестированием, специально разработанное для JIRA.

Посетите сайт www.kanoah.com для получения дополнительной информации

Ответ 7

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

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

В моем случае я сейчас перейду к специальному инструменту управления тестами.

Ответ 8

Мы являемся экспертами Atlassian Enterprise и Platinum, и, хотя вы можете настроить JIRA для использования в качестве основного инструмента управления тестированием, вам необходимо понять, что он превосходит инструмент управления инцидентами, инструмент управления задачами и гибкий инструмент управления (с JIRA Agile).

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

Я работаю для Catch Software (http://www.catchsoftware.com), мы создали Enterprise Tester, веб-инструмент управления тестированием, который имеет ведущую на рынке JIRA интеграция.

Эта интеграция позволяет автоматически генерировать тестовые примеры из JIRA-историй, автоматически создавать проблемы JIRA из тестовых прогонов и позволяет размещать гаджеты отчетов в JIRA или Confluence, чтобы ваша команда менеджеров могла видеть все показатели в одном месте.

Вы получаете чистый инструмент управления тестированием, который легко интегрируется (без плагинов) с вашим внутренним экземпляром JIRA или OnDemand.

Итак, проверьте свои потребности в тестировании, и если вам нужны основы тестирования, мы можем помочь вам с помощью встроенного решения JIRA или если вам нужен более специализированный инструмент для управления тестированием, тогда не стесняйтесь проверить Enterprise Tester (http://www.enterprisetester.com)

Отношения Bryce

Ответ 9

Я бы порекомендовал Zephyr для JIRA, который является отличным дополнением к управлению тестированием, которое хорошо интегрируется с JIRA. Это позволяет вам поддерживать комплекты тестов и исполнения в дополнение к управлению Epic/User Story.

http://getzephyr.com/

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

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

Я использовал HP ALM (и QC, когда он был вызван так!) для наших ранних программ. Теперь, когда диск должен идти гибким, мы обнаружили, что ALM является слишком громоздким для Agile... Возможно, я ошибаюсь, но после Zephyr/JIRA мы решили остаться с Zephyr для управления тестированием;)

В моей оценке, Zephyr для JIRA работает для нас хорошо. Я сделал POC, используя одну из схваток, над которыми я работаю (ее большая программа из 6 различных схваток!), И теперь они начали выкатываться в другие команды, и им также понравилась идея и вся настройка. Точка цен также не так высока.

P.S. - Мы используем Zephyr для JIRA Server.

Я надеюсь, что эта информация поможет.

Ура!

Ответ 10

Я бы предложил инструмент управления тестом qTest Test Case QASymphony. интеграция JIRA лучше всего в классе. Вы можете преодолеть все усилия по разработке, будь то рассказы JIRA, задачи или подзадачи (или настраиваемые типы проблем), а также построить прослеживаемость для них с помощью инструмента, связав с ними тестовые примеры. В конечном счете позволяет создавать отчеты с одним щелчком мыши.

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