FF 10.0.2
selenium-server-standalone-2.20.0.jar
WAMP запущен, локально http://localhost/addressbook/ открывается без проблем

Eclipse открывает пустое окно FF, ошибка остается.

Что я делаю не так?

Статья является модификацией более ранней версии, опубликованной в журнале “Windows Tech Journal”(10/96) и протоколами 14й Международной Конференции в Тестировании Программного Обеспечения, соответственно. Автор благодарит ST Labs за поддержку.

Ситуация 1. Во время разработки продукт передается от одного разработчика к другому. Каждый новый разработчик обнаруживает, что документация к продукту уже устарела и процесс разработки нарушен. После анализа в течение месяца каждый объявлял о неудачном проектировании и настаивал на необходимости написания больших объемов нового кода. По прошествии еще нескольких месяцев разработчик уходил или продукт передавался другому человеку, и весь процесс повторялся заново.

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

Ситуация 3. 100000$ было потрачено на внедрение современного набора инструментов для разработки. Вскоре обнаружилось, что данные инструменты не настолько мощные, портативные, надежные, чтобы использовать их для достижения значительных успехов в разработке. После ближайших двух лет попыток заставить их работать, инструменты были заброшены.

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

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

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

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

Странно, что почти все эксперты по тестированию, практикующие тестировщики, менеджеры по тестированию, и, конечно же, компании, продающие инструменты для тестирования, рекомендуют автоматизировать тестирование с таким чрезвычайным энтузиазмом. Хотя, возможно, «странно» не совсем правильное слово. В итоге, инструменты для автоматизации проектирования и разработки были огромной прихотью, и инструменты для тестирования просто другая сторона таких продуктов. От объектно-ориентированного до «безпрограммистского» программирования, идеалистическая пропаганда не новость в нашей индустрии. Так, может, высокое качество общедоступной информации и анализа автоматизации тестирования не такое уж удивительное, а скорее, просто знак незрелости данной области. Как сообщество приверженцев автоматизации, возможно, мы еще в фазе восхищения идеей автоматизации тестирования, но еще не разобрались в подводных камнях. Поспешу согласиться, что автоматизация – это отличная идея. Мне нравиться что-то автоматизировать гораздо больше, чем выполнять какие-либо другие задачи. Большинство тестировщиков, работающих полный день, и, наверное, все разработчики мечтают, что можно будет нажать большую зеленую кнопку и позволить лаборатории верных роботов сделать всю тяжелую работу по тестированию, тем самым освобождая их самих для более возвышенных занятий, как, например, сетевые компьютерные игры. Не смотря на это, если бы достигли этого Шангри-Ла, мы все равно должны были бы продолжать действовать с осторожностью.

Эта статья является критическим анализом «скриптового и проигрывательного» стиля автоматизации регрессионного тестирования приложений с графическим интерфейсом.