Home

Запись доклада Алексея Баранцева на июньской встрече клуба тестировщиков в Москве.

Если почитать какую-нибудь книжку про разработку автотестов или просто погуглить по словам "successful test automation" -- можно найти множество разнообразных рекомендаций. Выбирайте правильно инструмент. Проектируйте и выстраивайте правильную архитектуру тестов. Уделяйте внимание тому, чтобы тесты было легко поддерживать. Не забывайте про планирование и управление (вообще-то это надо было бы поставить первым пунктом).

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

Что же делать?

Вы когда-нибудь выращивали цветы? Комнатные, или на клумбе, или может быть даже не цветы, а кусты или деревья?

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

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

Однако есть и другой путь -- "органический". Сначала посадить один цветочек. Если не приживётся -- посадить другой. Когда вы увидите, что он хорошо себя чувствует -- посадить побольше таких цветов. Оформить красиво клумбу. Подсадить что-нибудь ещё. Разбить рядом вторую клумбу, с другими цветами. Потом что-нибудь куда-нибудь пересадить, а что-нибудь вообще перестать сажать, потому что не понравились. И так постепенно создать ничуть не менее красивый, а может даже более уютный парк. Где нет прямых, как стрела дорожек, но всё равно достигнута гармония.

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

Публикуем подборку докладов с SQA Days-17, посвященных автоматизации тестирования.

Доклад Николая Абалова, специалиста по автоматизации тестирования в 2GIS, на конференции CodeFest 2015.

Для автоматизации тестирования под Windows Phone и Windows отсутствуют удобные и открытые инструменты, которые можно было бы легко адаптировать под свои нужды. Основные существующие инструменты закрыты, ограничены и предлагают свой подход, отличающийся от таких общепринятых стандартов как, например, Selenium WebDriver. В докладе я расскажу про opensource решения для автоматизации UI тестирования под Windows и Windows Phone, разрабатываемые в нашей компании, что они умеют и к чему мы стремимся.
Windows Phone

Доклад Игоря Хрола, руководителя группы автоматизации тестирования, Wargaming на конференции CodeFest 2015.

Устали видеть копипастинг между тест-кейсами и автотестами?

Хотите иметь чётко отделённую бизнес-логику в ваших тестах, но при этом не учить новых нотаций по написанию кода, как в BDD?

У вас есть инженеры по тестированию, которые хотят участвовать в написании автотестов, но пока не очень хорошо умеют программировать?

Если вы ответили «да» хотя бы на один из вопросов, то моя презентация будет вам полезна. Речь пойдёт о новой библиотеке для Python, которая может улучшить ваши тесты — Grail. Она трансформирует ваши методы и функции в шаги, из которых можно строить автотесты. Grail имеет открытый исходный код и доступен каждому: https://github.com/wgnet/grail.

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

Один из самых популярных вопросов про тестовые фреймворки типа JUnit, TestNG, NUnit  -- как задать порядок выполнения тестов. В курсе "Эффективное использование JUnit и TestNG" у нас есть модуль, посвящённый этой теме. И мы включаем этот модуль почти во все наши тренинги в качестве дополнительного материала. А теперь вообще решили опубликовать в открытом доступе.

В этом фрагменте рассказывается про самую-самую основную аннотацию @Test, которая используется в тестовом фреймворке TestNG для того, чтобы помечать методы, которые должны считаться тестовыми.

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

Во время тренинга "Эффективное использование JUnit и TestNG" у участников возник вопрос -- как "правильно" организовывать конфигурационное тестирование, то есть запуск автотестов в разных браузерах (в том числе с разными настройками), на разных тестовых стендах, удалённо либо локально. При разработке тестов на языке программирования Java с использованием сборщика Maven это реализуется с помощью так называемых "профилей", вот как это делается:

Запись доклада Игоря Хрола на онлайн-конференции 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-формы.