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

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

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

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

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

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

Расскажу о том:

Какие выводы сделала из своего негативного опыта.
Каких типов заказчика следует избегать, если вы занимаетесь аутсорсом тестирования, и автоматизацией в том числе.
Какие тестовые задания по автоматизации не стОит делать, если вы тестер-фрилансер.
И самое главное, исходя из своего личного опыта, я расскажу, как объяснить заказчику/менеджеру/программисту, что автоматизация тестирования – это «не наш путь».

Когда тестировщики сталкиваются с задачами автоматизации тестирования перед ними встает вопрос, какой язык для этого выбрать? В своем докладе я расскажу о языке Groovy, который обладает мощью и кроссплатформенностью языка Java, но при этом гораздо легче в освоении, а программы на нем имеют более компактный и читабельный код. В докладе будут рассмотрены следующие примеры:
1. Поиск и замена текстов с помощью регулярных выражений.
2. Парсинг логов с помощью готовых классов Java (например, HashMap).
3. Как с помощью Groovy использовать более знакомые тестировщикам инструменты, такие, как Selenium и JMeter.
4. Как с помощью Groovy написать простой web сервер и протестировать такие вещи, как HTTP REST API на уровне основных запросов (Create, Read, Update, Delete).

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

Сценарий Сложение двух чисел на калькуляторе
Допустим Складываем числа 2 и 3 на калькуляторе
Если Выполняем операцию сложения
То На экране отображается результат 5

и самое главное, как их автоматизировать с использованием SpecFlow + C# + NUnit для .Net.

Что нам надо делать когда нужно автоматизировать веб-приложения? Просто гуглим и находим нужную информацию. А когда нужно автоматизировать что-то необычное? Например, Windows приложение с самописными контролами и объектами. Сразу приходят в голову страшные слова как QTP или TestComplete. Но даже эти инструменты не всегда справляются с задачей расспознавания объектов. И что тогда? Не делать автоматизацию?!

Sikuli – это универсальный инструмент, который должен быть в арсенале каждого автоматизатора. В своем докладе я покажу, на практическом примере, как выполнить автоматизацию, даже если ее нельзя выполнить обычными инструментами (QTP, TestComplete, Selenium, и т.д.).

Работа с инструментом будет продемонстрирована в реальном времени в прямом эфире.

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

Поэтому все начинают строить свои «фреймворки» на базе Selenium/WebDriver. Это достаточно непростая задача. Ведь нужно продумать гибкую архитектуру, позаботиться о простоте написания и поддержки тестов, решить вопрос отчетов и хранения данных. Тут очень легко ошибиться, особенно с ограниченными знаниями языков программирования.

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

Automated Testing Dojo это уникальный формат, где можно посоревноваться с коллегами автоматизаторами и программистами в написании приемочных тестов на WebDriver.

Мы разработали этот формат специально для тестировщиков автоматизаторов. Это не простое соревнование, а соревнование со смайликом, в котором каждый участник получает помимо прочего хорошую порцию fun’a. Множество позитивных отзывов участников, собранных за 5 последних встреч, свидетельствуют о том, что раскопки нами ведутся в правильном направлении.

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

За 20 минут доклада, вы решите для себя – хочу ли я принять участие в следующей at dojo встрече, вероятно вдохновитесь на создание своего dojo-framework’а и просто весело проведете время.

Каждая из двух предыдущих автоконфеток содержала доклады про протоколирование (логирование). Не будет исключением и третья.

Я расскажу, как запротоколировать выполнение тестов, разработанных с использованием инструмента Selenium, фреймворка TestNG и языка программирования Java.

Я не буду рассказывать о том, как сделать красивый отчёт о выполнении тестов.

Мой рассказ будет посвящен тому, как информацию собрать. Я считаю, что отчёт должен быть простым и коротким, потому что если тесты прошли успешно, детали их выполнения мало кого интересуют. Но если «тест упал» – приходит Специалист, чтобы решать Проблему, и он должен получить максимально полную информацию о том, что происходило. Поэтому основная задача протоколирования – сбор и сохранение информации.

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

Вместо этого я покажу, как выжать максимум из того, что уже имеется в Selenium и TestNG. Разные библиотеки используют разные фреймворки протоколирования, я расскажу, как всё это перенаправить в единый фреймворк-фасад slf4j и при помощи фреймворка протоколирования logback сохранить всё в базу данных. При этом будут рассмотрены разные варианты запуска тестов – локально, удалённо, с использованием Selenium Grid, а также запуск тестов в облаках с использованием сервиса SauceLabs.

Я уверен в том, что многие из нас, тестировщиков-автоматизаторов, прикладывают огромные усилия для того, чтобы результате тестового прогона создавался красивый, понятный и читабельный отчет. Чтобы был не просто голый call-stack c “NoSuchElementException”, а чтобы было ясно, что делал тесткейс и на каком шаге он упал, чтобы были картинки и видео, чтобы было просто приятно его читать и не стыдно другим показать.
+
Пусть наши коллеги из мира Java продолжают настраивать Jenkins и писать собственные парсеры для логов JUnit. А в мире .NET, есть замечательные бесплатные инструменты – MbUnit, Gallio Icarus, BDDfy – которые помогут сделать из Вашей автоматизации – кон-фЭтку!

Разработка веб-сайтов на PHP – это норма. А вот тестирование PHP веб-сайтов, к сожалению, нет. Я разработал инструмент, который позволяет соединять все лучшие фреймворки для тестирования PHP веб-приложений. В своем докладе я покажу, как работать с новым инструментом Сodeception и покажу на практике:

- установку Codeception
- описание сценариев поведения
- тестирования без javascript через PhpBrowser
- тестирование с javascript через Selenium
- использование CSS-селекторов и XPath локаторов
- проверка и очистка данных в БД