Тестирование веб-сервисов *

Сталкивались вы когда-нибудь с ошибкой при просмотре потокового видео на Netflix? Может — неожиданно останавливался или вовсе не запускался фильм, который вас заинтересовал? В первой части этой серии статей мы рассказали о методологии тестирования канареечных релизов, применяемой к показателям, которые представлены непрерывными потоками данных. Среди таких показателей — «задержка воспроизведения» (play‑delay). Вот комментарий одного из читателей:

«А что если выход нового релиза не связан с изменениями в функционале воспроизведения и потоковой передачи видео? Например — что если в новом релизе будет изменено что-то, ответственное за вход пользователя в систему? Тестируя такой релиз вы, как и в других случаях, так же будете наблюдать за метрикой «задержка воспроизведения»?»

Привет, Хабр! Из этой статьи вы узнаете про применение последовательного A/B‑тестирования в Netflix.

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

Спустя время появляется новый тикет, но внутри лишь пара строчек и скриншот. Вздохнув, вы пробуете воспроизвести баг по этим данным, но ошибки нет. Пробуете несколько раз, но в итоге пишете тестировщику, что баг не воспроизводится и начинается новый цикл уточнений. Тратите время, которое могли потратить на решение новых задач, исправление других багов, просмотр аниме, рефакторинг.

Меня зовут Евгений Домнин, я QA и постараюсь поделиться видением, что делает баг репорт хорошим. Прошу простить за долгое вступление, давайте начнем.

Всем привет, меня зовут Александр Матюшенко, я инженер по автотестированию в одной из платформенных команд в Альфа-Онлайн. В статье хочу рассказать, как внедрить функционал скриншот-тестирования в проект E2E автотестов с использованием библиотеки aShot от Yandex. Возможно, в этой статье я добавил излишне много кода на Java, но хочется более подробно показать, как это работает.

Многие команды используют глобальную настройку для входа в приложение и последующего использования этой настройки для тестов, которые должны выполняться в авторизованном состоянии. Однако у такого подхода есть несколько важных ограничений. Например, при использовании глобальной настройки вы не видите трейсы для этапа настройки тестов, и этот этап настройки не отображается в HTML-отчёте. Кроме того, глобальная настройка не поддерживает использование фикстур.

Для решения этой проблемы создаются проектные зависимости.

Автоматизация тестирования приложений является важным элементов в обеспечении процессов CI/CD. В этой статье мы поговорим о практическом использовании инструмента с открытым исходным кодом Locust для проведения нагрузочного тестирования приложений.

Дубай позиционируется как место для комфортного бизнеса, крупный финансовый центр и перекресток торговых путей. Однако попытка организовать комфортный удаленный доступ в или из Дубая, наталкивается на неожиданные трудности. Результаты поиска причин в интернете настолько скудны, будто кто-то скрыл необходимую информацию. В таких случаях, ничего нельзя утверждать, а только иметь свое “Highly likely”. Всем  кто рассматривает Дубай или похожие  локации как часть своей ИТ инфраструктуры.

Привет! Меня зовут Бальцер Вадим, я QA-инженер в команде android направления Банки.ру. Сегодня поделюсь нашим опытом внедрения автотестов обратной совместимости и интеграции их в CI. 

В материале расскажу: 
1) зачем нашей команде понадобились автотесты для контроля обратной совместимости API, почему мы выбрали Postman CI.
2) с чего начали: базовые вещи + полезные советы для начинающих.
3) есть ли жизнь за гранью проверок схемы.
4) CI и интеграция с ТестОпс.
5) к чему пришли и какие перспективы видим.

Также добавлю примеры примеры кода и небольшие советы, которые могут пригодиться, если вы еще только присматриваетесь к Postman как к инструменту автоматизации проверок API.

Проектирование A/B-экспериментов может быть сложным процессом, особенно для тех, кто только начинает работать с аналитикой и тестированием в мобильных приложениях. Нередко возникают проблемы с формулировкой гипотез, выбором метрик и определением оптимального распределения аудитории.

На связи Алексей Андриянов, менеджер продукта в RuStore. В этой статье на простом примере мы рассмотрим, как правильно подойти к постановке гипотезы и избежать распространенных ошибок при тестировании изменений в мобильных приложениях.

Функциональное тестирование стало неотъемлемой частью процесса обеспечения качества в веб-разработке. В этой статье рассмотрим возможности Playwright — мощного инструмента для автоматизации тестирования.

Playwright — это библиотека для автоматизации браузеров, разработанная командой Microsoft. Она позволяет взаимодействовать с веб-приложениями так, как это делает пользователь, поддерживая работу с несколькими браузерами, включая Chrome, Firefox и Safari. Главная фича Playwright заключается в его способности работать не только с браузерами, но и с мобильными приложениями.

В мире разработки ПО поддержка высокого уровня наблюдаемости (observability) для приложений с архитектурой, управляемой событиями (event-driven architecture, EDA) стало критически важным. Сложность таких систем, связанных с обработкой огромных объемов данных в режиме реального времени, требует надежных инструментов для мониторинга, отладки и анализа. Однако традиционные методы, использующие логи и метрики, часто оказываются недостаточными, когда необходимо глубоко понять взаимодействие между различными компонентами системы и выявить узкие места.

Именно с этой проблемой мы столкнулись в нашей команде, поэтому я, Дмитрий Титаренко (QA-инженер в компании TAGES), решил поделится найденным решением в статье на Хабр. Надеюсь, что будет полезно!

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

Современные команды разработки тестируют каждое изменение кода перед мержем. Это не просто общепринятая традиция: наряду с ревью кода, это стандарт по умолчанию, применяемый практически во всех кодовых базах компаний. Мы называем его тестами CI (непрерывной интеграции). В результате их внедрения среднестатистическая организация запускает сотни наборов тестов в день.

В прошлом непрерывное интеграционное тестирование было с нами не всегда, в отличие от обычного тестирования. По моим наблюдениям, CI — это результат того, что тестирование всё больше ускоряется. Разберёмся, как это произошло и как тестирование будет ускоряться дальше.

Если вы хотите пощупать GraphQL API с ТЗ на русском языке, то добро пожаловать в мою песочницу — систему Cards.

Тут есть пользователи и их банковские карты. Можно пополнить баланс банковской карты, можно переводить деньги с одной карты на другую. Есть графический интерфейс и API. Есть даже ролевая модель! И даже ТЗ есть, хоть и не супер подробное =)

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

Конечно, сейчас уже есть инструменты на базе искусственного интеллекта, такие как GitHub Copilot, ChatGPT и Claude, которые пытаются облегчить нам жизнь. Но давайте будем честны — они также заставляют нас желать большего.

Вам когда-нибудь хотелось, когда вы активно погружались в сложный проект, чтобы ваш AI-помощник видел всю картину в целом? Например, понимал общую архитектуру, ваш стиль кодирования и специфические особенности проекта?

Вот тут-то и приходит на помощь Cursor.

Всем привет! Нагрузочные тесты за 5 минут (ну почти).

Не так давно делился историей о том, как решали проблему E2E автотестов в маленьком проекте. Продолжим историю).

Когда фича «протестировать табуретку» вызывает нервный смех у тестировщиков и недоумение у менеджеров, пора разобраться, как на самом деле работает тестирование. Привет, Хабр. Меня зовут Елизавета Лященко, я работаю тестировщиком 5 лет, из которых 1.5 года в Самолете, и сегодня разложу по полочкам весь цикл проверки — от странных требований до стресс-тестов и финального релиза. Мы узнаем, почему тестировщик задает миллион вопросов, чем его работа отличается от «я всё проверил, всё ок» и как тестирование спасает команду от хаоса. Ну и готовьтесь увидеть табуретку так, как вы ещё никогда её не видели!

Интеграционное тестирование нередко вспоминают на собеседованиях, когда спрашивают о видах и уровнях тестирования. И, как любую теорию, его сложно понять в отрыве от практики. В этой статье разбираем тестирование интеграций на конкретных примерах.

Привет! Меня зовут Данила, я фронтенд-тимлид в KTS.

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