Можно ли сделать e2e тесты мощным инструментом раннего отлова багов, не потопив при этом CI и не всем не разругавшись?
Рассказываю, через что пришлось пройти, чтобы релизы были спокойные, пайплайны — зеленые, разработчики — довольные.
Как мы это внедряли, сколько сопротивления получили и что из этого выжило спустя четыре месяца.
Интуитивно любой разработчик понимает: чтобы выпуски проходили спокойно, нужно написать автоматизированные тесты. Чем больше тестов, тем спокойнее проходят выпуски. Или нет?)) В этой статье я поделюсь нашим опытом построения пирамиды тестирования. Надеюсь, что она понравится читателям и станет первой из цикла статей об автоматизированном тестировании. Нам есть что рассказать!
Часто кажется, что тестирование пуш-уведомлений – одна из самых простых задач: отправил, получил, кликнул. Если текст отображается корректно, и ссылка открывается, задача считается выполненной.
Однако в финтехе цена ошибки измеряется не только временем, но и реальными деньгами. Для нас, как для команды обеспечения качества, пуш-уведомления – это не просто текст на экране, это обещание пользователю. Обещание того, что клик приведет его к решению задачи быстро, безопасно и без потери контекста. Сломанный диплинк в уведомлении о волатильности актива может привести к тому, что трейдер не успеет закрыть позицию и потеряет часть депозита. Если навигация ломается, пользовательский сценарий прерывается, и клиент остается один на один с проблемой.
В Centicore Group мы подходим к проверке диплинков и пушей не как к сухой технической задаче, а как к части пользовательского опыта. Разберем, где скрыты основные риски и как выстраивать мышление качества в этом направлении.
А еще мы с командой решили провести небольшой конкурс. Мы подготовили для QA-инженеров виз с вопросами - отличная возможность проверить свои знания и просто интересно провести время за чашкой кофе (или в перерыве между прогоном регрессии). Взамен - приятный бонус в виде подарков для тех, кто успешно пройдет тест.
Об условиях конкурса и подарках можно узнать по ссылке - Квиз для QA
А теперь к контексту
Диплинк, как контракт между бизнесом и пользователем
Диплинк в инвестиционном приложении выполняет роль навигационного контракта. Когда клиент видит уведомление о смене цены или статусе заявки, дизайн системы предполагает, что тап по нему сразу откроет экран для принятия решения.
Проблема возникает, когда мы рассматриваем диплинк исключительно как технический URL. На деле это сложный объект с метаданными: идентификаторами инструментов, параметрами сессии, источниками триггеров. Фокус тестирования меняется: мы проверяем не только работоспособность ссылки, но и ее соответствие текущему контексту.
Важнее проверить пограничные состояния, например, что увидит клиент, если актив уже делистингован, а чат поддержки временно недоступен? В нашей практике мы заменяем технические ошибки на понятные заглушки: вместо белого экрана или кода 404 пользователь видит сообщение «Актив больше не торгуется» или «Раздел временно недоступен» с предложением вернуться в портфель или написать позднее.
Задача качественного тестирования навигации – минимизировать риски «тупиковых» сценариев. Если целевой экран недоступен, система должна мягко перенаправить пользователя, объяснив причину и сохранив рабочий контекст. Это прямое уважение к его времени.
Матрица состояний: уважение к контексту
Одна из самых сложных задач при тестировании пушей – учет состояния приложения в момент клика. Пользователь взаимодействует с устройством по-разному, и навигация должна адаптироваться. Мы выделяем несколько ключевых сценариев:
Распределенная система может сломаться так, что по отдельности все ее части будут выглядеть исправными.
Представим обычную оплату заказа: сервис отправил запрос платежному провайдеру, тот списал деньги и вернул успешный ответ. На обратном пути соединение оборвалось. Для платежной системы операция завершена, а сервис заказа получил тайм-аут и не знает, произошло списание или нет.
Самое очевидное решение — повторить запрос. И получить второе списание.
В монолите подобные ситуации встречаются реже: операция обычно проходит внутри одного процесса или одной транзакции, поэтому место сбоя проще определить. В распределенной системе между началом и концом одной бизнес-операции могут быть несколько сервисов, брокер сообщений, разные базы данных и внешний API (интерфейс программирования приложений). У каждого компонента при этом свое состояние и свое представление о том, что уже произошло.
Так, проверки «отправили запрос — получили ожидаемый ответ» здесь недостаточно. Интереснее проверить, что будет, если ответ задержится или потеряется, запрос придет повторно, события поменяются местами, а один из сервисов восстановится после нескольких минут простоя.
В таких ситуациях проявляются ошибки, которые сложно увидеть на happy path (позитивном сценарии). Ниже разберем, как их воспроизводить и что проверять, чтобы отказ одного компонента не превращался в некорректное состояние всей системы.
Почему распределенную систему нельзя тестировать как обычное приложение
Возьмем простой пример — оплату заказа в интернет-магазине.
Компании годами ищут «золотой стандарт» тестирования, один набор правил для любого проекта. Такого стандарта нет и не появится. Одинаковые правила либо задушат лёгкий проект дорогой инфраструктурой, либо оставят критическую систему с серьёзными уязвимостями.
Как выстраивать процессы контроля качества под конкретный продукт, рассказала Светлана Иванова, ведущий инженер по автоматизации тестирования в М.Тех (технологическое подразделение М.Видео).
Как отделить платные enterprise-функции от open-source кода так, чтобы их нельзя было взломать с помощью ИИ — показываю на примерах Dokploy и Pangolin.
Авторизация — это сложно… Хотя казалось бы — самая частая используемая фича в мире. Очень многие процесы завязаны на авторизации и аунтентификации. Начиная от ваших любимых соц сетей и заканчивая редакторами кода.
Привет! Сейчас покажу штуку, которую я довольно долго доводил до ума, и мне кажется, она может пригодиться не только мне.
Задача звучит скучно: нагенерировать тестовые карточки людей. Пол, имя, диагноз. Скучно ровно до того момента, пока не посмотришь, что получилось:
Меня зовут Константин Кузнецов, в ПСБ я занимаюсь, в числе прочего, поддержкой ИТ-инфраструктуры.
В этой статье я расскажу о том, как концепция инфраструктурного релиза помогала формировать процессы обеспечения идентичности сред.
Если вы начинающий специалист в области ИТ-инфраструктуры, который видит своё будущее в ИТ-менеджменте — эта статья для вас. Думаю, вам будет полезно ознакомиться с вызовами и олдскульными способами их решения, основанными частично на ITIL, частично на devops.
Меня зовут Алексей Тиньков, я занимаюсь тестированием производительности уже 8 лет. В первой статье цикла хочу поделиться своим опытом организации процесса нагрузочного тестирования (НТ), рассказать о том, как правильно думать о тестировании производительности и чем оно принципиально отличается от привычного функционального тестирования.
Есть класс ошибок, которые проходят все ручные проверки и спокойно доезжают до продакшена. Не пятисотки, не пустые поля, не сломанная структура — с этим как раз всё в порядке. Речь про случаи, когда сервис отвечает статусом 200, все поля на месте, типы правильные, и при этом одно число посчитано неверно.
Расскажу, как я проверяю такие ответы, когда в команде нет автотестов и в ближайшее время не появится: писать и поддерживать код некому, а сверка ответа с документацией делается глазами. Подход применим в любом инструменте, я просто покажу его на своём рабочем сценарии — создании заказа с расчётом скидки.
Приветствую, Хабр! Меня зовут Владислав Тимашенков, я занимаюсь автоматизацией тестирования в ГК Infowatch.
В этой статье мы построим основу лаконичного фреймворка для UI-автотестов. Настроим запуск браузера, подготовим авторизацию, создадим Page Object и напишем тест. Здесь не будет лишних обёрток и сложной инфраструктуры, не будет даже ИИ и прочего хайпа. Только проверенные решения на базе Playwright, готовые к использованию.
Главная идея — максимально использовать возможности самого Playwright, а не строить вокруг него собственный слой абстракций.
В статье я разберу, как писать тесты, используя Playwright. И покажу все на собственном примере.
Когда наш продукт стал сложным, мы столкнулись с тем, что релизы стали затаскивать на прод баги. Чтобы не “тестировать на пользователях” и минимизировать человеческий фактор, мы решили автоматизировать самые частые пользовательские сценарии, используя Playwright.
Давайте перейдем к сути и начнем писать тесты на Playwright.
Я делаю NotiBox — Pusher‑совместимый сервис realtime уведомлений. Под капотом я использую Sockudo — WebSocket сервер на Rust. Прежде чем показывать реальным пользователям, я решил проверить, на сколько Sockudo на самом деле «blazingly fast».
Я ожидал, что это будет лёгкая прогулка, типичное тестирование нагрузки. Даёшь мало ресурсов серверу, запускаешь бенчмарк, видишь что он захлёбывается запросами в какой‑то момент, и фиксируешь показатели.
Идеальный сценарий — полная загрузка процессора, памяти или сети, тогда ты реально нашёл предел ресурсов. Проверяешь масштабируемость и готово.
Другой сценарий — ничего не перегружено, но новые соединения/запросы не проходят, растёт задержка ответов. Это тоже ожидаемо и понятно как чинить: смотришь на TIME WAIT сокеты, max open files, и другие «предохранители».
А что делать, если там тоже всё по нулям? Вот тут начинается настоящее приключение.
Переход с Selenium на Playwright часто заканчивается теми же флаками, долгими прогонами и ручными ожиданиями.
Разбираем семь ошибок Java‑миграции и показываем, как перестроить тесты под возможности Playwright.
Половину контрактов моего игрового сервера нельзя записать ассертом: исход живёт в ответе живого процесса, в разметке страницы и в кадре игры. Я записал их таблицами «дано → действие → ожидание», а прогоняет их агент. Рассказываю, как устроен контур проверки кода, который пишет ИИ: контракты вместо юнит-тестов, ревью, где находку надо доказать, и граница, за которую машину не пускают.
Последние годы стали серьёзным испытанием для тестирования.
Нейросети существенно ускорили разработку кода: интеграция ИИ-помощников в IDE позволила за минуты решать задачи, на которые раньше нужны были часы. Качество иногда страдает, но высвобожденное время в сумме даёт положительный эффект, и в итоге количество поставляемого кода резко растёт.
В то же время пропускная способность QA принципиально не изменилась. Тестировщики тоже пользуются нейросетевыми помощниками, но им для успешной работы обычно нужно больше контекста — а значит, больше инфраструктуры.
В этой статье я хочу привлечь внимание к тому, насколько большую роль подготовка данных играет для нейросетей в QA. Конкретно, речь пойдёт о группировке падений перед анализом их причин. Я буду анализировать запуски инструментом для автоматической отладки багов — playwright-ai/auto-debug.
Часто приходят ребята после курсов по пентесту (так уж вышло в ходе профессиональной деятельности) и спрашивают что им делать дальше.Так как я по ходу работы занимаюсь обучением пентестеров уже как года 3 и их дальнейшей судьбой и у нас есть свой офлайн клуб по пентесту в городе я решил поделиться своим видением на эту тему Так как сейчас ситуация выглядит следующим образом:
1) Человек ранее не занимавшийся айтишкой решает что он хочет в пентест
2) Проходит курсы (не буду называть какие разные)
3) Начинает откликаться на вакансии
4) И оказывается в одиночестве
Самый интересный момент тут на пункте 3. Что происходит. Вакансий мало. Ребят много. Конкуренция дикая на пентестеров. Вакансий почти нет. На рынок выброшено куча ребят. Потом они приходят и говорят. Либо я отправил резюме и 0 собесов. То есть оно просто не дошло до hr потому что AI фильтры посмотрели на строчки закончил курсы реального опыта 0 - значит false.
Либо. В более лучшей форме человек доходит до собеса. И получает что-то вроде этого:
Как выбрать аналитическую СУБД, если одна быстрее, другая проще в эксплуатации, а третья лучше поддерживает нужный SQL? Рассказываю о нашем исследовании: TPC-DS и SSB, экспертные критерии и метод комплексной оценки с расчётом, который можно повторить на своих данных.
Всем привет, Я Артур Валиев, Не хотелось но на этот раз я все-таки попрошу гуся что-бы помог рассказать мою историю.
Три дня назад я сидел и сравнивал integrity level токена процесса с integrity level окна в фокусе, чтобы понять, почему Диспетчер задач блокирует ввод удалённого пользователя. Никто в мире, кроме меня, в этот момент не знал, что это вообще проблема. Я был там один. И мне было хорошо.