Прошло довольно много времени с момента нашейпоследней статьи об эффективной Selenium-инфраструктуре. Если вы находитесь в самом начале непростого пути Selenium — советую ознакомиться с нашими статьями про масштабируемый Selenium (часть I, часть II), Selenoid — универсальный инструмент для автоматизации тестов в браузерах (раз, два), Selenium под Windows (ссылка). Если вам больше нравятся мотивирующие рассказы — посмотрите видео моего доклада про масштабируемый Selenium на SeleniumConf Berlin 2017.
С момента публикации последней статьи в нашем сообществе произошло много интересного. Сегодня я хочу рассказать о самых важных возможностях, добавленных в наши инструменты за последние месяцы.
Если долго ведешь блог, то одним из забавных результатов становится то, что люди начинают воспринимать тебя как эксперта. Так это или не так в моем случае – вам судить. В любом случае ко мне обращаются за советами по поводу карьеры, а также спрашивают, знаю ли я, куда движется отрасль. Отвечать на первую часть я здесь не буду – нет такого понятия, как общие советы по карьере, а делиться вопросами, которые мне задавали, и моими ответами мне неловко.
В этой статье я поделюсь своими мыслями на тему «куда движется отрасль». Вы все равно увидите в ней скрытые карьерные советы.
Последний и самый короткий месяц зимы выдался необычайно насыщенным новаторскими подходами и свежими решениями в автотестировании. Сегодняшнее повествование целиком и полностью посвящено автоматизации, и для этого есть множество причин:
автоматизация — это высшее благо при проведении регрессионного тестирования!
автоматизация помогает исключить человеческий фактор, а значит минимизировать ошибки!
все, что может быть автоматизировано, должно быть автоматизировано!
А теперь с удовольствием и гордостью представляем на ваш суд каждое достижение, успешно реализованное нами в феврале.
Затем задумайтесь о том, как люди участвуют в тест-автоматизации в зависимости от того, где они в этой модели находятся. Изначально я пометила части диаграммы как доступ, навыки и мотивацию:
Все приложения можно условно разделить на «спринтеров» и «марафонцев». Спринтеров запускают редко и ненадолго — например, интернет-банк для проведения разовых операций. Марафонцы же включены у своих пользователей постоянно: текстовые редакторы, бухгалтерские программы, системы документооборота и т.д.
Если ваш продукт — марафонец, то вам просто необходимо тестирование надёжности (aka reliability testing). В рамках такого тестирования мы проверяем, как продукт ведёт себя при длительном использовании, не наблюдается ли утечек памяти, не растут ли используемые ресурсы, не возникают ли непредвиденные ошибки.
В своём докладе Олег расскажет, как проводить автоматизированное тестирование надёжности веб-приложений при помощи Selenium Web Driver.
По итогам этого доклада вы узнаете:
Какие критичные ошибки «марафонцев» можно пропустить, не уделяя достаточно внимания тестированию надёжности
Что такое утечки памяти, и почему растёт память браузера при длительном использовании продукта
Почему автоматизация тестирования — наиболее оправданное решение для тестирования надёжности
С чего начать автоматизацию reliability тестов, и как это лучше всего сделать.
Доклад будет полезен всем, кто занят тестированием регулярно и подолгу используемых программных продуктов.
Это письменная версия моего выступления на официальной конференции по Selenium в Берлине. Если вы предпочитаете посмотреть доклад, он доступен здесь: Selenium YouTube channel.
Как ваши коллеги вкладываются в автоматизацию?
Кто участвует в дизайне, разработке и поддержке наборов тестов?
Что произойдет, если люди в вашей команде изменят свой вклад в автоматизацию?
— Итак, поступило новое дело: в нашем распоряжении 10 дней для поиска места тестировщика в Scrum разработке. Необходимо понять, что же это такое Scrum, что входит в это понятие, кто вовлечен в этот процесс, и что именно необходимо делать тестировщику.
— Шеф, так что же такое Scrum?
— Все элементарно, коллега. Scrum – это набор принципов, на которых строится процесс разработки, позволяющий в установленные небольшие промежутки времени предоставлять заказчику (конечному пользователю) наделенное наибольшим приоритетом работающее ПО с новыми возможностями.
— И из чего состоит этот процесс?
— Из принципов, скоупа задач, определенных при планировании, и ограниченных (четко оговоренных и определенных) сроков. Учитывается и то, что качество не должно пострадать из-за скорости или установленных временных рамок.
— Шеф, и с чего начнем?
— А начнем с того, что рассмотрим наиболее простую и понятную схему для Scrum процесса: двухнедельная итерация (10 рабочих дней). При этом мы имеем определенно важный спринт, сплоченную команду разработки и тестирования, минимум документации, четкие требования к проекту и лаконичное описание требуемых разрабатываемых фич.
— И где же в этой схеме место тестировщика?
— А в этом нам предстоит разобраться, коллега!)
В любом из основных языков программирования существуют BDD фреймворки автоматизации. В некоторых даже не один. Основываясь на структурных принципах, описанных в предыдущей статье, в этой я представляю обзор основных фреймворков, существующих сегодня. Поскольку я вряд ли смогу рассмотреть подробно каждый BDD фреймворк в рамках этой серии, состоящей из 101 статьи, моей целью является помочь вам, читатели, выбрать фреймворк, наиболее подходящий именно вам. Для каждого фреймворка имеется сопроводительная online документация с информацией о его специфике и способах использования, но я бы предпочел не дублировать документацию. Используйте эту статью, главным образом, как справочный материал. (Полный список статей можно найти на странице Automation Panda BDD.)
Когда ты – единственный тестировщик – неважно, положивший ли начало или конец тест-команде – у тебя есть масса возможностей, осложненных внушительными обязанностями.
Если ты первый, кого наняла компания, то ты, возможно, отвечаешь за создание эффективных процессов тестирования для нескольких команд. Может быть, твоя обязанность – тестирование нескольких продуктов, или же ты возглавляешь найм новой команды. Одинокий тестировщик как результат сокращения команды может столкнуться со всеми этими проблемами, да еще и с дополнительным давлением – ведь нужно выполнять работу по тестированию, которую до этого делали другие люди.
В этих случаях легко сказать, что компания просто не ценит тестирование. Возможно, это даже правда, но я считаю, что в большинстве случаев это не так. В конце концов, ты еще там работаешь – то есть кто-то еще осознает нужду в тестировании. Возможно, на найм большего количества тестировщиков нет бюджета, или высший менеджмент считает, что тестирование должно быть частью команды, а не большой изолированной областью.
iOS - система с достаточно закрытой архитектурой. В отличие от Android, где для тестирования нужен только apk файл, здесь необходим доступ к исходному коду, чтобы просто скомпилировать тестовое приложение.
На курсе “Автоматизатор мобильных приложений” мы запускаем тесты через Appium на симуляторе iOS. Для того, чтобы проверить запуск приложения, мы используем Appium Viewer. В этом видео, которое является частью курса, показано, как получить .app файл, подключить его к Аppium и проверить работу.
