Последнее время область мобильных приложений становится все популярнее. Чего только стоит приложение Angry Birds, количество загрузок которого уже давно превысило цифру в 10 миллионов!

Существует 3 основных типа Android приложений:
— Native
— Web
— Hybrid

За 20 минут я успею показать, как автоматизировать Native Android приложения при помощи инструмента Robotium, так чтобы голова не болела.

Каждый уважающий себя автоматизатор стремится к совершенству. Есть две повторяющиеся строчки — надо сделать общий метод. Есть некоторые методы которые выполняют одну и ту же функцию, значит, надо определить абстрактный класс и вынести туда общий метод.

При подготовке фреймворка автоматизации таких моментов очень много, и чтобы все быстро и шустро работало, а также выглядело элегантно и красиво, и тем более лекго поддерживалось, надо где-то подсолить, а где-то подперчить. Есть очень много примеров релизации фреймворков для автоматизации веб приложений на Selenium c помощью Java, а вот на Python не так много. Я поделюсь своим опытом разработки фреймворка на Python, так чтобы фреймворк выглядел вкусным и аппетитным!

Автоматизация тестирования — это стратегическая задача. Она требует 1) наличия специальных людей, обладающих особыми навыками, 2) инвестиций времени и средств, особенно на начальных этапах, 3) изменений в общем процессе тестирования — в подходах к проектированию тестов, в распределении времени тестировщиков. Более того, отдельная “стратегия автоматизации” — это нонсенс. Внедрение автоматизации приводит к изменениям в ручном тестировании, поэтому статегия должна быть общей, учитывающей все виды тестирования.

Я расскажу про две типовые стратегические схемы, которые позволяют плавно внедрить автоматизированное тестирование, оставляя возможности для отхода в случае неуспеха (да-да, это очень важно!) с минимальными потерями. Первая схема имеет основной целью сокращение времени на тестирование. Вторая — увеличение тестового покрытия. А последовательное применение этих двух стратегических схем позволяет достичь одновременно обоих целей.

TestComplete является одним из лидеров рынка автоматизации. Год за годом TestComplete номинируется на звание лучшего инструмента в области автоматизации тестирования. Всё больше компаний отказываются от дорогостоящих инструментов, которые навязывают проприетарный синтаксис, и переходят на лёгкий и гибкий TestComplete, который поддерживает 5 основных скриптовых языков. Практически в каждом проекте (как веб, так и стендэлон приложения), где используется этот инструмент, тестировщики и автоматизаторы сталкиваются с одними и теми же проблемами, и тратят время на изобретение нового универсального подхода. Но на самом деле всё уже давно изобретено и проверено!

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

TDD (Test Driven Development) является популярным подходом среди разработчиков. Сначала пишется тест, а только потом на основании этого теста пишется реализация. Эта практика дает много преимуществ, позволяя сосредоточиться на небольшом аспекте функциональности и автоматизировать проверку правильности его реализации. Таким образом, разработчик сразу думает о вариантах использования и реализует минимальный необходимый функционал.

TDD можно применять не только на уровне модульных тестов, но и на уровне функционального тестирования. Это дает возможность задуматься о структуре и особенностях функциональности еще до ее реализации. Вам не придется мучиться в попытках протестировать приложение, которое не задумывалось для тестирования (сложные локаторы, непонятная структура страниц, запутанные связки элементов). В качестве сопутствующего эффекта, TDD позволяет сократить время на ручную проверку разработчикам и автоматизировать 100% функциональных тестов.

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

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

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

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

Никогда не автоматизировали и боитесь начинать? Не понимаете языков программирования? Не владеете английским?

Вы не можете понять код, записанный с помощью кнопочки record?
Хотите, чтобы тест был не “сломай-глаза”, а нагляден и понятен любому? Например, такой:

формочка
  .Открыть
  .НайтиОбъект
  .ПерейтиНаОбъект
  .ВвестиФигню
  .ЕстьСообщениеОбОшибке
  .Закрыть

Это возможно! На примере Visual Studio 2010 + Watin + NUnit + ReSharper и c использованием языка C# я покажу вам, что такие тесты… работают!

Visual Studio – интегрированная среда разработки с широким набором средств для создания приложений. Многие компании успешно пользуются данным продуктом для создания программного обеспечения.

Но не все знают, что можно создать полноценное решение для автоматизации тестирования на проекте c Visual Studio, используя CodedUI как инструмент создания (записи) тестов и Microsoft Test Manager как инструмент для управления и контроля выполнения автоматичеких тестов. Интеграция этих инструментов на платформе Team Foundation Server в полной мере решает большинство задач автоматизации тестирования.

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

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

1. Промежуточный формат результатов тестирования Log4J/JAXB
2. Представление результатов XSLT/HTML
– уровни представлений (разработчик тестов, тестировщик, менеджер)
3. Хранилище результатов MySQL/Tomcat
– фильтрация результатов;
– анализ результатов;
4. Взаимодействие системы с иструментом TestNG

Вы сталкивались с проблемой, когда 40% Ваших авто тестов заблокированы парочкой известных дефектов в приложении? А Разработчики и Менеджмент ставят этой проблеме низкий приоритет, и обещают все исправить в следующем году?

А тем временем, Вы не можете писать новые тесты и доверие к результатам Вашей автоматизации стремительно падает… И выход есть!
Сделать ход конем! – Обойти проблему и разблокировать авто тесты.

Я покажу, как это можно сделать и с точки зрения процесса разработки, и кода.