Затем задумайтесь о том, как люди участвуют в тест-автоматизации в зависимости от того, где они в этой модели находятся. Изначально я пометила части диаграммы как доступ, навыки и мотивацию:
Все приложения можно условно разделить на «спринтеров» и «марафонцев». Спринтеров запускают редко и ненадолго — например, интернет-банк для проведения разовых операций. Марафонцы же включены у своих пользователей постоянно: текстовые редакторы, бухгалтерские программы, системы документооборота и т.д.
Если ваш продукт — марафонец, то вам просто необходимо тестирование надёжности (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 и проверить работу.
Сегодня мы поговорим о тестировании безопасности веб-приложений. Сам я инженер по тестированию, по образованию – специалист по информационной безопасности, а по жизни – параноик.
В то время, когда я учился в университете, было не принято преподавать какие-то реальные вещи (читай – потребности отрасли), касающиеся защиты и компрометации информационных систем. Конечно, это можно было бы списать на бюрократию и сложности внедрения новых методик, но я думаю, что там, как и везде, просто больше любят бумажки – оттуда и безопасность у нас — «бумажная». В работе же необходимы практические навыки и знания.
1. СНАРУЖИ
Ни для кого не секрет, что количество сетевых атак неуклонно растет. Каждый день их совершается около 1000, подсчитать же их число за год практически невозможно (это наглядно видно из статьи Стива Моргана). Атакам подвергаются самые разные сетевые ресурсы – от сайта местного провайдера до федерального размера (агентурной) торговой сети суши и атомных станций. Можно даже посмотреть на интерактивную карту кибератак в режиме онлайн.
И каждый уязвим. И каждый отдает себе отчет об этом риске. И каждый думает, что это не про него. Что уж там душой кривить – мы так привыкли. Нежелание признавать риски приводит к нежелательным последствиям.
Давайте рассмотрим безопасность подробнее, ведь «в действительности все не так, как на самом деле» (с).
Рано или поздно каждый специалист в сфере автоматизированного тестирования сталкивается с необходимостью ускорять тестовые прогоны, идя для этого на всевозможные ухищрения, в том числе прибегая к инфраструктурным решениям.
Последнее время трендом стало использование инструмента виртуализации Docker, и именно о нём будет данный доклад, а также о ряде других лайф-хаков, которые сыграли большое значение в решении задачи по ускорению прогонов на практике.
В рамках доклада вы получите ответы на следующие вопросы:
что такое Docker, и в каких случаях он позволяет оптимизировать тестовые запуски
как избавиться от классических «болезней» при параллельном выполнении автотестов
как получить достаточное количество окружений для параллельных запусков, изрядно при этом сэкономив
как привнести динамику в жизнь проекта и, в случае необходимости, без труда мигрировать между серверами?
Если бы на модные словечки века проводился конкурс (хоть я и не думаю, что тестированию уже стукнуло сто лет), я почти на 100% уверен, что выиграла бы автоматизация тестирования. Если вы читаете про тестирование или слушаете подкасты, это обычно «автоматизация то», «автоматизация се», «автоматизируйте все».
Оно безусловно чрезмерно употребляется и чрезмерно злоупотребляется, и я готов спорить, что куча людей, дающих советы по автоматизации, не имеют ни малейшего представления, о чем они, черт возьми, говорят. Или, как минимум, их заявления демонстрируют полнейшее непонимание цели автоматизации.
То, что термины «тест-автоматизация» и «автоматизированное тестирование» во многом ошибочны, то, что «автоматизировать» тестирование, в сущности, нельзя, то, что мы можем автоматизировать только его часть, обсуждалось множество раз, бла, бла, бла, я не буду это повторять, и мне скучно говорить об этом снова и снова. Мысль, которая ударила меня как молния, состоит в том, что автоматизации тестирования не существует – есть «тестирование» и есть «автоматизация». Мне кажется, что наше мышление еще недостаточно развилось для того, чтобы мы эффективно их комбинировали. Сейчас покажу.
