Автоматизация в тестировании применяется гораздо шире, чем может показаться на первый взгляд. Этим занимаются не только специально назначенные люди, у которых на бейджике (или на лице) написано "автоматизатор". В традиционно "ручном" тестировании автоматизация тоже встречается, пусть и в меньшем количестве.
Посмотрите небольшой видеоролик "Автоматизация в тестировании", записанный Алексеем Баранцевым, а потом посмотрите вокруг -- есть вероятность, что вы активно используете автоматизацию, даже не задумываясь об этом!
А если задуматься и подойти к этому осознанно, не окажется ли внезапно, что сфера применения автоматизации в вашей повседневной работе может быть расширена, иногда даже без приложения сколь-нибудь значительных усилий?
У пользователей Selenuim WebDriver нередко возникает вопрос -- почему Selenium не дожидается завершения загрузки страницы? А иногда, наоборот, пользователи жалуются, что Selenium ждёт слишком долго -- страница вроде бы уже загрузилась, но тесты дальше не хотят выполняться.
На самом деле Selenium и в том и в другом случае действует по одним и тем же правилам. У него есть формальные критерии завершения загрузки страницы, и он неукоснительно их придерживается.
Алексей Баранцев написал серию из трёх статей, в которых объясняются эти правила и способы их "настройки" под ваши требования, если вас не устраивает стандартное поведение:
Запись доклада Алексея Баранцева на июньской встрече клуба тестировщиков в Москве.
Если почитать какую-нибудь книжку про разработку автотестов или просто погуглить по словам "successful test automation" -- можно найти множество разнообразных рекомендаций. Выбирайте правильно инструмент. Проектируйте и выстраивайте правильную архитектуру тестов. Уделяйте внимание тому, чтобы тесты было легко поддерживать. Не забывайте про планирование и управление (вообще-то это надо было бы поставить первым пунктом).
Но когда вы только приступаете к созданию автотестов -- вы ещё не знаете ничего ни про инструменты (насколько хорошо они вам подойдут), ни про архитектуру, да и управлять ещё нечем. Планировать в условиях такой неопределённости тоже сложно.
Что же делать?
Вы когда-нибудь выращивали цветы? Комнатные, или на клумбе, или может быть даже не цветы, а кусты или деревья?
Конечно, можно сначала нанять ландшафтных дизайнеров, распланировать и спроектировать большой-большой парк, потом нанять рабочих, которые всё посеют и посадят в соответствии с планом, сделают дорожки и выкопают декоративные прудики. А потом будут его поддерживать.
Но для этого нужно во-первых, иметь опыт таких работ, а во-вторых, иметь достаточно солидный бюджет.
Однако есть и другой путь -- "органический". Сначала посадить один цветочек. Если не приживётся -- посадить другой. Когда вы увидите, что он хорошо себя чувствует -- посадить побольше таких цветов. Оформить красиво клумбу. Подсадить что-нибудь ещё. Разбить рядом вторую клумбу, с другими цветами. Потом что-нибудь куда-нибудь пересадить, а что-нибудь вообще перестать сажать, потому что не понравились. И так постепенно создать ничуть не менее красивый, а может даже более уютный парк. Где нет прямых, как стрела дорожек, но всё равно достигнута гармония.
Тесты можно выращивать примерно так же -- используя разные инструменты, время от времени меняя их, постепенно усложняя архитектуру по мере надобности. Главное -- не забывать их регулярно поливать и полоть, чтобы не заросли сорняками.
Для автоматизации тестирования под 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 это реализуется с помощью так называемых "профилей", вот как это делается:
