×Закрыть

Автоматизация тестирования Prom.UA на примере Java и JBehave

Исходный код приложения доступен здесь. Загрузить его себе можно с помощью команды:

git clone https://github.com/irinkav/promua-test-app.git

Содержание

Вступление

Некоторое время назад у меня появилось желание попробовать на Java написать простенькое приложение для тестирования веб-интерфейса Prom.UA, которое бы следовало популярному сегодня направлению разработки приложений — BDD (Behavior-Driven Development). И в этой статье я хочу поделиться своей находкой в этом направлении.

Начну с того, что свое внимание я остановила на BDD потому, что, как мне кажется, этот процесс, расширяя идеи TDD (Test-driven development), фокусирует наше внимание на реализацию минимальной коммерчески ценной функциональности (minimum marketable feature), которая представляет собой наибольшую ценность для бизнеса. Достигается это за счет ориентации на взаимодействие между командами бизнес-пользователей и разработчиков. При этом используется общий язык для такого взаимодействия, что сближает команды, и, в конечном счете, значительно снижает недопонимание в проекте, тем самым экономя время и убирая ненужный код и функциональность.

Набор инструментов

Для реализации приложения я выбрала следующий набор инструментов:

  • Apache Maven — фреймворк для автоматизации сборки проектов. Eго я выбрала исходя из соображений того, что он позволяет легко управлять зависимостями (благодаря поддержки транзитивных зависимостей и возможностью централизировано управлять зависимостями и плагинами — dependencyManagement, pluginManagement), версиями, обеспечивает зеркалирование зависимостей в локальный репозиторий, придает структуру приложению, благодаря которой большинство IDE (для разработки на Java) поддерживают этот фреймворк, и благодаря чему легко обеспечивается переход к процессу непрерывной интеграции приложения
  • JBehave — BDD фреймворк, который помогает автоматизировать приемочные тесты и поддерживает процесс разработки в BDD стиле. В этом фреймворке бизнес требования и их приемочные критерии описываются в виде, так называемых, пользовательских историй (user stories). Выбрала его, а не любой другой BDD фреймворк потому, что:
    • он хорошо документирован
    • лицензия позволяет его свободно использовать в проекте
    • у него открытый исходный код, который в случае проблем дает преимущество в отладки для нахождения workaround’а, если проблему еще не исправили в основном релизе
    • мне понравился подход и стиль, по которым пользовательские истории связываются с Java POJO объектами
    • у него есть библиотека, облегчающая взаимодействие с Selenium WebDriver API (jbehave-web-selenium), например ответственность за управление жизненным циклом браузера лежит на ней (см. Driving Web Behaviour
    • по результатам прохождения тестов генерируется отчет в достаточно детальной и удобочитаемой форме
  • Selenium WebDriver — фреймворк для автоматизации тестирования веб приложений. Выбрала его по нескольким причинам:
    • имеет богатое API для тестирования веб интерфейсов, написанных на HTML/CSS/JavaScript и которые нуждаются в проверки на различных популярных браузерах, таких как IE, Firefox, Google Chrome, Safari и других
    • один из самых популярных фреймворков на сегодняшний день, что в целом облегчает поиск различной информации по нем и, на мой взгляд, служит почвой для развития лучших практик в автоматизированном тестировании проектов
    • он бесплатен и распространяется под лицензией Apache License 2.0, что позволяет на нем писать собственное программное обеспечение и при этом не распространять на него исходного кода
    • у него открытый исходный код, который в случае проблем дает преимущество в отладки для нахождения workaround’а, если проблему еще не исправили в основном релизе
    • если нет подходящей версии браузера на одной машине, можно присоединиться к удаленной машине, где он есть, и выполнить на ней тест
    • тесты, написанные с его помощью можно исполнять в распределенной среде (Selenium-Grid), где разные тесты могут выполняться на разных машинах (все зависит от конфигурации)
    • Selenium WebDriver’ом можно работать на различных языках, таких как: Java, Python, .Net, Ruby, PHP, Perl, JavaScript
  • Spring. Этот фреймворк я выбрала для организации зависимостей в проекте
  • JUnit фреймворк — который служит платформой для написания и выполнения тестов. Выбрала его, потому что его функциональности вполне достаточно для покрытия бизнес требований, приведенных в качестве примера в приложении и также потому, что именно этот фреймворк идет в коробке с JBehave (имеется ввиду в виде транзитивной зависимости)
  • Hamcrest — фреймворк с большой коллекцией хорошо сочетаемых matcher’ов для проверки различных условий, причем, на мой взгляд, сочетаются эти matcher’ы гармонично и исключения выбрасываются по ним в удобочитаемой форме

Шаблон для проекта

После того, как я определилась с набором инструментов для реализации своей задумки я продолжила с того, что принялась гуглить уже готовые решения. И вот, по прошествии некоторого времени, мне попался один замечательный Maven Archetype, который почти удовлетворял мои пожелания. Называется он jbehave-web-selenium-java-spring-archetype, и находится в центральном репозитории Maven 2 (Maven 2 central repository). Maven Archetype — это инструмент, который позволяет легко и быстро сконфигурировать проект под себя по шаблонам существующего проекта. Для того, чтоб сконфигурировать проект под себя я воспользовалась командой:

mvn archetype:generate -Dfilter=org.jbehave.web:jbehave-web-selenium-java-spring-archetype

и далeе просто следовала инструкциям (см. Archetypes)

Что было мной проделано

  1. Адаптировала пользовательские истории под наш портал Prom.UA
  2. Перевела все зависимости проекта на использование Dependency Injection принципа на основе механизма аннотаций на базе Spring. Аннотации представляют собой метаинформацию для обозначений участков кода. Например: мы хотим, чтоб зависимость A в процессе инициализации получила зависимость B, для чего просто помечаем в зависимости A свойство, сеттер или конструктор, отвечающий за работу с зависимостью B, аннотацией @Autowired, и обоим зависимостям добавляем аннотацию @Component, чтоб обозначить их, как зависимости, управляемые Spring контейнером. На мой взгляд, применение аннотаций улучшает читабельность кода по той причине, что не нужно ходить в конфигурацию, чтоб понять, как будет построен объект во время его конструирования контейнером Spring
  3. Убрала фабрику PageFactory, так как в ней необходимость отпала после полноценного перехода на Spring Dependency Injection
  4. Убрала зависимость на fluent-selenium (обертка над Selenium WebDriver), чтоб уменьшить количество звеньев от кода приложения до браузера, тем самым сузив возможное разнообразие ошибок. Да и API Selenium WebDriver’а мне кажется вполне сносным и хорошо документированным. Хотя для тех, кто все же со мной не согласится, то можно его добавить в pom.xml (см. jbehave-web-selenium-java-spring-archetype maven archetype, там он используется), и тогда ваши обращения к WebDriver’у могут стать похоже на FluentInterface, о котором писал Мартин Фаулер
  5. Параметризировала сценарий promua_search.story так называемой таблицей с примерами (examples table), при которой в сценарии описываются шаги с отметками, а отметки во время выполнения подменяются на значения из таблицы, что убирает необходимость в повторном написании одного и того же сценария для разных входных данных. Детальней можно прочитать здесь: Parametrised Scenarios
  6. Добавила абстракцию над существующими PageObject’ами, которая позволяет осуществлять запросы за веб элементами через WebDriver к браузеру с использованием явных и не явных ожиданий для получения результата обращения. Тут, кстати, мне пришлось реализовать свой велосипед, так как существующие решения иногда отказывались работать по исключению NoSuchElementException. Придумала я реализовать это решение на основе кеширующего пула потоков и задач. Последние отправляю в пул на выполнение. На каждую задачу устанавливается время ожидания, интервал выполнения и локатор для поиска веб элемента. В целом, инициализация очень похожа на FluentWait (благодаря шаблону Builder, который я для себя открыла после прочтения о FluentInterface, ©Мартин Фаулер), но внутри реализация своя. Если результат обращения за веб элементом возвращается раньше, то задача завершается, и результат возвращается. Возможно это решение и не идеальное, но зато тесты перестали падать по исключению NoSuchElementException с теми же настройками ожидания и интервалом, что использовала во FluentWait (см. Class FluentWait). Почему такое происходит, я затрудняюсь сказать
  7. Добавила поддержку создания скриншота по случаю возникновения ошибки во время выполнения сценария путем объявления бина WebDriverScreenshotOnFailure в Spring контексте (файл конфигурации promua-steps.xml). Этого достаточно, так как мы создаем фабрику SpringStepsFactory в PromUaStories.stepsFactory, которая получает контекст Spring’а и в дальнейшем использует Spring бины из контекста для работы с JBehave аннотированным кодом (используя механизм Dependency injection), например, во время выполнения шагов (step’ов). Об этом можно прочитать здесь: Dependency Injection в JBehave
  8. Упорядочила зависимости в pom.xml (файл конфигурации Maven)

Spring бин — это объект, который управляется Spring’ом.

По поводу Spring хочу также добавить, что в promua-steps.xml определены два бина:

  • <context:annotation-config />
    — используется для включения механизма аннотаций у уже зарегистрированных бинов в контейнере Spring
  • <context:component-scan base-package="ua.prom"/>
    — используется для сканирования пакетов ua.prom*/** на предмет аннотаций над бинами, например такой как @Component с последующей регистрации такого бина в контейнере Spring

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

Как работать с проектом

  1. Для сборки проекта и последующим выполнением всех пользовательских историй нужно выполнить команду
    mvn clean install
  2. Для сборки проекта и последующим выполнением пользовательских историй, которые удовлетворяют фильтр по названию файла с пользовательской историей, нужно выполнить команду
    mvn clean install -DstoryFilter=promua_cart
  3. Для сборки проекта и последующим выполнением пользовательских историй, которые удовлетворяют фильтр по мета информации, нужно выполнить команду
    mvn clean install -Dmeta.filter="+category basic"

Тут я хотела бы сказать несколько слов по поводу мета информации. Построения соответствия между мета информацией и пользовательской историей происходит во время фазы integration-test (описано в pom.xml файле конфигурации Maven) и вызовом в этой фазе PromUaStoryMaps со списком мета фильтров (metaFilters). В результате этого, во время выполнения пользовательских историй выполняются только те, которые удовлетворяют критерию фильтра (см. Meta Matchers)

Просмотр результатов тестов

После выполнения тестов в директории target/jbehave/view будет создан файл, который называется reports.html. В этом файле описывается результат в виде таблице в разрезе сценариев, шагов и их результатов выполнения. Каждая запись в таблице соответствует пользовательской истории. В правой части таблице, в последней колонке, находятся ссылки. Кликая по ссылке вы перейдете к детальному отчету по выбранной пользовательской истории.

Структура проекта

  • ua.prom — пакет в котором определены сущности по конфигурированию контекста выполнения тестов. PromUaStoryMaps выполняет привязку мета информации к пользовательской истории. PromUaStories занимается конфигурированием контекста выполнения и непосредственно запуском пользовательских историй. По своей сути оба класса являются точкой входа (entry-point) приложения, которые используются JBehave’ом для настройки и запуска пользовательских историй
  • ua.prom.pages — пакет в котором определены сущности, реализованные в соответствии с шаблоном PageObject, используемых в шагах (step’ах) для абстракции и обеспечения лучшей организации кода. В классе PageObject вообщем-то и находится разработанный и спрятанный мной велосипед по работе с поиском веб элементов
  • ua.prom.steps — описаны сами шаги (step’ы). JournaledStoriesSteps выполняется после каждой пользовательской истории и выводит в лог журнал команд WebDriver’а (наследие от Maven Archetype для примера). LifecycleSteps — чистит карту покупателя перед каждой пользовательской историей (также наследие от Maven Archetype для примера)
  • src/main/resources — находятся ресурсы приложения. log4j.properties — файл свойств логгера, который пишет разного рода информацию в настроенный вывод (может быть файлом, консолью и др.). promua-steps.xml — файл конфигурации Spring, где я описала только те зависимости в виде бинов, которые не находят своего отображения в коде приложения (над ними невозможно поставить аннотации @Component, так как они подключены и используются в проекте как третьи зависимости)
  • src/main/stories — находятся текстовые файлы с пользовательскими историями (user stories)

В завершения своей статьи хотела бы еще добавить, что аннотацию @Component можно было бы и расширить до @Steps и использовать ее для аннотирования шагов (step’ов), и она тоже бы воспринималась родной Spring’у (я видела такой подход во многих проектах на GitHub), но я этого не стала делать, так как мне показалось, что людям, которые будут поддерживать этот код после меня, как мне кажется, будет более очевидней, какой жизненный цикл сущности под аннотацией @Component, нежели под аннотацией @Steps. Конечно же, все это при условии, что никакой другой ответственности не будет повешено на аннотацию @Steps. В противном же случае, возможно, ее следует ввести (и при этом не забыть задокументировать для потомков).

Спасибо всем за внимание.
Хороших праздников и хорошего Нового Года!

  1. Хороший tutorial по Spring: Spring Framework Tutorial
  2. Еще один хороший tutorial по Spring: Spring Tutorial
  3. Хороший tutorial по Maven: Maven Tutorial
  4. Еще один хороший tutorial по Maven: Maven Tutorial
  5. Официальный ресурс по JBehave: JBehave
  6. Презентация по JBehave: BDD with JBehave and Selenium
  7. Официальный ресурс по Selenium WebDriver: Selenium WebDriver
  8. Хороший tutorial по JUnit: JUnit Tutorial
  9. Хороший tutorial по Hamcrest: The Hamcrest Tutorial
  10. BDD: Behavior-driven development
  11. Minimum Marketable Feature: Incremental funding methodology
  12. Описание шаблона PageObject: Page Objects
  13. Описание фабрики: Factory (software concept)
  14. Описание шаблона Builder: The builder pattern in practice
  15. Описание шаблона Dependency injection: Dependency injection
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Вопрос к автору: вохможно ли еще где-то скачать исходники данного проекта? По ссылке в посте он больше недоступен.

Спасибо!

Поздравляю с хорошей статьёй (и новым годом :) )
Я помню историю от основателей Prom.UA, о том, как 3-е Java программистов решили созадать стартап на Python...
Так вот вопрос: а почему все таки была выбрана Java для фреймворка, а не Python?

Обычно суровые Java-программеры пишут тесты и билд-скрипты на Пайтоне или Груви, а тут все наоборот :D

Я помню историю от основателей Prom.UA, о том, как 3-е Java программистов решили созадать стартап на Python...
Так вот вопрос: а почему все таки была выбрана Java для фреймворка, а не Python?
Думал задать такой же вопрос но сдержалсо. И удивлен почему reality_hacker его не задал :)
.
Есть подозрение что причина в том что под ждаву средства для УИ-тестирования очень развиты, имеют много доступных мануалов.
Не слышал про подобные штуки (типа селениума или ватира) для Питона. Интересно узнать насколько они отличаются от джава-инструментов.

Много хороших инструментов и на Python и на Ruby по автоматизации тестирования UI.
Особых отличий в API Selenium WebDriver’а для Python и Java я не нашла кроме синтаксической разницы.

Особых отличий в API Selenium WebDriver’а
А я не про API WebDriver-а, я про инфраструктуру в общем. Например, github.com/...ls/htmlelements вроде как нет версии для Python и по каким-то странным причинам сама библиотека таки сделана под Java-инфраструктуру.
Я не КуА, поэтому инфа по вопросу авто-тестов ко мне может доходить однобоко, но то что доходит выглядит так: менейнстрим — это УИ-тесты в среде Java, Ruby или Node.js, люди пишут о своем опыте и о «новом классном инструменте который придумали» именно на этих экосистемах. Честно говоря не могу вспомнить даже одной статьи, которая мне попадалась, (я не отрицаю их существование) где бы люди описывали опыт построения инфраструктуры для UI-тестов в экосистеме Python-а.

Чтоб статью сделать полезней, я выбрала Java, так как с ней уверенней себя чувствую.
Почему технология Python была выбрана нашими ребятами для разработки портала, написано здесь: Prom.ua: украинский стартап в ответе на вопрос: А причем здесь Python? Неужели так надоела Java?.
Чтоб ответить на вторую часть комментария, нужно определить критерии, по которым одних разработчиков можно отнести к суровым, а других нет. Если суровость — это мера, которая показывает, на сколько долго человек работает с определенным инструментом, то тогда, возможно:
— со временем просто надоедает возиться с одним и тем же, и начинаешь покорять новые вершины
— с опытом приходит понимание того, что другой инструмент (Java, Python, Groovy и др.) умеет делать что-то лучше, быстрей (из коробки, или же с помощью дополнительных фреймворков или библиотек), чем текущий
Я считаю, что выбор инструмента может быть оправдан только контекстом и задачей, а не какой-то обобщенной тенденцией.

Есть мнение, и не только мое, что на jvm все лучше, больше и продуктивнее чем на пистоне, и нового тоже хватает.

Хочу еще добавить, что в названии топика фигурирует Prom.UA, а не любой другой подобный ресурс, потому, как я таким образом выражаю свое уважение ко всем ребятам, с которыми работаю в этой компании и к продукту, над которым мы вместе трудимся.
То, что описано в этой статье — это исключительно мой личный опыт и мой личный интерес, которыми я поделилась с сообществом. Это решение не интегрировано в текущую инфраструктуру, и скорей всего не будет в обозримом будущем по причине того, что на данный момент мы счастливы и с Python.

Это решение не интегрировано в текущую инфраструктуру, и скорей всего не будет в обозримом будущем
в названии топика фигурирует Prom.UA, а не любой другой подобный ресурс, потому, как я таким образом выражаю свое уважение
Тогда переименуйте топик из
«Автоматизация тестирования Prom.UA на примере Java и JBehave»
в
«Пример сетапа JBehave для УИ тестирования имени Пром.УА».
.
на данный момент мы счастливы и с Python
А про то как в реальности тестируетсо Уи в Пром.УА рассказ будет? (Эт не троллинг, мне честно интересно)

Спасибо, Богдан, за Ваш юмор по поводу нового названия топика. Немного юмора всегда приветствуется :-)
Спасибо также за интерес к нашей компании. Как будет время и вдохновение, то конечно опишу это в отдельной статье с примерами, либо кто-то другой из нашей компании это сделает раньше.

думаю пригодятся ссылки на полезные ресурсы! Благодарю) написала вам личное сообщение. делала нечто похожее на тестинге порталов знакомств)

Тут многие тестировали порталы знакомств)))

Респект! Жаль, что нельзя добавить статью в фавориты...

Сейчас доступно довольно много сервисов для «добавления статей в фавориты», например delicious.com

Здравствуйте Ирина, замечательная статья. А не хотите ли разместить ее на automated-testing.info ?

Спасибо, я разместила ссылкой на эту статью.

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

тестирование бизнес-требований, которые описаны в виде пользовательских историй (user stories)

А можно примерчик бизнес требования? Интересно взглянуть.

Прочитать о том, что собой представляют бизнес требования можно здесь:
The Foundation of Good Requirements: Business Rules and Business Requirements
В моем примере они выглядят следующим образом: Prom.UA пример

Ссылочки устарели. Можете обновить, плиз?

при всём блеске и широте подхода, респекте и одобрении,
хочу заметить, что умные оч умелые ручки тестировщика Никакое автотестирование не заменит.
автотестирование обходится дороже чем мануальное, при этом оно редко приносит в качестве улова хитрые функциональные баги.
Хочу пожелать автору успешного движения в сторону традиционной разработки.
upd: также, хочу добавить, что навыки дизайна, тестирования и документирования — это подмножество навыков разрабочика.
Хотя, на практике множество экземпляров живут без них.

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

Автоматизированное тестирование никаким образом не призвано свести на нет мануальных тестировщиков
это правда.
необходимое количество мануальных тестировщиков пропорционально темпу разработки, и почти не зависит от наличия Юнит-тестов, функциональных тестов, автотестинга, от количества и зарплат менеджмента тоже не зависит.
.
я занимался и авто и ручным тестингом когда-то.
автотестинг ваял скрипты, фиксил их же, снова ваял
а мануальщики искали баги.
система большая, жирная.
заказчик мог себе позволить любые няшки.
по базам созданных дефектов (за годы) отчётливо виднелась тенденция:
серьёзных багов эта шняга находила очень мало.
хотя в автотестинге работали, трудились, кодили.
у меня тогда возникли сомнения:
а что даёт это автотестирование?
— показывает что в системе нету багов?-так нет же- там их толпы, мне просто говорили каких и где надо наловить ручками.
— находит баги?-так нет же- багов ловят теми же ручками в нужных модулях и в нужных количествах, а потом мануальщики идут кто Джаву учить а кто котиков лайкать. Зарплата-же не позволяет им работать много.
.
автотестеры зарабатывали на уровне сеньёр QA или мидл девелопера, недёшево так обходится эта радость.
.
в любом случае, на тестировании сэкономить нереально,
т.к. команды тестировщиков создают экспертную базу без которой разработчикам очень сложно и возникает эффект т.н. НЁХ.

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

и Вы на меня не обижайтесь.
мне хотелось донести то, что я понял работая в тестировании.

серьёзных багов эта шняга находила очень мало.
Эм... чем мне всегда нравилось работать с компьютерами — они всегда однозначны. Т.е. они делают ровно то, что ты им скажешь. КмК, из этого наблюдения следует очевидный вывод, что если программа делает мало — например, находит мало багов — то это не потому что программа сама по себе плохая и не надо ее писать, а потому, что программа просто так написана. Где-то так.

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

поиск проблем (ака) багов — процесс твоческий.
пока что программы не умеют работать творчески.
Очень смешно такое читать, особенно как коммент к теме где ТС описывает как начать писать эти самые программы которые ищут баги :)
быстро и неутомимо — да, но чутья и наблюдательности у них нет.
При желании ее можно добавить, особенно в УИ-тесты, но будет большое количество ложных срабатываний (что так же часто происходит и с «наблюдательными» тестерами). Второй момент что наблюдательность (именно наблюдательность, а не придирчивость) есть далеко не у всех тестеров.
Если речь о «серьезных багах», то это те которые заденут или много пользователей, или важных пользователей. А это ограниченное количество сценариев и оно покрывается авто-тестами очень хорошо. (Другое дело что писать все эти тесты впадло, путь лучше тестировшики проклацают.)
.
Надо отличать «реальные проблемы» и «сказочные баги». Первое — это реальные сценарии пользователя, второе — это заковыристые баги с мытным путем воспроизведения, которые реальный пользователь вряд ли найдет. Программы без багов быть не может, вопрос в __вероятности__ проявления ошибки.
.
А хорошим тестерам надо платить хорошо, чтобы они соответственно работали.
1) Тестерам не надо платить много, ибо они это расходный материал. КуА надо платить много, ибо это интеллектуальная работа, которая позволяет оптимизировать процесс создания продукта. От только фишка в том что «клацанье мышкой» — это самая малая часть работы КуА (и при том не всегда часть). И таки да, КуА машиной заменить пока проблематично.
2) По данным ДОУ средняя ЗП КуА (а по факту тех самых тестров) в Киеве 1300 багзов (10+К грн) и синьор — 2250 (18+К грн). Это в разы больше чем в среднем по стране у других специальностей. Этих сумм вполне хватает для того чтобы жить хорошо. Да-да всегда хочетсо больше и тд, но суть не в этом. Суть в том что тестировщикам уже хорошо платят и если платить в 2 раза больше лучше работать они не будут. Потому что в КуА идет много «случайных людей», тех самых которые знают что в ИТ большие ЗП, но в других ИТ-специализациях порог входа выше. А «случайному человеку» сколько ЗП не поднимай, работать лучше он не будет, просто вместо того чтобы весь год мечтать про поездку в Турцию, он будет мечтать про поездку в более дорогое место.

мнение специалиста детектед))
сколько лет ты проработал в QA?

Спасибо, статья просто блеск!

Вот так должно выглядеть резюме специалиста!

Да, очень хорошее CV. Если бы я придирался, то совсем немного и скорее к деталям стиля.

Спасибо. Жаль, конечно, что выглядит это как резюме, так как написать статью хотелось в формате experience sharing’а. Если появится время, и придет в голову какая-либо интересная идея, которой также захочется поделиться, то постараюсь лучше

это комплимент невероятного уровня.
Жалеть не стоит. Топик — класс.

Это действительно немного иной формат. Однако writing skills очень ок)

написано очень хорошо.
технично.

Если это не секретная информация, то не могли бы Вы привести некоторые «цифры» или хотя бы их порядок:
* какое количество\процент из всех возможных user stories, актуальных для Prom.UA, было реализовано?
* интегрировано ли данное решение уже сейчас в реальный процес разработки Prom.UA?
* Вы упомянули о Selenium-Grid, в контексте данного решения, пробовали ли Вы все это дело распараллелить? если да, то каков был прирост производительности?
* средение время прогонки всех тестов?
* какие были параметры вычислетельной системы cpu, memory, ..., на которой было развернуто решение?
* во время тестирования использовалась копия DB с production или какая-то её «урезанная» версия?
Спасибо.

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

Задавать вопросы типа почему не Cucumber (с каким нибудь watir) / Cucumber-JVM или решение на node.js (и какие рассматривали) имеет смысл?
Или остановимся на том что я вас похвалю за техническую статью то что статья не про ХРов или ЗП?
.
P.S. Админы, от такое можно было бы и в Ленте опубликовать, а то от нее (Ленты) как-то не особо пользы.

Спасибо за Ваш комментарий, потому, как я вижу, что Вы внимательно прочли мою статью.
Комментарии приветствуются любые, которые каким-либо образом связаны с темой топика, раскрывая ее лучше.
Сравнений между решениями JBehave vs Cucumber JVM и др. я не проводила. Отталкивалась от того, каким спросом в интернете пользуются различные BDD решения, такие как JBehave, Cucumber JVM и др. Сначала опрашивала google на предмет таких решений, а потом проводила сравнение характеристик спроса по ним с помощью инструмента google: www.google.co.uk/... JVM&cmpt=q . После чего рассматривала наиболее популярный фреймворк на предмет следующий качеств: работа с maven, документирование, лицензия, исходный код, стиль использования, выходной формат отчетов и др., после чего сделала вывод, что этот инструмент гармонично вписывается в архитектуру моего проекта.
Как мне кажется, такой подход оправдан, прежде всего, тем, что он позволяет, в первую очередь, найти решение, с которым, в дальнейшем, не столкнешься с плохой поддержкой. Другими словами, вероятность найти решение своей проблемы по популярному фреймворку выше, чем по любому другому, что, в конечном счете, сказывается на времени покрытия системы автоматическими тестами.
Сравнительные же характеристики этих двух решений описаны хорошо в статье по ссылке: mkolisnyk.blogspot.com/...comparison.html

P.S. Админы, от такое можно было бы и в Ленте опубликовать, а то от нее (Ленты) как-то не особо пользы.

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

Лента надеюсь в этом году станет еще полезнее чем в предыдущем :)
1) Слово «еще» было лишнее :)
2) Будем надятсо что станет, а не загнетсо как «отзывы про компании»

За 2013-й Лента выросла на 0.6% — немного, но выросла же :) А с новым редактором думаю вырастет на десятки процентов.

Форум мне нравится не столько как флудогенератор, но и как «народная Лента», где почти весь контент генерируется сообществом и часто видно много позитива — начиная от улучшающегося storytelling’а в текстах топиков и заканчивая примерами самоорганизации типа dou.ua/...ums/topic/8624

Если рассматривать «отзывы про компании» в широком смысле, то есть учитывая рейтинг компаний, то получится такая картинка:
i.imgur.com/HcGrGyL.png — оно как-то с переменным успехом растет.

можно было бы и в Ленте опубликовать, а то от нее (Ленты) как-то не особо пользы.
в ленте комментов обычно очень мало, по понятным причинам.

не читал, но одобряю, техническая статья на доу это что-то из ряда вон выходящее! Может, в этом году это войдёт в добрую традицию?

Для технических статей есть свои ресурсы. Зачем их размещать на ДОУ.

Для технических статей есть свои ресурсы. Зачем их размещать на ДОУ.
Для того чтобы высказывать дурацкие мысли есть свои ресурсы. Но вы же зачем-то оставили свой коммент на ДОУ.

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

Я не против технических статей на ДОУ и оставил свой комментарий не к статье, а ответом на другой комментарий. Потому что немного надоело, что люди под каждой такой статьей пишут, что вот как тут не хватает тех.статьей. Как будто они тут должны быть и это единственный возможный источник информации.
Хотя честно написали, что даже не читают.

c другой стороны, греховно-же не набросить в хороший топик.
а троллей покормить? а помериться?
без этого тема просто утонет в глубинах форума.

Очевидно, что доу занял место такой себе «курилки», где люди могут на пару минут переключитсья с работы, отдохнуть, высказать свои «дурацкие» мысли.
Для этого есть Offtopic rsdn.ru или всякие фейсбучики.
Че __вы__ на ДОУ забыли? Идите на профильные ресурсы!
Хотя честно написали, что даже не читают.
__Кто-то__ написаЛ, что __он__ не читаЛ.
Я, например, прочитал.

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

Согласен с Кириллом. Рубрика для технических или статей с научной составляющей очень востребована.

Подписаться на комментарии