⬅️ «Перфоманс Лаб» вошла в топ-3 крупнейших поставщиков услуг тестирования ПО в России по версии TAdviser ➡️

Компании оценивались по выручке от услуг тестирования, динамике роста и масштабам проектов.

Топовая позиция в рейтинге показывает, что мы остаемся устойчивым независимым игроком на российском рынке тестирования ПО. При этом ​по оценке TAdviser спрос на услуги по обеспечению качества продолжает расти.

📌Наш результат обеспечен не только проектами для крупных заказчиков из финансового и корпоративного сектора, но и развитием собственных продуктов и услуг в области тестирования.

✔️Благодарим за доверие и совместную работу — именно она позволяет развивать экспертизу и двигаться дальше!

⬅️Пять ключевых QA-трендов 2025-2026: как ИИ, DevOps и безопасность меняют тестирование➡️

Рынок тестирования меняется быстрее, чем когда-либо. Скачок ИИ-технологий, рост DevSecOps, нагрузки от LLM-сервисов и переход на no-code-автоматизацию формируют новую реальность.

📌Что нужно знать, чтобы команда оставалась эффективной и востребованной?

В новой статье Александр Канатов, директор департамента функционального тестирования «Перфоманс Лаб», разобрал пять мировых трендов, которые нельзя упустить из виду в новом году.

✔️Главный вывод: будущее QA — не за теми, кто пишет больше тестов, а за теми, кто делает продукт надежнее, быстрее и безопаснее через каждое свое действие.

🎙Обезличивание данных в базах: в чем сложность и как организовать процесс

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

В статье Петр Мельченко, лид команды разработки в «Перфоманс Лаб», и Василий Жидков, продакт-менеджер инструмента «Датасан» делятся уникальным опытом: разбирают подводные камни, через которые проходят все команды, пытаясь организовать обезличивание в больших системах. И, конечно, дают решения, чтобы пройти этот путь быстро и без проблем.

➡️ Как правильно выделить и обработать персональные данные? Например, как автоматически выделить именно ИНН, а не произвольный набор цифр?
➡️ Технические сложности профилирования: категоризация данных, сборка движка.
➡️ Тонкости деперсонализации: работа с проблемными сущностями, правильные настройки баз данных и таблиц.
➡️ Оптимизация алгоритмов обезличивания: как распараллелить процессы, пересобрать логику и выстроить работу планировщиков.

⬅️Совмещать тестирование и управление: табу или нормальная практика?➡️

В ИТ до сих пор гуляет мнение: «Либо тестируй, либо управляй. Третьего не дано».
Но на практике у QA-лида внезапно оказывается в подчинении 4 команды, 5 тестеров и один «зеленый» проект, на котором нужно ещё проводить ручные тесты.

Что делать, когда ролей две (или больше) — а голова одна? Наш опыт показывает: совмещение — не ошибка, если превратить его в систему:

📌 Разделяй и властвуй по времени
Попытка быть лидом и тестировщиком одновременно в один и тот же час — прямой путь в выгорание. Работает другой подход: фиксированные «окна» под каждую роль. Сегодня до обеда — только тесты. После обеда — только люди и процессы. Команда привыкает, стейкхолдеры подстраиваются, хаос отступает.

📌 Автономность ≠ бесконтрольность
Ошибка думать, что если команда опытная, она «как-нибудь сама». Без регулярной связи с командой проект превращается в хаос. Выход — не в ежедневных командных встречах, на которых половина команды томится, а в коротких, но регулярных касаниях. Викли в понедельник, четкая рутина 1:1 (пусть не еженедельных, это роскошь), чтобы слышать каждого. Этого бывает достаточно, чтобы заметить проблему до того, как она станет критической.

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

✔️ И главное, что мы поняли:
Совмещение ролей — нормальная ситуация для растущих команд и компаний в переходной фазе. По исследованиям распределения управленческого времени (в том числе в рамках подходов time blocking и managerial leverage), ключевой риск не в количестве ролей, а в постоянном переключении контекста. Именно оно переключение, а вовсе не объем задач, быстрее всего ведет к выгоранию.

Так что главный вопрос — не «можно ли совмещать», а «как снизить цену переключения».

⬅️26 февраля состоится онлайн-подкаст по теме "Диалоги о персданных. Как не преступить черту закона: Технические средства и реальные кейсы."➡️

Встреча для CISO, CIO и DPO, которые ежедневно балансируют между привычной механикой разработки и требованиями регуляторов.

📌Фокус — обезличивание персональных данных в тестовых и dev-средах. В эфире обсудим, где компании чаще всего ошибаются, разберем недавние инциденты и покажем, как происходит обезличивание реальных данных на примере решения Датасан от «Перфоманс Лаб».

Почему стоит подключиться:
➡️Узнаете, как минимизировать риск утечек и претензий надзорных органов;
➡️Увидите живую демонстрацию деперсонализации в действии;
➡️Сможете задать свои вопросы экспертам и обсудить специфику ваших систем.

🎙Спикеры:
Егор Говорков — продуктовый маркетолог Перфоманс Лаб
Василий Жидков — владелец продукта Датасан
Петр Мельченко — техлид Датасан

📌Для трёх участников предусмотрен бесплатный пилотный проект решения Датасан на реальных данных.

➡️Регистрация на онлайн-подкаст⬅️

Дата: 26.02.2026 11:00 МСК
Формат: онлайн, с живым диалогом и Q&A
Регистрация обязательна. После заявки участники получают персональную ссылку на подключение.

Команда Перфоманс Лаб ждет ваших!

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

📍На форуме «Технологии и безопасность» поделились, как избежать проблем и соблюсти все требования закона.
Особенно уязвимый процесс — передача базы сторонним подрядчикам: объяснили, как качественно обезличивать данные и экономить ресурс.

🎙Спикером выступал эксперт по обезличиванию персональных данных в тестовых средах и фискализации данных, владелец продукта «Датасан» Василий Жидков.

Тема: «Как избежать штрафов за утечки персональных данных с помощью обезличивания»
➡️Новая регуляторика. Сколько теперь придётся заплатить за утечку?
➡️Методы защиты. Обезличивание персональных данных для сред разработки и тестирования и передачи третьим лицам.
➡️Встраивание обезличивания в цикл разработки.

⚡️Ждите запись выступления и следите за нашими анонсами.⚡️

Вебинар уже совсем скоро!

📌Напоминаем
26.02 в 11:00 состоится вебинар, на котором вы узнаете, как не преступить черту закона и какие технические средства можно использовать на примере реальных кейсов.

📌Для трёх участников предусмотрен бесплатный пилотный проект решения Датасан на реальных данных.

➡️Регистрируйтесь по ссылке

Команда "Перфоманс Лаб" ждет вас!

⬅️АБС, которая смогла: как мы 2 часа нагружали банковскую платформу пакетами из 215 тыс. документов➡️

⚡️Сегодня генеральный директор «Перфоманс Лаб» Владимир Каширский на форуме Fincore 26 рассказал, как мы подтвердили масштабируемость и отказоустойчивость Платформы FXL 3.0 от ФлекcCофт.

Коллеги перенесли кодовую базу банковской бизнес-платформы из Oracle в российскую Platform V DataGrid и хотели убедиться, что новая архитектура выдержит требования к производительности критичной для банка системы.

📌О самом проекте мы обязательно напишем подробнее, а пока спойлер: гордимся отечественными разработками!

⬅️19 февраля на форуме "Технологии и безопасность" выступал Василий Жидков➡️

Мы готовы поделиться с вами записью выступления, из которого вы узнаете:
➡️ Утечки персональных данных — это новая реальность
Вопрос больше не в том, случится ли утечка. Вопрос — как минимизировать риски, когда она случится. С новыми оборотами штрафов утечка становится непозволительной роскошью.
➡️ 90% утечек — инсайдеры
Исследование Infowatch показывает, что подавляющее большинство утечек связано со злым умыселом или роковой ошибкой своих. Самые уязвимые — периметры с мягкими политиками безопасности, их и надо защищать в первую очередь.
➡️ Золотое правило — меньше доступа
Сокращайте поверхность атаки за счет разграничения доступа и минимизации допущенных к данным.
➡️ Подходы к обезличиванию
Надстройка для БД — самый быстрый и безопасный способ среди всех вариантов.
➡️ Решение Датасан
Совместимо с Oracle, PostgresPro, MySQL, MSSQL. Обезличивает связанные БД с сохранением структуры. Выполняет требования приказа 140 РКН и ФЗ-152.

📌 Полная запись выступления уже доступна. Кто не был или хочет пересмотреть — ссылка на запись.

⬅️Вебинар о производительности 1С систем + полезный гайд➡️

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

На вебинаре подробно разберем:
➡️ как вовремя проверять производительность системы и минимизировать риски отказов;
➡️ нюансы подачи нагрузки через веб-сервера и от десктопных приложений;
➡️ какой инструменты для подачи нагрузки существуют и как выстроить процесс с нуля.

🎙Спикеры:
Ксения Ворончагина — руководитель направления Performance «Перфоманс Лаб»

📌 Все участники вебинара получат гайд "Как протестировать 1С: все виды тестирования, типовые ошибки и процесс по шагам"

➡️Регистрация на вебинар⬅️

Дата: 12.03.2026 в 16:00 МСК
Формат: онлайн

⬅️Как быстро поднять gRPC-заглушку на Java для тестирования и нагрузочных сценариев➡️

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

📌Зачем нужна gRPC-заглушка

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

📌Вкратце: как создать заглушку шаг за шагом

◾️Берем у разработчиков .proto-файл с контрактом
◾️Добавляем зависимости в pom.xml (grpc-spring-boot-starter, protobuf-maven-plugin)
◾️Компилируем проект — генерируется base-класс сервиса
◾️Наследуемся от него и переопределяем RPC-методы
◾️Описываем нужную логику (для unary, server streaming и других типов вызовов)

📌 Нагрузочное тестирование gRPC

На проектах часто используют JMeter, но в открытом доступе практически нет gRPC-плагинов, которые полноценно поддерживают все виды стриминга. Большинство доступных решений работают только с Unary-вызовами. В «Бумк» есть поддержка всех четырех типов gRPC-вызовов прямо «из коробки». Загрузили .proto, настроили сценарий — поехали.

💾 Полный гид с прописанным кодом и пошаговой инструкцией — в нашем блоге. Сохраняйте, пригодится!

Вебинар уже совсем скоро!

📌 Напоминаем
12.03 в 16:00 состоится вебинар, на котором вы узнаете, как проверять производительность 1С и минимизировать риски отказов в продуктивной среде.

📌 Все участники вебинара получат гайд "Как протестировать 1С: все виды тестирования, типовые ошибки и процесс по шагам"

➡️Регистрируйтесь по ссылке

Команда "Перфоманс Лаб" ждет вас!

⬅️Выпустили новые функции продуктов, встретились с экспертами, поделились с вами полезными материалами ➡️

⚡️У нас много новостей: запускаем новые возможности «Датасан» и «Бумк», проводим встречи с экспертами, а еще выпустили инструкцию, как организовать процесс обезличивания с нуля и избежать ошибок, которые делают все.

💾Полный дайджест — на сайте «Перфоманс Лаб», читайте и делитесь!

➡️Сделали модуль для ускоренного обезличивания больших баз в «Датасан».
Модуль усечения данных формирует минимально необходимую для разработки и тестирования копию базы. Это ускоряет процесс обезличивания в 4 раза по сравнению с обработкой полной БД. Усечение настраивается по различным параметрам — например, по дате, географии или маске идентификаторов — и выполняется с сохранением связей между данными.
📌Заказать демо по ссылке.


➡️Запускаем ИИ-подготовку сценариев нагрузочного тестирования в «Бумк»
ИИ поможет автоматически формировать основу сценария нагрузочного тестирования на базе описания системы или пользовательского потока. Сейчас мы обсуждаем прототип — и очень ценим вашу обратную связь! Ниже — ссылка на Calendly владельца продукта «Бумк» Бориса Селезнева: просто перейдите по ней и забронируйте удобный вам слот для кастдева.

⚡️Все участники кастдева получат билеты на онлайн-поток «Перфоманс Конф #12», которая пройдет в сентябре!
📌Забронировать слот по ссылке.

Прекрасной и продуктивной весны!

⬅️Рассказали о нагрузочном тестировании на вебинаре Ассоциации финансовых технологий (АФТ)➡️

⚡️Генеральный директор «Перфоманс Лаб» Владимир Каширский выступил на вебинаре, посвященном передовым технологиям в архитектуре финансовых систем — в том числе и российским вендорам.
Вместе с коллегами мы обсудили платформу FXL (ФлексСофт) и кейс переноса ее функционала на отечественный стек. Успешность переноса как раз подтвердили инженеры “Перфоманс Лаб” в ходе независимого тестирования.

📌 На вебинаре Владимир Каширский рассказал детали проекта:
◾️ какие метрики производительности использовались в проекте;
◾️ как реализовывали горизонтальное масштабирование под нагрузкой;
◾️ как обеспечили штатную работу при аварийной потере узлов кластера.

❤️ Спасибо организаторам — FlexSoft и Ассоциации финансовых технологий (АФТ) — за приглашение и возможность поделиться опытом!

Видеозапись вебинара доступна по ссылке.

⬅️Пять ключевых QA-трендов 2026 года: как ИИ, DevOps и безопасность меняют тестирование➡️

За последний год объем утечек данных в России вырос в 138 раз, а стоимость одного инцидента для бизнеса уже измеряется десятками миллионов рублей.

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

На вебинаре обсудим:
➡️как использовать ИИ, чтобы снижать расходы на тестирование и где это действительно работает;
➡️какие риски утечек актуальны для российского рынка;
➡️как QAOps и нагрузочное тестирование помогают предотвращать сбои в критичных процессах;
➡️как DevSecOps и инструменты вроде SAST / SCA / Trivy снижают вероятность инцидентов;
➡️где low-code ускоряет разработку, а где оправдан классический подход.

🎙Спикеры:
Александр Канатов — директор направления QA, «Перфоманс Лаб»
Алексей Кузнецов — технический директор направления QA, «Перфоманс Лаб»

Дата: 31.03. 2026 в 11:00 МСК
Формат: онлайн

Количество мест ограничено — зарегистрируйтесь заранее.

➡️Регистрация на вебинар⬅️

Вебинар уже совсем скоро!

📌Напоминаем
Уже через час пройдет вебинар на котором вы узнаете, как использовать ИИ, чтобы снижать расходы на тестирование и где это действительно работает.

📌Для участников вебинара будет открыта возможность получить новый выпуск большого аналитического журнала Russia Quality Report в числе первых!

➡️Регистрация на вебинар⬅️

Ждем вас и ваших вопросов!

⬅️Скролим страницы: не бойтесь нарушать правила➡️

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

📌 Седат Капаноглу в книге «Кодер с улицы» честно рассказывает, как выживать в реальном мире разработки, а не на курсах.

💾О чём книга.
Это не учебник по чистому коду, а скорее сборник приёмов, которые работают, когда сроки горят, требования меняются каждый день, а в команде есть менеджер-параноик. Автор учит адаптировать теорию к реальности — и понимать, в каких местах можно нарушать правила, чтобы не утонуть в задачах.

Что внутри:
◾️как писать код, который не развалится (даже если он не идеальный)
◾️как выживать в проблемной команде
◾️где антипаттерны становятся единственным рабочим решением
◾️как превратить «плохие» методы в инструмент, а не в костыль

Почему это полезно ИТ-специалисту.
Книга не про «как должно быть», а про «как бывает на самом деле». Для тех, кто уже столкнулся с тем, что в реальных проектах нет места идеальным абстракциям. Для джунов, которые хотят быстрее набраться практического опыта. И для мидлов, которые устали воевать за идеи, которые не работают.

⚡️Главная мысль: правила написаны для идеального мира. В реальном выживает тот, кто знает, какое правило можно нарушить, чтобы сделать систему надёжнее, а не красивее.

⬅️JMeter для функционального тестирования: парадоксально, но факт➡️

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

🔍 Что умеет JMeter (коротко):
— писать автотесты на API без кода
— проверять содержимое ответов (JSON, XML)
— подключаться к базам данных и очередям
— парсить файлы и использовать данные из них
— запускаться в CI и отдавать отчёты в Allure

📌 Почему он может быть лучше конкурентов, даже open-source:

1️⃣Отдаёт отчеты в привычном формате allure (а во многих компаниях единая TMS все еще принимает только его). Позволяет доработать что угодно — и отчёты, и подключение к БД, и интеграцию с RabbitMQ.

2️⃣ Переменные в JMeter работают просто. Записал значение в ${var_name} — используй где угодно. Если нужно что-то обработать — подключаются процессоры. Regular Expression Extractor вытащит токен из ссылки. JSR223 Post-processor позволит выполнить код на Java/Groovy — решение можно найти за минуту в поиске.

3️⃣ С контроллерами можно делать ветвления и циклы:
◾️ If Controller — условие для выполнения шага (но без фанатизма)
◾️ While Controller — повторять запрос, пока не вернётся нужный ответ
◾️ ForEach Controller — пробежаться по всем элементам массива
◾️ Loop Controller — отправить запрос N раз

⬅️Аутсорс в ИТ: как сделать так, чтобы он действительно экономил ресурс➡️

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

Но разве проблема в аутсорсе как модели работы?

📌 Мы видели много проектов, в которых бизнес отдает внешним подрядчика то, что отдавать нельзя, — и не замечает точки, где аутсорс может в разы ускорить команду. Но еще более распространенная ошибка — ожидать, что исполнитель сам разберется, расставит приоритеты и даже примет продуктовое решение. Итог предсказуем.

➡️ В новом материале рассказываем:
◾️ как понять, когда нужен аутсорс, а когда — классический найм;
◾️ какие задачи отдать внешнему подрядчику, чтобы сэкономить время;
◾️ для каких проектов аутсорс используют крупные команды — и какой денежный эффект это может принести.

💾 Подробнее — читайте в блоге «Перфоманс Лаб» по ссылке.

⬅️Как просчёт в ИТ обошёлся в $100 млн➡️

Конец 90-х. Крупный производитель спортивных товаров стремительно растёт, но цепочка поставок трещит по швам: 27 разрозненных систем управления заказами по всему миру, девятимесячный цикл производства. Компания решается на тотальную замену — внедрение новой системы управления цепочками поставок.

⚡️️Что пошло не так
Проект оценили в $400 млн, выбрали стратегию «большого взрыва» — старую систему отключили, новую включили сразу, без поэтапного перехода.
Legacy-данные оказались слишком неструктурированными, а софт требовал кастомизации далеко за пределы рекомендованных 10–15%. Система тормозила, падала, дублировала и теряла заказы.

📌Какие последствия были у бизнеса:
◾️нехватка популярных моделей и перепроизводство непопулярных;
◾️вынужденные скидки и доставка самолётами вместо кораблей;
◾️падение квартальной прибыли на 28%, обвал акций на 20%;
◾️совокупные потери — около $100 млн.

💾Почему так вышло:
◾️недооценили сложность интеграции с legacy-системой;
◾️выбрали рискованную стратегию внедрения без пилотов и фаз;
◾️плохо обучили сотрудников;
◾️не привлекли стороннего интегратора;
◾️торопились — от старта до «live» прошло чуть больше года.

📌Что в сухом остатке
Проект всё-таки завершили успешно: цикл сократили с 9 до 6 месяцев, запасы на складах — с месяца до недели. Но осадок остался: поспешность, отсутствие независимого аудита и переоценка своих сил обошлись в 9 нулей.

➡️ Вывод: масштабные изменения в ИТ требуют не только бюджета, но и холодного расчёта, стороннего взгляда и готовности идти поэтапно. Экономия на подготовке и консультациях часто обходится дороже, чем сами консультации.