В прошлом месяце я участвовал в конференции DevOps в Тель-Авиве. Я делал заметки об интересных вещах, про которые рассказывали люди – как и многие на конференции – и затем убрал блокнот – как делают, опять же, многие после конференции.
Вчера, просматривая блокнот (вроде бы я хотел посмотреть, что мне еще нужно сделать из моих бесконечных списков "надо сделать"), и наткнулся на заметки с конференции. Среди рисунков и почеркушек было предложение, за которое я зацепился взглядом. Я написал его и затем позабыл, но когда вновь увидел его, оно снова привлекло мое внимание.
Вот что там было написано:
Сложность – это тоже баг. Сложность повышается и будет продолжать повышаться.
Под этим предложением были заметки о презентации этого спикера.
Он был основателем/программистом/гиком/директором из Силиконовой Долины, и он рассказывал, как, с его точки зрения, повышается сложность программных продуктов, и как она будет повышаться в будущем.
Суть его речи сводилась к тому, что компании, занимающиеся разработкой ПО, должны выбрать, кто будет справляться с этой сложностью. Он смотрел на это с точки зрения DevOps, и поэтому сказал, что варианта тут три – разработка, IT или конечные пользователи.
Проще говоря, приложения должны делать больше: разговаривать с другими приложениями, чтобы что-то сделать, делать это быстрее, делать это в разнообразных окружениях. Мы делаем все больше и больше (не считая сна и отдыха, которых у нас все меньше и меньше).
Так вот обстоят дела, и кто-то должен "заплатить штраф" за эту повышающуюся сложность, а этот штраф может понести только одна из трех вышеперечисленных сторон.
Справляться со сложностью можно в качестве части процесса разработки, создавая более сложные алгоритмы и хитрые коды, чтобы управляться с повышающейся сложностью.
Частично эта задача может лечь на IT, деплоящим и настраивающим систему так, чтобы она могла справляться с повышенной сложностью.
И, наконец, все то, с чем не справились два предыдущих кандидата, уходит к конечным пользователям, которым надо разбираться с более сложными процессами установки и настройки, и менее дружелюбными приложениями.
В конце презентации он объяснил, что сложность – это игра с нулевой суммой, и в процесс разработки ПО должно входить решение, кто будет справляться со сложностью.
В современном мире бизнес всё чаще обращает внимание на мобильные технологии. Рынок мобильных устройств растёт в разы быстрее рынка домашних компьютеров, позволяя реализовывать новые возможности для развития и продвижения самых передовых бизнес идей. Вместе с тем возрастает и спрос на тестировщиков мобильных приложений. Разработка мобильного ПО – новая и динамично развивающаяся отрасль, поэтому разработчикам и тестировщикам приходится решать не только типичные IT проблемы, но и преодолевать вновь возникающие, ещё не изведанные трудности. Сложность при этом заключается ещё и в том, что сами инструменты для разработки и тестирования находятся на стадии развития.
Данный тренинг направлен на то, чтобы помочь вам преодолеть трудности, возникающие при тестировании мобильных приложений. Курс рассчитан как на новичков, собирающихся работать в мобильном тестировании, так и на уже работающих мобильных тестировщиков, которые хотят повысить свою квалификацию.
На тренинге вы научитесь работать с инструментами мобильного тестирования: телефонами, эмуляторами, прокси, IDE. Особый акцент сделан на работе с платформой Android, как с наиболее распространённой мобильной ОС на данный момент. Также вы научитесь использовать более продвинутые техники: сбор статистики, построение стратегии тестирования мобильных приложений, использование сторонних сервисов и организацию различных видов тестирования.
Тренинг рассчитан не только на приобретение теоретических знаний, но и на их отработку, позволяя на практике научиться применять навыки тестировщика мобильных приложений.
После прохождения тренинга вы научитесь разрабатывать автоматизированные тесты для веб-приложений с использованием инструмента Selenium IDE.
От участников не требуется никакой предварительной подготовки в области автоматизации тестирования, не требуется умение программировать, не требуется предварительное знакомство с Selenium или иным инструментом автоматизации. Стартуем с нулевой отметки.
Чем же новая версия тренинга отличается от предыдущей?
Во-первых, мы записали тренинг в более удобном формате. Материал представлен в виде серии небольших модулей средней продолжительностью около 10 минут. Такие короткие лекции проще усваиваются, чем длинный непрерывный рассказ.
Во-вторых, мы полностью переработали программу тренинга. За счёт более компактного и насыщенного изложения материала мы смогли без увеличения времени и стоимости тренинга добавить целый ряд новых тем. В них рассмотриваются вопросы, которые часто задавали участники предыдущих тренингов:
-- объяснение принципов работы XPath и CSS локаторов,
-- различие между некоторыми похожими командами (click и clickAt, type и sendKeys),
-- использование ожиданий, выполнение фрагментов JavaScript-кода,
-- усложнение логики сценариев при помощи расширения SelBlocks,
-- загрузка тестовых данных из внешнего файла (Data Driven Testing).
В третьих, появились новые интересные домашние задания. Участникам предостоит автоматизировать несколько сценариев в реальном веб-магазине, имеющем достаточно сложный интерфейс с динамическими элементами.
Да, пожалуй, у нас получился самый лучший в мире тренинг, посвящённый инструменту Selenium IDE!
И конечно всё это (как в любом нашем тренинге) сопровождается поддержкой тренера, готового отвечать на самые каверзные вопросы и помогающего вам освоить все возможности инструмента.
Онлайн-тренинг Таисии Рыбак, 1 месяц занятий, 4 часа теории + много практики + постоянные консультации тренера в скайп-чате
Тестирование базируется на требованиях, но часто бывает, что сформулированных требований нет или они не полные. И на тестировщиков падает задача по сбору базиса для тестирования. Данный курс поможет понять, как правильно организовать процесс сбора, выявления и управления требований как в крупных проектах, так и для небольших команд гибкой разработки. Мы на примерах разберем все этапы работы с требованиями и проведем практические занятия в системе управления требованиями.
Добрый день!
Возникла проблема. Нужно в Jmeter сделать конвертацию base64 в массив байтов и отправить этот массив на сервер. Подскажите пожалуйста как это можно реализовать, какие инструменты, плагины использовать?
Пыталась использовать BeanShell Sampler, но все тщетно(
Изучаю автоматизированное тестировние, столкнулся с проблемой когда нужно передать пароль и логин чтобы авторизроватся. С куки,http запросами еще не разбирался может кто помочь как пройти авторизацию? Использую Selenium+Java. Возможно как - то можно запустить Хром используя параметры какие у него уже записаны в тех же куках когда логинюсь вручную?