Кто пишет автоматизированные тесты UI? Разработчики или Тестеры?

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

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

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

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

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

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

selenium.clickButton("Button Text")

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо.

I think it depends mostly on the skill level of your test team, the tools available, and the team culture with respect to how developers and testers interact with each other. My current situation is that we have a relatively technical test team. All testers are expected to have development skills. In our case, testers write UI Automation. If your test team doesn't have those skills they will not be set up for success. In that case, it may be best for developers to write you UI automation.

Other factors to consider:

What other testing tasks are on the testers' plate? Who are your customers and what are their expectations related to quality? Каков уровень квалификации команды разработчиков и какова их готовность взяться за работу по автоматизации тестирования?

-Ron