Есть много проблем, которые возникают при попытках автоматизировать UI. Перво-наперво, почему это надо делать?
- Заказчик, в подавляющем большинстве случаев, мыслит именно в категориях интерфейса. То есть все, что он себе представляет - это внешний вид системы и ее реакцию на действия пользователя. Естественно желание сделать нечто, что сразу же говорит разрабочтику, соответствует результат работы этим требованиям или нет.
- Если все нижние слои системы покрыты тестами, то UI получается самым слабым звеном. В нем чаще всего появляются и сложнее всего ищутся ошибки. А тратить 20 минут и лезть в какой-нибудь ASP.NET-отладчик, который съест полтора гига оперативки, ради того, чтобы узнать, что какой-нибудь там дропдаун (dropdown) не восстановил состояние из вьюстейта (viewstate), согласитесь, раздражает.
Теперь, какие же все-таки возникают проблемы, помимо самой технической нетривиальности?
- Там приходится программировать. Это утверждение не кажется таким уж глупым, если учесть, что отделы QA укомплектованы не программистами. QuickTestPro предлагает писать скрипты на бейсике, различные NUnit-библиотеки для ASP используют прямо C#. Кроме того, для каждого теста надо готовить исходные данные, для чего может понадобиться соответствующий навык, чаще всего SQL.
- Эти тесты ужасно долго работают. В большинстве случаев системы тестирования позволяют записать примитивный макрос - последовательность движений и кликов мышки, нажатия клавиш и т.п. То есть для тестирования веб-приложения система открывает браузер, ходит там по нему, кликает и т.п. Таким образом, это не дает немедленного фидбека разработчику так, как это делают юнит-тесты.
- Соответственно, тестирование нельзя запустить в фоновом режиме на рабочей машине. Приходится еще и выделять отдельный компьютер. Иногда бывает проблемой.
- Поддержка написанных тестов в рабочем состоянии - головная боль тестеров. Интерфейс пользователя меняется быстро. В ASP.NET, скажем, стоит положить контрол на страничке в другой контейнер, как его клиентский ID кардинально изменится. Тест поломается, а выполняется он долго, то есть чинить его тоже достаточно долго и неприятно. В итоге все сведется к тому, что тестер плюнет на все, самостоятельно пробежится по страничкам и на глаз посмотрит, что "вроде все правильно".
- Чувствуется большой недостаток в общении между разработчиками и тестерами. То есть по идее, исходя прямо из тербований заказчика, можно было бы изначально договориться о том, какие элементы управления понадобятся на данном экране. Потом на экран попросту сверху вниз слева направо добавляются все необходимые кнопки, которые пока ничего не делают. На этом этапе тестеру уже есть над чем работать.
Надо сказать, мне кажется, что большинство проблем было бы решено, если посадить за тестирование программистов. Причем не каких-нибудь интернов, а полноценных. Больших технических знаний там не потребуется, но культуры программирования надо не мало. Я ни в коем случае не говорю, что "в топку тестеров", поле деятельности для неавтоматизируемой работы все равно огромно.
