Добро пожаловать на 1-й день челленджа #30DaysOfPlaywright!
Сегодня наша цель – изучить руководство по началу работы с фреймворком, которое должно помочь настроить средство запуска Playwright Test в локальной среде разработки и подготовить его для выполнения первого тестового прогона.
1 декабря мы провели конференцию QA Meeting Point. Участники услышали выступления экспертов в области тестирования AI и BigData, разобрались в основах performance-тестирования, познакомились с GraphQL и узнали, как создавать модульные тестовые проекты.
Ссылка на доклады и видео о QA Meeting Point — под катом.
Чему нужно обучить junior QA, чтобы он начал приносить пользу проекту? Конечно, было бы здорово «всему и сразу», но это может затянуться надолго. А вот с основами тестирования можно познакомить буквально за пару-тройку дней. Особенно если это фулл-тайм дни (рабочее время).
Я обучаю новичков больше 6 лет, больше тысячи людей выпустила, книгу вот написала. И на опыте студентов вижу, что «план-минимум» на самом деле небольшой.
Если перед вами стоит задача «завтра выйдут два джуниора, обучи их», начните с основ. Один из вариантов:
• дали посмотреть видео или прочитать статьи;
• собрались вместе в переговорке или зуме, обсудили;
• дали ДЗ на закрепление материала;
• через три дня получили более-менее адекватного джуна, профит!
В этом посте я собрала ссылки в помощь по каждой теме:
• видео — варианты из публичного доступа. Выбираете то, что больше по душе, отдаете падаванам;
• статьи — даете как дополнительный материал.
В итоге затраты на подготовку — меньше, а польза от новичков — быстрее.
В этом месяце было решено изучить тему, которая привлекает лично меня – e2e-тестирование веб-приложений. Я хочу перейти от изучения основных концепций и инструментов к реализации эффективных стратегий кросс-браузерного тестирования в рабочих процессах разработки веб-приложений. Планирую сделать это с помощью Playwright.
Присоединяйтесь к #30DaysOfPlaywright. Давайте изучим инструменты, API и лучшие практики, по одному сценарию тестирования за раз!
Перефразируя советского Чебурашку: «Мы ждали, ждали и наконец дождались!». Intel выпустила новые процессоры — Core i9-12900k. На новом техпроцессе, новой архитектуре, новом сокете и с новой памятью. Сам Раджа Кодури еще полтора года назад высказывался в том ключе, что выход этих процессоров может стать наиболее значимым шагом для Intel со времён появления процессоров Core в 2006 году. Давайте рассмотрим эти процессоры внимательнее.
Aloha всем хабравчанам! Я Влад, системный администратор Cloud4Y. Хочу рассказать, как и зачем мы используем продукт Phoronix Test Suite, а также каким образом можно точно и легко определить реальную (не заявленную) производительность оборудования, предоставленного провайдером облачных услуг.
В этой статье поговорю про основы работы с Postman для начинающих тестировщиков. Сама я столкнулась с этим инструментом как раз на последнем проекте.
Расскажу, как с его помощью создавать простейшие автотесты и уменьшать объем рутины с помощью переменных.
В прошлых публикациях (первая и вторая) рассмотрели основные понятия про качество, четырехуровневый процесса управления и обеспечения качества, увидели что требования и качества тесно связаны друг с другом, попробовали получить ответы на вопросы какое мышление должно быть у команды для встраивания качества в продукт? Какая на продукте пирамида тестирования? Как ускорить получение обратной связи при разработке программного обеспечения?
Отлично. Разобрались, осознали и приняли мышление Test-First, концепцию Shift Left Testing, определили пирамиду тестирования. Теперь возничкает вопрос, а как начать качественно генерировать качественные тест кейсы?
Мы все знаем прелести раннего тестирования и честно стараемся ревьюить требования, архитектурные проекты и прочую документацию. Выискиваем неполные описания, инструкции, которые приведут к ошибкам и вопросы без ответов.
При этом у меня бывает, что на тестировании документации сложно сфокусироваться, особенно если это затянувшееся коллективное ревью, автор рассказывает детали, а скука обволакивает и затягивает в сон. Я попыталась себе помочь, и зафиксировала некоторые азы рецензирования. Держу их перед собой. Добавим чашку кофе, и ревью превращается в осмысленное мероприятие.
Тем, кто формирует свой стиль работы, пригодится. Делюсь!
Привет. Меня зовут Маша, я — тестировщик в команде мобильной платформы. Когда-то для нас была актуальна проблема взаимодействия QA и Support. Сложностей было предостаточно, как и неприятных последствий. Но со временем мы успешно разобрались во всем. Хочу поделиться нашим опытом и рассказать, какие изменения сработали во благо.
Привет! Сегодня стартует наш четвертый митап для тестировщиков, QAчественное общение. До 18:00 МСК на него все еще можно зарегистрироваться. А пока мы начинаем выкладывать доклады с предыдущего митапа, и начинаем с Ольги, старшего QA-инженера в компании red_mad_robot.
Поговорим про мобильные устройства и про снятие логов с этих мобильных устройств, почитаем их и разберем, как вообще с ними работать.
Не всегда, приходя на крупный новый или старый проект, тестировщик знает с какой стороны подойти к началу процесса тестирования. Иногда нет куратора, иногда не настроен процесс коммуникации. И вы можете хоть сто раз плюнуть в компанию и пойти искать новую, благо рынок сейчас в дефиците. Но гораздо интереснее будет получить бесценный опыт становления вас как самостоятельного и понимающего члена команды. Данная статья будет посвящена практике тестирования системы антифрод в одном из крупнейших банков РФ. О чем мы поговорим в этой статье? Об особенностях архитектуры enterprise. Про основной инструментарий и про советы тем, кто захочет прийти в сферу интеграционного тестирования бэкэнда в крупную компанию.
Когда вы Когда вы открываете любой сайт — например, google или facebook, вы видите конечный продукт. Но чтобы этот продукт увидеть, и пощупать, нужно:
1. Написать код приложения
2. Собрать проект
3. Поднять его на сервере приложения
Сегодня я расскажу про второй этап. Сборку приложения можно проводить вручную, но есть также специальные инструменты для этого, которые называются «сборщик продукта». О них мы и поговорим.
Когда поступает HTTP-запрос, «обычное» веб-приложение сопоставляет запрос с конкретным потоком из пула потоков. Этот назначенный поток остается с запросом до тех пор, пока ответ не будет возвращен в сокет запроса. Попутно нам может потребоваться получить данные из некоторой веб-службы или базы данных, прочитать или записать в файл или выполнить другие вызовы ввода-вывода, во время которых поток блокируется и должен ждать, пока не получит ответ. Для приложений с высокой частотой запросов пул потоков может в какой-то момент исчерпаться, и тогда новые запросы больше не будут обрабатываться.
Здесь нам может помочь реактивное программирование. Вместо того, чтобы иметь большой пул потоков и модель «поток на запрос», реактивное приложение имеет только один поток на каждое ядро ЦП, которое продолжает работать, и если оно попадает в операцию ввода-вывода, оно разгружает эту операцию и работает над чем-то еще до тех пор, пока IO завершено. Мы говорим, что такое приложение неблокирующее.
Подход появился, когда группа компаний объединилась в инициативе Reactive Streams, чтобы определить ключевые принципы и четыре интерфейса JVM. После этого они практически каждый пошли своим путем, чтобы создать реактивную библиотеку на основе этих соглашений. Одна из этих библиотек, Project Reactor, является основой, на которой Spring построил свою реактивную веб-платформу Spring WebFlux.
Этот реактивный стек позволяет нам создавать неблокирующие веб-приложения в структуре, которая выглядит знакомой с точки зрения классов, методов и аннотаций, если вы работали с Spring MVC, но фактическая реализация методов может быть с довольно сложной кривой обучения.
Статья для начинающих аналитиков-стажеров
Когда вводишь в поисковой запрос "Курсы для аналитика данных", то сразу в глаза бросается SQL, Phytnon, R и другие инструменты. Но в первую очередь аналитику данных помогли бы не только инструменты, а еще и определенные способы мышления цифрового детектива. На наглядном примере мы вместе протестируем витрину данных, выстроим логику развития событий, а далее применим SQL. Статья предназначена для junior аналитиков данных или тех, кто только знакомится с будущей профессией Data Analyst.
Однажды, давным-давно, автор по локти погрузился в тестирование рынка подготовки тестировщиков с нуля. Он размышлял об обучении, общался с десятками продажников, слушал вводные лекции множества курсов с иногда противоречивыми чувствами, знакомился со многими интересными лекторами и анкетировал 100+ абитуриентов, текущих студентов и вчерашних.
В общем за прошедший месяц много чего произошло. Также автор получил множество вопросов от абитуриентов по выбору курсов. Исследование предполагает большое число общения и автору это нравится. Но некоторые вещи повторять каждый раз скучно, поэтому в ожидании результатов затянувшегося “Этап 3: Объективно оцениваем наполненность курсов (для этого привлечем QA-эксперта с опытом 15+ лет подготовки)” решил здесь зафиксировать следующее...
Несмотря на то, что у этих фреймворков много общего, Puppeteer и Playwright развивались с разной скоростью, и сейчас Playwright набрал обороты и оставил Puppeteer позади.
Это привело к тому, что многие перешли с Puppeteer на Playwright. Это статья показывает, какие нужны шаги и какие новые возможности открывает этот переход. Пусть вас не смущает объем этой статьи, в большинстве случаев переход происходит быстро и безболезненно.
Привет! Меня зовут Степан Лущий, я – тимлид команды тестирования компании «БАРС Груп». Мы занимаемся созданием автоматизированных тестов (автотест), инструментов для их написания, а также развитием инфраструктуры автотестирования. В этой статье я расскажу, как мы разработали инструмент, с помощью которого у нас получилось значительно сократить время реализации автотеста.
