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

Привет, Хабр! Меня зовут Егор, я руководитель Центра компетенций обеспечения качества SM Lab. И именно про наш центр компетенция я и хочу рассказать. Статья пригодится не только тестировщикам, но и разработчикам и аналитикам. Ведь тестирование — это не только поиск багов, но и создание культуры качества. 

Обсудим состав и механику работы нашего ЦК, продуктовые команды, а также немного подискутируем на тему тестирования в целом — каким оно будет в будущем, как на него повлияет ИИ и автоматизация.

Каждую ночь тысячи автотестов отрабатывают на бою, и сотни падений превращаются в рутину для QA-команд. Но что если привычный разбор ошибок можно отдать искусственному интеллекту — и самому сосредоточиться только на новых, действительно значимых сбоях? В этой статье — реальный опыт внедрения ReportPortal, который показывает, как ИИ помогает классифицировать падения, экономить время тестировщиков и снижать количество человеческих ошибок, не превращаясь при этом в «волшебную чёрную коробку».

Всем привет! Я Полина Спиридонова, product owner двух продуктов для подготовки специалистов по защите информации — Standoff Cyberbones и Standoff Defend.

В статье я расскажу, как мы прошли путь от формулирования идеи из вопроса «Как создать полигон для синих команд?» до запуска Standoff Defend — инструмента, который помогает командам SOC становиться сильнее. Давайте погрузимся в детали и узнаем, как все начиналось и к чему мы пришли.

Хочу рассказать об опыте пилотирования собственного решения компании — Kaspersky NGFW — с точки зрения специалиста по информационной безопасности.

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

В предыдущих частях работы (Часть 1, Часть 2) мы разобрали, что такое линейный конгруэнтный метод (ЛКМ), и как на его основе работает функция Rnd(), вшитая в скриптовый язык VBA, созданный Microsoft. Именно эта функция и "ответственна" за генерацию псевдослучайных чисел. Мы поняли, как ведет себя функция, если в качестве ее аргумента ввести число меньшее либо равное 0. Также мы выяснили, что эта функция работает с мнимым и реальными значениями своих аргументов, также мы поняли, как соотносятся некоторые мнимые значения аргумента функции с их реальными значениями.

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

В статье — эволюция поисковиков и практические хаки для работы: скрытые операторы, малоизвестные команды Яндекса и Google, промпты для Perplexity и Gemini, техники точной фильтрации и ИИ-подходы.

Рассказываю, как превратить 5 кликов в один и получить выдачу с точностью SQL.

Мне нравится Scaled Agile Framework (SAFe), и я вброшу вам несколько идей по тестированию с точки зрения этого фреймворка.

Часто вижу, что во многих компаниях одной из ключевых метрик является количество найденных тестировщиком дефектов. Хочу донести мысль: от этой метрики можно смело отказаться и жить в прекрасном мире Agile-разработки! 🚀

🤯 Когда вы начинаете считать баги, найденные тестировщиком, происходит вот что:

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

В этой статье мы разберемся:

• чем отличаются методологии «черного», «серого» и «белого ящика»;

• какую из них выбрать под конкретные риски;

• как подготовиться к тестированию, чтобы не тратить деньги впустую;

• и почему даже «зеленый» отчет сам по себе — не повод выдыхать.

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

Это история о попытке создать новую логику.

О попытке, рожденной в эпоху, когда фракталы Мандельброта казались ключом ко всей природе. Я, логик по образованию, увидел аналогию: если математические "монстры" оказались фракталами, то, может быть, логические парадоксы — это тоже фракталы?

Я построил концепцию, где смысл — не точка, а процесс, бесконечный и самоподобный. Но концепция осталась без семантики.

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

Qwen, стремясь к формализации, строил сложные системы. DeepSeek, как строгий судья, разрушал их одну за другой, обвиняя в "иллюзии формальности" и "магии".

В этой битве не было победы. Но из обломков моей идеи родилось нечто ценное: понимание того, что истина в сложности не в построении новой системы, а в способности видеть старые проблемы по-новому.

Это — отчет с поля боя за семантику.

Автоматизация тестирования — это не только про стабильность и скорость, но и про понимание причин падений. В этой статье практические приёмы, которые помогут сделать Playwright-тесты не просто «зелёными», а по-настоящему надёжными и понятными. Разберём, как:

— подключить минимальный набор инструментов для диагностики;
— улучшить читаемость отчётов;
— использовать кастомные ассерты для более информативных ошибок;
— выбрать подходящие репортеры под разные роли в команде;
— и даже применить AI для автоматического анализа падений.

Материал будет полезен QA-инженерам и автоматизаторам, работающим с Playwright, а также разработчикам, тимлидам и менеджерам, которым важно получать прозрачную картину состояния автотестов. 

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

В этой статье я покажу, как построить гибкий и масштабируемый подход к тестированию фильтрации с помощью Playwright + TypeScript, используя: Page Object Model, Data-driven testing, конфигурацию фильтров и кастомные фикстуры.

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

Сегодня рассмотрим недавно вышедшую модель 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, чтобы каждая фича доказывала свою устойчивость перед релизом;
● научились предсказывать поведение системы не на глаз, а по данным — даже при росте объемов в несколько раз.