Участники обозначили проблемные области и делятся своими решениями.

(в сторону) я ж говорил, data-driven testing невозможно без встроенной модели данных с полной поддержкой сервис-методов.

Просто неровное брюзжание на тему “заколебался жить в Молдове, вдали от всего интересного и происходящего”.

Или мне уже лечить параною?

“How to implement UI testing without shooting yourself in the foot”
http://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/

Обратите внимание на линк: Robot Framework.

Но я проблему уже решил, затащив лично Баранцева в скайп.

Кто-нибудь видит решение проблемы?

==
А в чём проблема вызвать того же Панкратова в Кишинёв? Насколько я помню “стоимость”, что-то окол 1000-1500 $/E
Это за 8 часовой тренинг, насколько мне не изменяет, опять таки, моя память.
Найти 10-15 человек готовых потратить 100 у.е. в Кишинёве сложно? Лично я бы потратил, при условии что тематика будет меня интересовать.

Я не собираюсь переходить к обсуждению вопроса “платные против бесплатных” (хотя всем, думаю, понятно, на какой я стороне).

Я говорю конкретно за Selenium и могу повторить ещё раз: Selenium хорошо решает ОДНУ задачу, это хороший надёжный драйвер WebUI, остальные интерфейсы доступны через другие библиотеки.

Поэтому бессмысленно называть его словом “инструмент” и сравнивать с другими “инструментами”.

Платформа для написания тестов с использованием Selenium — это Java или .Net или ещё один из почти десятка доступных языков программирования. Вот на этом уровне и надо сравнивать. Включая средства разработки и отладки. Включая возможность запуска в различных окружениях. Включая возможность использования и наличие готовых библиотек.

Цитата из Баха.
“…think of test tools as any tool that may help (especially cheap or free tools). Avoid expensive tools…”
Дело в том, что время зачастую все-таки гораздо дороже, чем деньги, и это главная проблема cheap free tools. С ними всегда нужно слишком многое строить с нуля. Да, Loadrunner тянет на десятки тысяч долларов, но с ним можно выдать все решающие тесты за неделю. Если сам проект имеет бюджет в сотни (или больше) тысяч долларов, а релиз через полгода – некогда огород городить.
Вторичная проблема при построении с нуля – тяжело поддерживаемый код. Настолько тяжело, что зачастую приходится его выбрасывать и начинать по новой. Никакого проджект-менеджера это не обрадует, и все это идет в минус автоматизации.

PS. Есть еще одна уловка в той цитате. Месячная оплата дорогого консультанта может запросто превысить стоимость лицензии коммерческого тула – с использованием которого процесс автоматизации может быть сокращен вдвое, а результаты будут весомее.

Но конечно же я не могу не согласиться, что разделение по специализации внутри команды тестирования возможно и зачастую необходимо. И не только по видам тестирования, но и разделение на “труэ тестировщиков” и “toolsmiths” (http://www.satisfice.com/blog/archives/15)

Почему?

Вот как раз “model-based test language” к работе тестировщика и относится. А “hybrid keyword/data driven framework” относится к работе инженера по автоматизации, или же консультанта, который всегда “и жнец, и швец, и на дуде игрец”.

Скажем, работая в должности Regression & Automation Lead, я имел в отделе 4 QA аналитика, все они писали тесты на метаязыке, и только одна из них помогала в расширении фреймворк. Regression testing представлял из себя прогон скриптов после каждого билда (smoke test), и прогон скриптов на входе-выходе билда из каждого test environment (sanity test). Найденные проблемы, естественно, изучались вручную, равно как и свежие багфиксы. ПЕРЕД автоматизаций нового дерева логики осуществлялся эксплоратори тестинг бизнес-функции, в процессе которого и создавался новый тест.
Остальные 12 QA в других отделах, равно как и наши коллеги в UAT, не писали ни фреймворки, ни тесты. Они настраивали под свои нужды и запускали (автоматические) тест планы, расширяли набор тест данных, пользовались результатами, и давали заявки на новое покрытие. Сам проект двигался в Waterfall, автоматизация, естественно, в схеме Agile. Вообще, при автоматизации, быстрый фидбэк тестеров – главное дело.
Таким образом, на 20-30 человек, занятых в тестинге, непосредственно с тулом и кодом работало двое, и еще двое активно участвовали в тест дизайне. Они и продолжают работать по внедренной мной схеме, благо фреймворк создан, отточен в процессе интенсивного использования на 3 релизах, и нового кода писать не требуется. Только тест-дизайн.

Когда работаешь консультантом, ситуация несколько иная. Клиент ждет решения конкретной задчи. Здесь приходится работать, как правило, одному и поэтапно: изучение проблемы, выбор средств, внедрение фреймворка, создание тестов и выдача результатов. Как правило, на двух последних этапах подключаются штатные QA-BA, осваивают ИСПОЛЬЗОВАНИЕ системы, участвуют в тест-дизайне и создании базы тест-данных. Поскольку к тому времени автоматизация уже активно используется в проекте, все компоненты проходят необходимую обкатку, сотрудники приобретают навыки работы (с автоматизацией), проект получает полезную отдачу (от автоматизации), а менеджер – уверенность (в автоматизации).

PS. Вышеописанные примеры относятся к функциональному тестированию.
Автоматизация задач на бэк-энде, нагрузочное тестирование, API / Unit тесты – имеют свою специфику и циклы, и реализуются по-другoму.