Когда мы говорим о веб-валидаторах и оптимизации сайта под них, мы чаще всего имеем ввиду Lighthouse/Pagespeed Insights от Google, который давно стал де-факто стандартом для оценки производительности сайта. Кто-то стремится к заветным 100 баллам даже на прототипах и шаблонных приложениях в две кнопки, кто-то в шутку создает абсолютно недоступный сайт с идеальным рейтингом, но для всех фронтендеров лайтхаус предоставляет вменяемую, хоть и довольно поверхностную, аналитику производительности сайта и поиск бутылочных горлышек. Однако скорость загрузки — лишь один из множества параметров, которые стоит проверять на своём сайте, и для большинства других есть свои валидаторы и скоринговые алгоритмы. Мы рассмотрим инструменты для каждого из значимых направлений и составим список, по которому стоит прогонять свой сайт, чтобы в дальнейшем не отлавливать проблемы вручную.
Автор: Ким Нап (Kim Knup) Оригинал статьи Перевод: Ольга Алифанова
3 года назад я рассказывала о своем опыте тестирования производительности в Songkick, и, честно говоря, я любила эту дисциплину. Она сочетает две моих любимых вещи – поведение пользователей и поведение системы в различных условиях. Было просто потрясающе – включаешь распродажу билетов на артиста и наблюдаешь, как по-разному используют систему разные поклонники. Они отличаются не только используемыми устройствами и браузерами, но и тем, что они делают. Они постоянно обновляют страницу, возвращаются вперед и снова переходят назад. Кому-то достаточно одного билета, а кто-то всегда берет несколько.
Обожаю сочетать данные о поведении реальных пользователей с их действиями и моделировать на этом основании различные тесты производительности.
Технические доклады от спикеров со всего мира о ручном и автоматизированном тестировании веб, десктоп и мобильных приложений. А также интервью с экспертами, воркшопы, нетворкинг и дискуссионные зоны для лютых холиваров.
В программе:
— Автор книги «Как тестируют в Google» и Distinguished Engineer Microsoft Джеймс Уиттакер расскажет о роли тестирования в эпоху искусственного интеллекта и о том, какие навыки в эту эпоху стоит развивать тестировщику.
— Shweta Sharma, Director of QA в Axelerant Technologies выступит с темой автоматизации визуального тестирования веб-приложений. Если вы хотите, чтобы стабильность вашего UI была под контролем автотестов, то доклад даст вам все необходимые знания, чтобы это реализовать.
— Андрей Солнцев выступит с докладом о flaky-тестах и борьбе с ними, а также проведет воркшоп, где покажет, как создать с нуля проект автоматизации тестирования в Selenide. Если вы хотите поднять крутую автоматизацию у себя в проекте, приходите узнать, как это нужно делать.
Всем привет. Мы в Avokado Project продолжаем рассказывать про автотестирование в Android. Эта статья — обзор и сравнение существующих инструментов для написания UI-тестов.
Давайте начнем с того, что вспомним, как обычно выглядит процесс тестирования. Будем называть сущность, которая взаимодействует с приложением, клиентом. Для взаимодействия с приложением клиенту обычно доступно несколько интерфейсов: API, REST API, CLI, GUI и т.д. И если, например, API используются клиентами-программами, то GUI используется человеком.
Ожидания от поведения приложения описываются в спецификации. Задача тестирования — проверить, что поведение приложения соответствует спецификации.
Автор: Баз Дейкстра (Bas Djikstra) Оригинал статьи Перевод: Ольга Алифанова
В этой короткой серии статей я исследую библиотеку Python requests и ее использование для тестов REST API. Это четвертая статья в серии, и в ней мы разберемся с имитацией ответов для юнит-тестирования.
Любой компании необходим взгляд со стороны на состояние информационной безопасности сервисов и продуктов. Эту задачу можно решить разными способами, один из которых — участие в Bug Bounty программах.
Bug Bounty программа как свежая сила в деле багхантинга
Bug Bounty («вознаграждение за ошибку») — это программа, которая предусматривает денежное вознаграждение или другие бенефиты за нахождение багов, эксплойтов и уязвимостей в работе ПО. Программы Bug Bounty реализованы многими компаниями, в том числе Facebook, Google, Reddit, Apple, Microsoft и др.
Автор: Баз Дейкстра (Bas Djikstra) Оригинал статьи Перевод: Ольга Алифанова
Если вы пишете тесты Selenium на C#, то, возможно, заметили, что начиная с версии 3.11 ряд часто используемых штук помечен как устаревший – в частности, PageFactory и класс ExpectedConditions. Для тех, кто не знает, почему это произошло – вот объяснение Джима Эванса, основного разработчика связки Selenium C#.
Все это перемещено в новое место и доступно в форме отдельных пакетов NuGet (DotNetSeleniumExtras.PageObjects и DotNetSeleniumExtras.WaitHelpers, соответственно). Когда я писал эту статью, этот репозиторий никто не поддерживал – а следовательно, поддержка недоступна, и будущее его туманно.
Мы – Владимир Мясников и Владислав Егоров — представители команды интеграционного тестирования Mir Plat.Form (АО «НСПК»). Сегодня мы расскажем про разработанный и развиваемый нами инструмент автоматизации, позволивший сократить рутину во внутренних процессах команды.
Предисловие
Платёжная экосистема Mir Plat.Form включает в себя несколько десятков систем, большинство из которых взаимодействуют между собой по различным протоколам и форматам. Мы, команда интеграционного тестирования, проверяем соответствие этих взаимодействий установленным требованиям.
На данный момент команда работает с 13 системами уровня mission и business critical. Mission critical системы обеспечивают выполнение Mir Plat.Form своих основных функций, обеспечивающих стабильность и непрерывность функционирования банковской карточной системы РФ. Системы уровня business critical отвечают за поддержку предоставляемых клиентам Mir Plat.form дополнительных сервисов, от которых зависит непосредственная операционная деятельность компании. Частота выкатывания релизов в ПРОД варьируется от раза в неделю до раза в квартал, всё зависит от системы и готовности участников к частоте обновлений. В общей сложности мы насчитали около 200 релизов, прошедших через нашу команду в прошлом году.
Автор: Рикард Эдгрен (Rikard Edgren) Оригинал статьи Перевод: Ольга Алифанова
На EuroSTAR 2019 я читал доклад о характеристиках качества вместе с Хенриком Эмильссоном. Больше всего в этих конференциях мне нравится то, что ты никогда не знаешь, что произойдет. Как-то раз я закончил свой ответ фразой "если тестировать легко, вы что-то не так делаете". Помню, как доволен я был, сказав это. Эта фраза отлично подходила для контекста, в каком-то смысле подытоживая мое отношение к тестированию и причины, по которым я его так люблю.
Я забыл об этом, читая лекцию, но вспомнил, когда мы получили обратную связь от аудитории. Обратная связь была очень хорошей, но всем понравиться нельзя (если это происходит, вы что-то делаете не так).
Один из участников (не помню, кто, да это и не важно) был очень негативно настроен и сказал, что говоря, что "если тестировать легко – вы что-то делаете не так", мы показываем себя плохими, непрофессиональными тестировщиками.
Настало время объяснить, что я имею в виду. Кто-то наверняка со мной не согласится, но это может привести к интересным обсуждениям (или неконструктивным комментариям).
Всем привет! Меня зовут Егор Иванов, и я специалист по автоматизации тестирования. Довольно долгое время до этого я проработал в различных компаниях из сферы BI. Я обожаю визуализацию данных и считаю, что без нее невозможно строить рабочие процессы и уж тем более процессы в тестировании. Поэтому хочу, чтобы ее использовали как можно больше людей, так как визуализация данных очень важна, а в виде дашбордов она еще и прекрасна.
Надеюсь, материал будет полезен и для тех, кто уже использует дашборд, — возможно, вы увидите новое применение для этого инструмента. А те, кто незнаком с ним, познакомятся и, возможно, также начнут его использовать.
Многие из нас видят дашборд каждый день. Он пришел к нам из транспорта — это приборная панель автомобиля.
Слева - дашборд автомобиля, справа - информационный дашборд в IT
