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

Сегодня рассмотрим недавно вышедшую модель ChatGTP-5.

Посмотрим на сведения которые новая модель скрытно собирает о пользователе, обновленный системный промпт, и под конец покажу рабочий jailbreak.

Привет! Меня зовут Ваня Тришкин, я тестировщик в KTS.

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

Сегодня я не просто опишу панель DevTools, а приведу примеры сценариев, в которых она может понадобиться менеджеру. Заодно для каждого инструмента я дам небольшие упражнения, которые помогут закрепить материал и увереннее пользоваться тулзами на практике.

Привет! Я Леша Севальников, старший QA-инженер в команде, которая занимается разработкой бэкенд-сервисов для хранения, предоставления и актуализации данных о юридических лицах. 

Почти пять лет работаю в Т-Банке, где с нуля организовал тестирование в своей команде. За это время я успел пройти путь от ручного до автоматизированного тестирования, встроить и автоматизировать нагрузочное тестирование и многое другое. 

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

Всем привет! Меня зовут Семён Эйгин, я бэкендер в Авито, люблю опенсорс и периодически что-то туда контрибьючу. В этой статье разбираемся с моками и выбираем самый удобный инструмент (не обязательно лучший!). Это достаточно холиварная тема, хотя при подготовки статьи я не ожидал, что она окажется настолько спорной — у каждого разработчика своё мнение на этот счёт. Чтобы узнать моё и высказать своё — переходите под кат!

Привет, Хабр! Меня зовут Константин Бессонов, и я — ведущий инженер-тестировщик в компании «Столото», где уже шесть лет участвую в тестировании и управлении процессами.

Эта статья — моя история о том, как я пришёл в тестирование без опыта, как готовился к собеседованиям, какие ошибки совершал, а главное — как за несколько лет вырос от новичка до руководителя группы. В процессе пути сталкивался с волнением перед первым релизом, автоматизировал процессы через Postman, осваивал SQL, Linux и понял, что в IT важны не только навыки, но и желание учиться.

Спойлер: если вы думаете, что в IT можно попасть только с идеальным резюме или опытом программирования — вы зашли не в ту статью.

В этой статье расскажу, как выбрать правильную компанию, найти наставников, развивать soft skills, почему важно записывать всё новое.

Mock-сервисы (или мок-сервисы) — это программные компоненты, которые имитируют поведение реальных сервисов, систем или зависимостей в процессе разработки и тестирования приложений. А мы сделали свой.

Последнее время все чаще появляются продукты, которые скрещивают LLM и TMS — и получается магия! ✨

Свежий пример: ▶️ Gen-A: как искусственный интеллект переворачивает тестирование

Плюсы таких решений очевидны. Минусы тоже есть: у всех свои TMS, конфлюенсы и прочие инструменты. Как это затянуть в свой контур? 🤔

И давайте честно, LLM есть у многих, но не у всех есть AI-команды, которые делают такие красивые большие продукты. А у меня есть ощущение, что стоимость таких продуктов, пока они на волне, как крыло от самолета

Что делать? Есть решение - MCP - Model Context Protocol.

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

В этой статье расскажем, как мы:

● автоматизировали нагрузочное тестирование, сократив ручную работу инженеров на 85%;
● встроили стресс-тесты в CI/CD, чтобы каждая фича доказывала свою устойчивость перед релизом;
● научились предсказывать поведение системы не на глаз, а по данным — даже при росте объемов в несколько раз.

Основан на pluggy. Основная единица pytest - pytest плагин. Написан достаточно интересно. Ключевое слово - “ключевое слово”. Основное взаимодействие в pytest происходит через хуки. Хук это некий этап к которому можно получить доступ к той или иной логики работы. Следуя из названия это некоторые крючки за который можно цепляться вставляя свои заплатки. Начинаются с pytest.

Фикстуры (Fixture) в  pytest это некий аналог мока/сетап tear down в unittests.  Это некие кусочки кода результаты которых могут быть пере использованы. Сами фикстуры реализованы как плагин. 

Как уже говорилось в эта система плагинов полагается на Pluggy. В Pluggy програамма полагается на PluginManager который управляет сохранения спецификаций хуков регистрацией плагинов и вызовом их. Плагины могут регистрировать сами себя в PluginManager.

Когда хук стартуют они вызывают свои имплементации по умолчанию как LIFO очередь - самый поздний элемент вызывается раньше всего. Для изменения этого порядка вызова можно применять trylast or tryfirst свойства в их имплементациях(пример). По умолчанию возвращается результат от всех имплементаций с исключением случая с как  firstresult свойством. В случае свойства firstresult программа возвращает результат первого не None результата. 

Другое интересное свойство имплементации плагина это hookwrapper.  С помощью этого свойства имплементации будут вести себя как обертки над другими хуками с помощью yield.

Вдохнули?

Хуки вызываются 3 способами:

Делюсь опытом сборки отчетов Allure 3, можете стабильного релиза не ждать, он и в beta очень хорош.

Статья синьорская, под капотом все что нужно.

Развитие IT-технологий приводит к очевидному росту различных киберпреступлений, осуществляемых посредством взлома этих самых IT-технологий. Чтобы защищаться от таких посягательств, владельцы программ, сервисов, крупных IT-систем вынуждены самостоятельно заказывать такие взломы у сторонних лиц с целью выявления уязвимостей и их устранения. Такой процесс называется «пентестом», и помимо технической составляющей здесь присутствует очень много юридических нюансов, потому что взламывать – незаконно (сюрприз, да?). Давайте разбираться.

Если вы когда-либо писали автотесты для веб-приложений с элементом canvas, то наверняка знаете, как это может быть непросто. Canvas — это "чёрный ящик", где привычные инструменты UI-тестирования бессильны: внутри нет DOM-структуры, за которую можно зацепиться. При этом на экране canvas может отображать что угодно — от графиков с осями X и Y до сложных анимаций.

Хотите узнать, как автоматизировать тестирование canvas без лишней боли? Давайте разберёмся на простом примере.

Что должен знать и уметь успешный тестировщик? Знания и опыт не появляются сами по себе: у каждого QA есть свои книги, статьи и ресурсы, которые помогли ему начать и освоиться в сфере тестирования.

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

Если надоело открывать Postman и вручную запускать каждую коллекцию или проверять эндпоинты по очереди, то решение есть — Newman, терминальный раннер от команды Postman. Его функционал позволяет:

автоматически выгружать все коллекции и окружения,

запускать их прямо из командной строки,

получать отчёты для анализа или интеграции в CI/CD.

В этом кейсе покажу путь от экспорта коллекций до автоматического прогона тестов через Newman CLI.

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

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

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

В лучшем случае вы получите бесполезный список из сотни мелких «дыр» в принтерах и кофемашинах. В худшем — пентестеры случайно обрушат производственную линию или устроят DDoS на Active Directory. А между этими крайностями лежит целый спектр проблем: от юридических рисков, если в документе не очертить скоуп и команда выйдет за рамки дозволенного, до банального несовпадения ожиданий и результатов.

Однако всех этих неприятностей легко избежать, если подойти к планированию внутреннего пентеста основательно. В этой статье разберем, почему техническое задание — не формальность, а жизненно важный документ, и покажем, как его правильно составить. Кто-то возразит, что это утопия, и в реальности все работают иначе, но нам бы хотелось это изменить. Поверьте: оно того стоит.

Чаще всего мы падаем не на сложных алгоритмах и не на асинхронных гонках. Главные враги — самые простые куски кода, те, на которые даже не хочется тратить внимание. В этой статье я делюсь опытом и наблюдениями о том, как «архитектура сомнений» помогает не доверять очевидному, и почему программисту полезно быть немного параноиком.

Jira — это гибкая система отслеживания задач и багов от Atlassian, которая помогает командам разработки и тестирования вести единое хранилище требований, задач и дефектов. Позволяет ловить баги и фичи на одном бэклоге: по словам Atlassian, в Jira можно «уловить, отследить, решить и отчитаться о багах и проблемах» на протяжении всего процесса разработки.

При этом инструмент предлагает «единый вид всех элементов бэклога — будь то баг или задача по новому функционалу», что помогает приоритизировать общие цели команды. Это значит, что QA могут иметь в Jira общее пространство тест‑кейсов, задач на тестирование и найденных дефектов.

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

Статья будет полезна для всех участников QA‑команд (тестировщиков, тимлидов), кто базово уже разбирается с инструментом и хочет в него углубиться.

В каждом собеседовании наступает момент, когда интервьюер говорит: «Какие у вас есть вопросы к нам?». Для большинства это вежливая формальность. Для сильного специалиста — это главный этап собеседования, на котором уже он оценивает компанию.

Ваши вопросы — это не просто способ узнать про ДМС и формат работы. Это диагностический инструмент, который позволяет за час понять то, что другие узнают за месяцы испытательного срока: реальные процессы, настоящую культуру и истинное отношение к качеству. Ответ «вопросов нет» почти всегда говорит о слабой заинтересованности или поверхностном понимании профессии.

Это руководство поможет вам превратить список вопросов в системный подход к оценке будущего работодателя.