Home

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Среди тестировщиков множество перфекционистов. Практически у всех, с кем я сталкивался, чешутся руки использовать команду .wait() в Cypress и остановить тест на пару секунд. Если вы из таких людей, то отлично знаете, что такое использование .wait() – не лучшее решение, и пробуете найти альтернативу. Тест просто ничего не делает несколько секунд. Их может быть достаточно, но иногда этого мало.

Когда мы используем .wait(), то хотим, чтобы приложение пршило в нужное состояние. Закрытие модального окна, получение ответа от сети, смена состояния кнопки… Cypress был создан с учетом повторных попыток – это означает, что как только команда сработает, Cypress перейдет к следующей. Если команда не срабатывает, Cypress будет пытаться выполнить ее повторно в течение нескольких секунд.

Эта архитектура часто приводит к тому, что Cypress зачастую слишком быстро бежит по приложению, а мы хотим заставить его подождать. Жестко закодированное ожидание – зачастую способ приказать Cypress замедлиться. Но это не идеальный подход, как я уже говорил. Давайте посмотрим, что можно сделать, если вы сталкиваетесь с этим пугающим решением.

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

TypeScript в последнее время набирает популярность, и для этого есть веские основания. Он помогает разработчикам создавать свои собственные типы. Это позволяет делать меньше ошибок и создавать самодокументирующийся код. В этой статье я познакомлю вас с основами TypeScript.

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Вы узнаете:

• Как создать кастомную команду, автоматически дополняющую ваши селекторы
• Как выполнить проверку тестов, написанных на TypeScript
• Как грепнуть селекторы из приложения
• Как создать предупреждение, если в приложении есть неиспользуемые селекторы.

Cypress советует использовать селекторы data-cy в качестве лучшей практики для выбора элементов на странице. Недавно мы отлично подискутировали в дискорде, действительно ли эта практика хороша. Лично я сильно склоняюсь к "да". Если вы в моем лагере, у меня есть для вас ряд полезных советов.

Автор: Луиза Гиббс (Louise Gibbs)
Оригинал статьи
Перевод: Ольга Алифанова

UI-автоматизация может быть медленной, неуклюжей и склонной к ошибкам. Ее поддержка в условиях меняющейся базы кода неизбежна. Настройка тестов, исправление поломок и адаптация к изменениям ПО могут стать огромной проблемой.

Это звучит адски, но я обожаю это! Это похоже на серию головоломок, нуждающихся в решении, а я люблю головоломки. Если вы покупаете книгу головоломок в киоске, то загадки в начале книги будут намного проще загадок в ее конце. Если вы совсем новичок в этом типе задач, логично начинать с начала, с более простых головоломок.

Вне зависимости от вашего опыта автоматизации, вы должны подходить к проекту как новичок, если проект для вас в новинку. Начните с идентификации "простых" тестов. Я всегда начинаю с теста, запускающего приложение. Если вы не сможете это сделать, то все остальные тесты будут бесполезными.

Затем сконцентрируйтесь на создании базовых тестов, перемещающихся по приложению, открывающих определенные страницы и выполняющих базовые действия. Нажатия кнопок легко выполнимы, и это хорошее место для старта. Начиная, не особо раздумывайте о том, какие тесты понадобятся вам надолго – думайте о создании тестов, которые "работают", и развивайте их. Добавляйте более сложные действия, когда основной фреймворк уже готов, и у вас появилась некоторая уверенность.

В этом примере я расскажу, как я начинаю совершенно новый проект UI-автоматизации.

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Если вы оказались здесь через Google-поиск, то, возможно, недоумеваете, почему подобный код не работает в Cypress:

it('stores value in variable', () => {
 
     let id
 
     cy.request('/api/boards')
          .then( res => {
 
          id = res.body[0].id
     })
 
     cy.visit('/board/' + id) // "id" is undefined?!
 
})

Если вам нужно только решение, промотайте вниз до раздела Возможные решения. Если вы хотите разобраться, что происходит, читайте дальше.

Источник — блог HTML Academy

Быстрые сайты любят и пользователи, и поисковики.

С первыми всё просто: если страница долго грузится, пользователь её закроет и перейдёт на другой сайт. С поисковиками похожая история: скорость загрузки влияет на ранжирование сайта в поисковой выдаче.

Проверить производительность сайта можно с помощью разных инструментов. Один из наиболее известных — Lighthouse от компании Google. Он не только тестирует сайт и показывает оценку производительности, но и даёт конкретные рекомендации: что можно улучшить, чтобы сделать сайт быстрее.

Давайте разберём, как с помощью Lighthouse проверить качество сайта и повысить его производительность. Мы не будем углубляться в алгоритмы работы инструмента и принципы подсчёта внутренних метрик: начинающим веб-разработчикам это и не нужно. Однако знать, как работает инструмент, и уметь использовать его в своих проектах — очень важный навык.

Оригинальная публикация

Всем привет, меня зовут Катя, я QA Engineering Manager в inDriver. В этой статье расскажу про свой опыт использования Proxyman, а также о том, почему считаю его лучшей программой-сниффером. Приятного чтения! 

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Осторожно! Длинная статья!

Введение

Это отчет о попытке провести обзор и тестирование работоспособности инструмента "тест-автоматизации". Работа велась в сентябре 2021, а последующие мероприятия – 3-4 ноября. Приложение - Katalon Studio.

Мой самоназначенный чартер заключался в исследовании и инспектировании Katalon Studio с фокусом на рекламациях и идентификации функциональности продукта посредством лояльного применения.

Я включил в статью мета-заметки о тестировании, выделенные курсивом.

Основная миссия обзорного тестирования – это изучение дизайна, задач, тестируемости и возможностей продукта. Обзорное тестирование, как правило, спонтанно, открыто, несерьезно и сравнительно поверхностно. Оно дает базу для эффективного, результативного, намеренного, глубокого дальнейшего тестирования.

Тестирование работоспособности можно также назвать "смоук-тестированием", "быстрым тестированием" или "тестированием верификации сборки". Это краткое, поверхностное тестирование с целью определить, подходит ли продукт для глубокого тестирования, или же в нем есть очевидные или серьезные проблемы.

Идея лояльного тестирования не в поиске багов, а в использовании функциональности продукта относительно несложным образом.

Автор: Яковлев Станислав — Team Lead команды тестирования сервиса Юла, телеграмм канал t.me/qa_chillout

Привет! После знакомства с Charles Proxy большинство из читателей захотело узнать больше про инструменты мониторинга и анализа HTTP/HTTPS трафика. Расскажем про популярный у многих тестировщиков Fiddler. Описать все возможности Fiddler в одной статье вряд ли получится, поэтому давайте рассмотрим базовые возможности, которыми мы пользуемся каждый день.

Fiddler это:

Кроссплатформенное приложение прокси-сервера для отладки HTTP. Он позволяет пользователю просматривать HTTP, HTTPS и активированный трафик TCP-порта, доступ к которому осуществляется с локального компьютера, на него или через него. Сюда входят запросы и ответы, включая HTTP-заголовки и метаданные (например, файлы cookie, кэширование и кодирование информации), с функциями, предназначенными для помощи разработчикам и тестировщикам в анализе соединений и обмене сообщениями.

Автор: Корина Пип (Corina Pip)
Оригинал статьи
Перевод: Ольга Алифанова

Вопрос падения тестов Selenium из-за неразберихи со временем поднимается достаточно часто. Тесты случайным образом падают, если взаимодействие произошло слишком рано, страница неправильно загрузилась, или веб-элементы не полностью инициализированы. Наибольшие проблемы возникают, если в отрисовке элементов страницы задействован JavaScript.

Хотя в ряде случаев тестировщики пользуются методами ожидания Selenium WebDriver, чтобы условия выполнились до начала взаимодействия, тесты все равно могут продолжать падать. Как же добиться надежных тестов? Читайте дальше, чтобы узнать, как создавать агрегированные методы ожидания, позволяющие заново создавать сложные условия.