Интеграция инструментов тестирования QA

Question

Мне нужен совет по выбору правильных инструментов для моей стратегии тестирования регрессии. Основными критериями являются «лучшая покупка» подходящего инструмента. После анализа примеров Gartners я пытаюсь выбрать решение Atlassian и IBM QA. Основная дилемма заключается в том, что платформа IBM Jazz объединяет функциональный тестер Rational в качестве решения для тестирования автоматизации, а Atlassian использует платформу Jira, которая по умолчанию не интегрирует тесты тестирования автоматизации.

Наша компания ориентирована на Java, поэтому мы исключаем HP Quick Test Professional из-за языка сценариев VB.

Варианты:

1. Atlassian: Jira - Greenhoper - Зефир - Селен 2
2. IBM: Jazz - Rational Quality Center - Rational Team Concert - Rational Functional Tester.

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

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

Приложение для тестирования - это веб-приложение java и интеграция с другой системой.

Вопрос: Возможно ли, что RFC интегрируется с Jira не с Jazz? Если да, что вы думаете о решении Atlassian - Jira - Greenhoper - Zephyr - Rational Functional tester?

Answer 1

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

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

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

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

Что также напоминает мне, Zephyr не единственные, кто интегрируется с Jira и знает, как запустить Selenium (или TestComplete или любую другую систему автоматизации). Вы также можете проверить наше решение. Это называется PractiTest, и это может быть еще один вариант для вас попробовать (извините, если вместо того, чтобы упрощать вещи, я добавил вам еще одну вещь, чтобы рассмотреть :-)

В любом случае удачи!

-joel

Answer 2

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

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

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

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