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

Question

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

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

Вторичная цель — помочь тестировщикам при выполнении повторяющихся задач.

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

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

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

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

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

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

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

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

Редактировать: Рассматриваемое приложение представляет собой «многофункциональное клиентское» приложение C# WPF, которое подключается к серверу с помощью WCF.

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

Некоторое время назад я изложил свои мысли о матрицах навыков в нескольких сообщениях в блоге.

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

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

Спасибо.

Answer 4

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

Answer 5

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

Answer 6

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

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

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

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

selenium.clickButton("Button Text")

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

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

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

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

Answer 7

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

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

Answer 8

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

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

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

-Рон