На конференции 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)

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

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

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

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

Начнем с более общего вопроса.

Автор: Компания SnowHall Ltd

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

У нас уже был опыт тестирования проектов с помощью PHPUnit, поэтому к тестированию мы относились более чем положительно. Но в данном случае, помимо покрытия тестами кода, важно было определить степень завершенности проекта. Да, безусловно, заказчик предоставил нам техническое задание, в котором указал нереализованные модули, но он также сказал добавить недостающую функциональность в уже имеющиеся модули. Поэтому в данном случае сперва нам было необходимо определить, какие модули нуждаются в доработке. На помощь нам пришло Acceptance testing.

Так как времени у нас было относительно немного, то нужна была система для тестирования, несложная в освоении, простая в использовании и по-возможности не требовательная к ресурсам. После беглого обзора существующих систем я выделил следующих кандидатов:

Геннадий Алпаев, автора единственного русскоязычного учебника по TestComplete и автор тренинга Автоматизация тестов с использованием TestComplete, очередной набор которого начнет работу 19 июля.

TestComplete дает возможность создавать тесты, используя несколько языков программирования, и новичку обычно нелегко сделать выбор в пользу того или иного языка. В этой статье я постараюсь максимально подробно рассмотреть этот вопрос, а также ответить на часто задаваемый вопрос «какой язык выбрать?».

Выбор языка

Выбрать язык для нового проекта необходимо в момент создания проекта.

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

Сегодня мы опубликуем в открытом доступе доклад Игоря Хрола “Можно ли перевернуть пирамиду?” – автоматизируем тестирование с меньшим числом посредников”, который был признан лучшим на прошедшей онлайн-конференции для для специалистов по автоматизации тестирования Auto ConfeT&QA.

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

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

Публикация от Андрея Дзыни, автора тренинга Автоматизация тестирования Android приложений

Не так давно вышел релиз новой версии Robotium 4.0, который стал знаменательным в истории этого инструмента. До недавнего времени, автоматизировать тестирование компонента WebView(отображающего Web страницу внутри Native Android приложения) было возможно лишь при помощи кликов по координатам.

solo.clickOnScreen(float x, float y)

Или же посредством подключения расширения ExtSolo от компании Bitbar.

После выхода Robotium 4.0 надобность в подобного-рода хаках отпадает. Появилась возможность работать с Web элементами напрямую через объект Solo, да и еще посредством использования класса By, для формирования локатора в стиле WebDriver API

Примеры доступных команд:

clickOnWebElement(By by)

enterTextInWebElement(By by, java.lang.String text)

getCurrentWebElements(By by)

getWebElement(By by, int index)

typeTextInWebElement(By by, java.lang.String text)

waitForWebElement(By by)

Полный список команд и их описания можно посмотреть в JavaDoc API

https://robotium.googlecode.com/files/robotium-solo-4.1-javadoc.jar

Выступление Андрея Дзыни с конференции UA Mobile

Мир мобильных телефонов очень сильно изменил нашу жизнь. В наше время невозможно представить современного человека, без этого чудо устройства. На рынке появляется все больше устройств и приложений. И чтобы удобнее пользоваться этими приложениями пользователи выбирают “умные” телефоны, или как их еще принято называть смартфоны. В этом докладе Андрей Дзыня, автор тренинга Автоматизация тестирования Android приложений хочет поделиться своим опытом автоматизации приложений под Android и iOS. Он расскажет о том, какие инструменты автоматизации он использовал. Поговорит о недостатках этих инструментов и какие из них стоит использовать у себя на проекте.

Автор: Киселева Ольга

Начнем с основ - что вообще такое робот и зачем он нужен?

Робот - это приложение, которое выполняет какую-то работу за нас. Но не всю - он делает маленький кусочек, а остальное проверяет тестировщик вручную. Такая полуавтоматизация.

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

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

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

Создаем карточку раз, создаем карточку два, создаем карточку три... создаем карточку одна тысяча сто восемьдесят шесть... И каждый раз заполняем одни и те же поля. И вот здесь нам и поможет наш робот - заполняем карточку один раз, пока пишем программу, а потом робот это делает за нас! Заманчиво, не правда ли? А ведь это еще и легко осуществимо!

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

Сегодня я хочу показать возможности инструмента Watin, добавив его в вашу копилку знаний.