Home

Запись доклада Игоря Хрола на онлайн-конференции Auto ConfeT&QA.

Часто возникают задачи, когда нельзя манипулировать пользовательским интерфейсом тестируемых приложений «изнутри». Это может быть Flash или созданные на основе закрытых библиотек Win-приложения. Ну или если автоматизация тестирования идёт отдельным сервисом и заказчик не может предоставить исходный код для тестирования, в который можно внедриться. Типичные варианты решения данной проблемы могут быть следующие:

• Отказаться от автоматизации через UI
• Искать инструменты, которые поддерживают данный конкретный пользовательский интерфейс

В своём докладе я рассмотрю еще один вариант обхода данной проблемы: рассматривать UI как набор изображений и манипулировать им на основе предопределённых шаблонов.
Наиболее известным инструментом, который работает на этих принципах, является Sikuli. Разработанный в MIT, Sikuli на данный момент является практически единственным бесплатным вариантом работы с UI на основе изображений. Подход является новым веянием в автоматизации тестирования и обладает весьма специфическими особенностями: как достоинствами, так и недостатками, которые надо учитывать, если Вы выбираете Sikuli в качестве инструмента для автоматизации тестирования.

Не секрет, что многие "ручные" тестировщики хотят стать "автоматизаторами". И когда человек осознаёт в себе это желание, у него естественно возникает вопрос "с чего начать", такие темы достаточно регулярно возникают на нашем форуме.

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

1. "Сначала освою автоматизацию тестирования, а потом перейду в разработку".

Весьма распространённый мотив, но тут всё просто с ответом на вопрос "с чего начать": хочешь идти в разработку -- учись программировать!

2. "Хочу расширить кругозор, новые умения не помешают".

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

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

3. "Хочу избавиться от рутинных задач, автоматизировав их".

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

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

Если Вы хотите неспешно научиться программировать -- мы приглашаем Вас на онлайн-тренинг "Программирование для тестировщиков", который начинается 16 мая.

А если нужна несложная автоматизация, но быстро -- тогда добро пожаловать на тренинг "Selenium 2.0: стартовый уровень", начало 12 мая.

Ну а с другими тренингами по тестированию ПО можно познакомиться в нашем расписании.

Запись доклада Ольги Киселевой на конференции Auto ConfeT&QA, осень 2012 года.

Как часто в вашей работе приходиться выполнять рутинные задачи для того, чтобы перейти «к самому главному»? Заполнять одну форму для того, чтобы протестировать следующую за ней…

Как это делать? Руками? «Я пишу 3000 знаков в минуту! Но такая ерунда получается…» Конечно, это вариант, но гораздо приятнее ведь видеть реальные данные, а не «лыпдкурп». А иногда даже полезнее.

Каждый раз заносить руками нормальные данные? Долго и нудно :( И тут нам на помощь приходят… роботы!

Есть и готовые решения, но я расскажу о том, как с помощью Watin написать своего собственного робота для web-формы.

Доклад Алексея Лупана с онлайн-конференции ConfeT&QA Online 2011

Доклад про то, что тестировщикам следует автоматизровать процесс тестирования вообще, а не отдельные тест-кейсы.Толкование: «Падающее на Землю тело увеличивает свою скорость примерно на 9,8 м/с каждую секунду».

Я расскажу в нескольких примерах о том, как грамотная автоматизация «в мелочах» помогает тестировщику двигать процесс тестирования.

На экране будут:

• слайды,
• роботехника в действии,
• сформулированные призывы к определенным ментальным состояниям.

Автор: Алексей Баранцев

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

Но есть некоторые «фичи», которых в Selenium нет и скорее всего не будет. Среди них: загрузка файлов с сервера, работа с сайтами, требующими авторизации, проверка кодов ответа на HTTP-запросы. Их не планируется добавлять в Selenium, потому что более правильным способом их реализации является использование вспомогательного прокси-сервера, работающего в связке с Selenium. Наиболее подходящим для этой цели является BrowserMobProxy, который в своё время «отпочковался» от Selenium и стал самостоятельным продуктом.

Под катом ещё один доклад с конференции ConfeT&QA, в котором рассказывается о том, как при помощи связки Selenium и BrowserMobProxy реализовать вышеупомянутые «фичи». Ссылка на проект с кодом примеров на гитхабе прилагается.

Автор: Алексей Баранцев

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

Осенью 2013 года я дважды на конференциях (сначала SECR, потом ConfeT&QA) рассказывал о том, как происходило развитие инструмента Selenium и каково текущее состояние дел. Предлагаю вашему вниманию запись, сделанную на второй из упомянутых конференций.

Выступление Геннадия Алпаева на онлайн-конференции для тестировщиков ConfeT&QA, 2011 год.

Об авторе: Занимается автоматизацией тестирования 8 лет, является автором и соавтором ресурсов по TestComplete, SilkTest, Automation Testing Group, член команды Team AQA, один из самых активных участников ветки нашего форума, посвященной инструменту. Скоро стартует его полностью обновленный тренинг TestComplete для начинающих

TestComplete.TestComplete, пожалуй, является одним из наиболее популярных инструментов тестирования на территории экс-СССР. Почему он получил такое широкое распространение?

3 главных аргумента:

• поддерживаемые технологии
• стоимость
• поддержка

7 неглавных аргументов:

• - XML-лог и экспорт лога
• - языки программирования
• - поддержка сторонних компонентов
• - разнообразие структуры приложения
• - интеграция через OLE
• - нагрузочное тестирование WEB
• - SDK и Extensions

И, наконец, «Разное»: системы контроля версий, разнообразие встроенных функций, широкие возможности работы с графикой, скриншоты каждого шага, распознавание текста (OCR), распределенное тестирование, NameMapping/Aliases, TestRecorder, подробная документация, куча настроек для удобства работы.

На конференции Selen ConfeT&QA мы решили заполнить паузы между докладами короткими дополнительными мини-выступлениями, которые не были анонсированы в программе. И поскольку они не являются "официальной" частью конференции, мы будем их сразу же публиковать. Автор всех мини-рассказов -- Алексей Баранцев.

Доклад № 3: Источники информации о Selenium

Как обычно после очередной онлайн-конференции серии ConfeT&QA мы публикуем лучший доклад.

Сегодня мы опубликуем в открытом доступе доклад Андрея Солнцева (http://ru.selenide.org, http://asolntsev.livejournal.com, https://twitter.com/asolntsev) “Selenide: лаконичные и стабильные UI тесты на Java”который по результатам зрительского голосования занял первое место на прошедшей онлайн-конференции для специалистов по использованию инструмента Selenium для автоматизации тестирования веб-приложений Selen ConfeT&QA.

Написание UI-тестов – нетривиальная задача. Настолько нетривиальная, что тестировщиков стали даже разделять на касты автоматизаторов и мануальщиков, а разработчики даже и мысли такой не допускают, чтобы самим писать тесты. Нестабильность, таймауты, ajax, бесконечная поддержка – вот что снится автоматизаторам в кошмарных снах. UI-тесты как тамагочи: требуют постоянного внимания. Тем более поразительно, что большинство существующих фреймворков для тестирования не пытаются решить этих – настоящих! – проблем, концентрируясь на красивых отчётах и BDD.

Я хочу рассказать про библиотеку Selenide, позволяющую писать лаконичные тесты и решающую большинство проблем типа таймаутов простым и элегантным способом. С Selenide вам больше не нужно заботиться о браузере, таймаутах, ajax и StaleElementException. Можете сконцентрироваться на бизнес-логике!

Как сказал один мой знакомый, теперь даже мануальщики могут писать тесты.

Автор: Геннадий Алпаев (автор единственного русскоязычного учебника по TestComplete и ведущий тренинга Автоматизация тестов с использованием TestComplete)

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

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