Кто пишет автоматизированные тесты пользовательского интерфейса? Разработчики или тестеры?

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

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

Вторая цель - помочь тестировщикам при работе с повторяющимися задачами.

Мой вопрос: кто должен создавать такие тесты? Неявное предположение в нашей команде состояло в том, что тестеры это сделают, но все, что я читал в сети, всегда, кажется, подразумевает, что разработчики создадут их как своего рода "расширенный unit test".

Некоторые мысли:

Разработчики, похоже, находятся в гораздо лучшем положении для этого, учитывая, что они знают контрольные ID, классы и т.д., и имеют гораздо лучшую картину того, как работает приложение.
Тестеры имеют то преимущество, что не знают, как работает приложение, и, следовательно, могут производить тесты, которые могут быть гораздо полезнее
Я написал несколько исходных скриптов, используя IronRuby и White. Это работает очень хорошо и достаточно мощно, чтобы делать буквально все, но тогда вам нужно написать код для написания тестов пользовательского интерфейса.
Все автоматизированные инструменты тестирования пользовательского интерфейса, которые мы пробовали (TestComplete и т.д.), кажутся невероятно сложными и хрупкими, и хотя тестеры могут их использовать, он занимает их примерно в 100 раз дольше, и они постоянно запускаясь в "случайную сложность", вызванную инструментами тестирования пользовательского интерфейса.
Наши тестеры не могут кодировать, и, хотя они очень умны, все, что у меня получилось, было забавным, когда я предлагал, чтобы тестеры могли писать простые рубиновые скрипты (хотя упомянутые скрипты примерно в 100 раз легче читать и напишите, чем искаженный беспорядок кнопок и datagrids, который, кажется, является стандартом для автоматизированных инструментов тестирования пользовательского интерфейса).

Я бы очень благодарен за отзывы других, которые пытались автоматизировать пользовательский интерфейс в команде разработчиков и тестировщиков. Кто сделал то, что сделал, и это хорошо работает? Спасибо заранее!

Изменить: Приложенное приложение - это приложение с богатым клиентом WPF С#, которое подключается к серверу с помощью WCF

Ответ 1

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

Альтернативой является использование простого инструмента GUI, который поддерживает язык (и скрипты данных) и позволяет QA визуально создавать сценарии, углубляясь в более тонкие детали языка только тогда, когда это действительно необходимо - здесь также может быть задействована разработка.

Самые успешные попытки, которые я видел, определенно были с последним, но настройка этого - трудная часть. Selenium хорошо работает для простых веб-приложений и простых потоков через приложение. JMeter также (для сценариев веб-разговоров для веб-сервисов) работал хорошо... Еще один вариант, который используется в встроенной тестовой жгуте - простой инструмент в верхней части языка сценариев (Groovy, Python, Ruby), который позволяет QA, чтобы поместить тестовые данные в приложение либо через графический интерфейс, либо через файлы данных. Файлы данных могут быть простыми файлами свойств или в более сложных случаях структурированными (например, YAML или даже Excel) файлами данных. Таким образом, они могут построить базовые тесты дыма, чтобы начать, а затем расширить их в различные сценарии, управляемые испытаниями.

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

Ответ 2

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

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

Ответ 3

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

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

Если интересно обсудить:

http://automation-beyond.com/2009/05/28/qa-automation-skill-matrices/

Спасибо.

Ответ 4

Как насчет тестеров, предлагающих тесты, и разработчики на самом деле его записывают?

Ответ 5

Я считаю, что вначале это во многом зависит от используемых вами инструментов.

В настоящее время наша компания использует Selenium (Мы - магазин Java).

Selenium IDE (которая записывает действия в Firefox) работает нормально, но разработчикам необходимо вручную исправлять ошибки, которые она делает против наших веб-приложений, поэтому не подходит для QA для написания тестов.

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

selenium.clickButton("Button Text")

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

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

Недавно я узнал о инструменте Twist (из Thoughtworks, построенного на движке Eclipse), который является оберткой для Selenium, позволяя писать простые английские тесты. Я надеюсь, что смогу предоставить это тестерам, которые могут писать простые утверждения на простом английском языке.

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

Ответ 6

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

Окурки могут быть заполнены с помощью комбинации пользователей QA/dev. Это позволяет CHEAPLY обучать QA людей тому, как писать тесты, и обычно они разрывают его, поскольку это способствует их безопасности работы.

Ответ 7

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

Ответ 8

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

Другие факторы, которые следует учитывать:

Какие еще задачи тестирования находятся на пластине тестировщиков? Кто ваши клиенты и каковы их ожидания относительно качества? Каков уровень навыков команды разработчиков и какова их готовность выполнять работу по автоматизации тестирования?

-Ron