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

Одной из задач Continuous Integration является автоматическое развертывание продукта в тестовой среде. Виртуализация предоставляет удобное и легко масштабируемое решение этой задачи.

Развёртывание и тестирование в среде виртуальных машин имеют свои особенности, которые необходимо учитывать для построения эффективных систем автоматизации.

Расскажу, как организована работа с виртуальными машинами на нашем проекте:
- Поддерка различных гипервизоров (KVM, ESX)
- Способы управления и начальной конфигурации виртуальных машин
- Создание независимых тестов, использование снэпшотов

и поделюсь нашим опытом создания системы автоматических тестов.

Разработка через тестирование (TDD) известна уже более 10-ти лет. Эту практику применяют десятки тысяч разработчиков. Есть масса успешных примеров, и при этом масса людей, не верящих в эффективность разработки через тестирование. Также есть заблуждение о том, что TDD заменяет работу тестировщика. При этом TDD – это всего лишь один из инструментов разработчика, решающий определенные задачи. Данный доклад является быстрым введением в TDD, который даст вам представление о нем, а также о популярных заблуждениях и мифах.

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

В этом докладе я расскажу о наиболее известных граблях, на которые может наступить тестировщик при написании автотестов, а также расскажу о некоторых ложных ожиданиях относительно автоматизации тестирования.

Хорошие тесты не просто говорят нам о том, работает функционал или нет. Хорошие тесты в удобной форме показывают что не работает, какие симптомы и прочую полезную информацию. Что значит в удобной? Это значит, что независимо от количества тестов 10 или 10000 вам и любому члену вашей команды просто разобраться в логах ваших тестов.

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

Когда мы говорим об автоматизации тестирования, чаще всего вспоминается Selenium, Microsoft Coded UI, QTP и другие аналогичные инструменты. Мы хотим воспроизводить действия ручного тестирования с максимальной точностью, чтобы можно было с уверенностью сказать, что тот или иной тест-скрипт повторяет какую-то часть сложившихся на проекте тестов. Когда же тестов становится чуть больше, то мы обнаруживаем, что наши тесты запускаются долго, работают нестабильно. После чего мы начинаем говорить о параллелизации, виртуализации, четырёхслойной архитектуре фреймворка и прочих жутко интересных вещах… Это всё очень хорошо, но главная цель где-то остаётся в стороне – контроль качества нашего продукта.

В своём докладе я попытаюсь слегка задать направление другой альтернативе: отойти от автотестов через пользовательский интерфейс в сторону более низкоуровневых, которые значительно быстрее и стабильнее. Если вас также волнует “переворачивание” пирамиды автоматизации тестирования, то приглашаю присоединиться к обсуждению этой сложной и важной темы.

Мобайл — молодая и стремительно развивающаяся отрасль, где лидеры и правила игры меняются с огромной скоростью. В силу молодости подходы к разработке и тестированию еще не окончательно устоялись, и имеется целый ряд препятствий, отравляющих нам жизнь. Если опытного мануального тестировщика мобильных приложений можно опознать по развитым хватательным рефлексам и мозолям на пальцах, то опытного автоматизатора мобильных приложений под iOS — по красным от слез глазам :)

Поделюсь с вами, почему автоматизация мобильных приложений — нетривиальный процесc. В частности, почему автоматизация iOS приложений — особенная пичалька :)

Расскажу:
- какие ограничения существуют у мобайла и у iOS в частности;
- какие инструменты мы исследовали;
- что выбрали;
- «по пацански» ли использовать screenshot-based средства;
- как мы скомбинировали screenshot-based c «традиционными» инструментами автоматизации;
- к чему пришли и куда будем двигаться дальше.

Часто к инструментам генерации кода тестов для автоматизации тестирования UI приложений относятся с некоторым пренебрежением, аргументируя это тем, что такие тесты тяжело поддерживать – и в случае изменений в UI их легче переписать.

В своем докладе я хочу показать, что генерация C# тестов в Visual Studio 2012 при помощи Coded UI достигла такого отличного уровня, когда мы можем поддерживать их, прилагая минимум усилий.

В ходе выступления я поделюсь опытом, который мы получили при создании платформы для автоматизации тестирования. Будет рассказано об основных направлениях и идеях платформы XML2Selenium

Особенности платформы:
- JavaScript и Groovy скриптинг
- ООП на уровне DSL XML
- параметризированные XML инклюды и циклы
- наборы плагинов для конкретных нужд – тестирование баз данных, Web UI, мобильные приложения, SOA
- для каждого теста мы записываем скриншоты, видео, снепшоты и отдельные логи
- платформа содержит Behaviour Driven Development плагин, и решает все задачи из области Test Management

Я расскажу:
- об особенностях создания DSL языка и о том, что как обеспечить платформе применимость в разных областях тестирования
- о том, как обеспечить плагинность, и что такое точки расширения
- об использовании платформы в процессе разработки для тестирования её собственного поведения (самотестирование)
- социальность, юнклюды и nexus репозитории
- data driven testing парадигма
- multi-instances, многопоточность
- самотестирование
- особенности Continuouos Integration при разработке своей технологии
- можно ли XML сделать объектно-ориентированным?
- и наконец, нужен ли мануальный тестировщик на платформу по автоматизации тестирования? Или о том, как мы стремимся авто-протестировать все уровни платформы :)