An examples of watir-webdriver specs
Ruby version -> 1.9.3
RSpec version -> v3.1.7 - framework for unit tests in Ruby
Gems:

• Watir-webdriver => 0.6.11 - family of librarys for automate browser testing
• Nokogiri => 1.6.4.1 - xml librarys. it's for allure and couple of tests :)
• Allure-rspec => 0.6.4 - yandex's allure - nice html-reports
• Parallel_test => 1.0.7 - for run tests in parallel. One core - one test

В папке abstract_pages можно увидеть 2 файла - это описание страничек, а если быть точнее отдельных блоков (aka PageObject).

В папке specs лежат сами тесты, всего их 2 (для примера). Один проверяет авторизацию, второй проверяет добавление xml в админке.

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

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

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

Кейсов, завязанных на данных почти нет, поэтому с данными особо не мучался, ну а вообще выносил их сначала в отдельный класс, а потом делал управление данными через xml, чтобы было удобнее менять

Запуск через CI Jenkins параллельно (тут как раз вступает gem parallel_tests), удалённая нода на моей локальной машине. Пробовал работать с SauceLab, но кончилась триалка, да и не быстро на триальном аккаунте :) Отчёты в формате xml складываются в папку allure на сервере, откуда их уже и читает сам allure. Каждый шаг описан. Каждый набор и тест имеет приоритет и "фичу", которую покрывает. После каждого теста делается скрин (как делать скрин только после фэйла пока не понял. Конструкция с эксепшеном не понравилась. В cucumber есть обработка такого события, но его пока не использую). Папка со скринам очищается со следующим прогоном. В итоге отчёт пригоден для чтения менеджерами.

Изначальная и текущая стратегия: автоматизировать регресионный лист xml-админки для быстрого деплоя. Мелкие изменения по этому блоку каждый день и тесты задизайнены так, чтобы отлавливать критические ошибки, мешающие работе, поэтому проверок на ошибки вроде "не правильно ввели в поле" нету. Локализация бага производится вручную, если вообще нужна. Как правило скриншот покажет, в чём проблема. Поэтому собственно от прикрепления post и get отказался, собственно, как и копии html. Так же RSpec и allure позволяет понять, "сломан" ли тест (статус broken) или он всё же не прошёл ассерт (статус failed)