Новые времена и технологии требуют трансформации QA-подхода. Расскажем о том, как по-новому организовать процесс тест-анализа и тест-дизайна, чтобы ускорять результаты команды, а не плодить море тестов ради бурной деятельности. Разберем экономику решений, инженерные механизмы и план внедрения. Статья пригодится CTO, продактам и QA-лидам, которые уже начинают тонуть в ИИ-коде. Читайте, если хотите понять, как снизить стоимость ошибок, сократить потери времени на тестирование и сделать качество продукта более предсказуемым. 

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

Ну и в целом, перечисленные ниже методики позволят заранее понимает, что проверять, почему именно это важно и какие риски остаются перед релизом.

Основные понятия

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

Важно не количество тестов, а их качество

Если команда сгенерировала 500 новых тестов за вечер, то возникает вопрос: какие новые риски удалось таким образом закрыть — и будут ли полезны все эти проверки через полгода?

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

Исследование DORA 2025¹ на основе опроса почти 5000 специалистов показало: применение ИИ связано с улучшением пропускной способности системы и продуктовых показателей, но при этом ведет к нестабильности доставки. Конечно, это отдельно взятые данные, а не доказательство, что любой ИИ ухудшает стабильность конкретного проекта, но задуматься есть о чем.

В эксперименте METR² 16 опытных участников, работавших над 246 задачами в знакомых репозиториях с открытым исходным кодом, в условиях начала 2025 года тратили с ИИ в среднем на 19% больше времени, чем без него. По данным Stack Overflow³ 46% респондентов не доверяли точности ответов ИИ-инструментов. Эти цифры не истина в последней инстанции, но показывают, как опасно верить в миф о гарантированном ускорении с помощью нейросетей. Особенно, если нет четкого контроля качества.

И видя все эти данные, можно сформулировать задачу QA в эпоху ИИ так: снизить затраты на обеспечение надежности релиза, но при этом не допустить роста рисков, которые считаются недопустимыми. Количество тестов, строки кода автотестов и процент зеленых прогонов – внутренние показатели. Бизнесу же важны время до релиза функций, затраты на переделки и последствия пропущенных ошибок. 

Здесь и приходит на помощь тест-анализ и тест-дизайн, так как главный QA-навык в мире разработки с нейронками – это уже не просто способность протестировать, а умение выбрать осмысленную проверку и определить верный результат.

Как с помощью тест-анализа и тест-дизайна определить оптимальный бюджет на QA?

Самая распространенная управленческая ошибка – рассматривать бюджет на тестирование поверхностно, например: «было восемь тестировщиков, стало пять, значит сэкономили». Это неверно, так как необходимо оценивать полную стоимость обеспечения качества внутри потока поставки изменений.

C_total = C_analysis + C_design + C_execution
        + C_maintenance + C_infrastructure
        + C_delays + E(C_escaped_defects)

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

У каждой проверки должна быть маржинальная полезность

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

Если совсем упрощать, то ценность каждой отдельной проверки можно обсуждать так:

Упрощенная модель приоритета
Ожидаемая польза теста ≈ вероятность наличия дефекта в рассматриваемом классе × вероятность его обнаружения данным тестом × ущерб от позднего обнаружения − стоимость исполнения и сопровождения.

Контекст влияет на вероятности – их обычно оценивают тест-аналитики. Проверки связаны между собой: нельзя просто сложить их пользу, будто они независимы. 

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

Управляем неопределенностью c помощью тест-аналитики

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

Можно разделить эти вопросы на три класса.

1. Неопределенность требований: бизнес пока не решил, как должно быть.
2. Неопределенность реализации: непонятно, где хранится состояние и кто отвечает за согласованность.
3. Неопределенность наблюдаемости: правильное поведение задано, но мы не можем доказать его в тестах или продакшене.

Это не поэтапная каскадная модель. Цикл повторяется при изменении бизнес-правил и архитектуры.

Четыре артефакта, без которых нельзя запускать функцию с высоким риском

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

Признак того, что тест-анализ работает не так, как надо

Если после внедрения усиленного тест‑анализа количество обязательных документов у команды выросло вдвое, но на приемке по‑прежнему всплывают спорные вопросы, это значит, что автоматизировали фиксацию неопределенности, а не ее устранение. Формально все оформлено, но проблемные места так и остались нерешенными.

Разберем оплату: 14 тест‑кейсов не помогут, если проверяем не тои инвариант

Допустим, у SaaS-сервиса есть выставление счетов, подписки, платежный провайдер и асинхронные webhook-события. Фича звучит просто: «поддержать повторную попытку списания после тайм-аута». Код легко сгенерировать, как и получить ошибки, которые могут стоить очень дорого.

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

Четыре проверяемых инварианта

1. Не более одного фактического списания на согласованную попытку покупки. Повторный запрос с тем же ключом идемпотентности не должен приводить к созданию новой денежной операции.
2. Локальное состояние выводится из подтверждённых событий, а не из тайм-аута. Потеря ответа не означает, что банк не списал деньги.
3. Возврат не превышает реально зафиксированную сумму списания. Проверяем не только UI, но и журнал финансовых операций.
4. Неупорядоченные и повторные события не нарушают допустимый жизненный цикл. Позднее уведомление об успешном платеже (после повторной попытки) должно обрабатываться по установленному правилу.

От инварианта к техникам: как выбирать проверки

Что именно запустить в CI?

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

По измененному графу зависимостей: релевантные интеграционные тесты. 

По расписанию и перед значимым релизом: расширенные последовательности событий, параллельные транзакции, длительные отказы и E2E-пути. 

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

Почему это именно тест-дизайн, а не просто усиление автоматизации? Одна модель порождает разные доказательства на разных уровнях. Нельзя копировать один и тот же сценарий 12 раз в UI, API и E2E. Нужно проверять инвариант там, где он наиболее наблюдаем, и оставлять несколько сквозных путей для подтверждения общей интеграции.

Универсальная модель: подходит и для человека, и для генератора 

Пример: контракт тест-анализатора, YAML

 risk_id: BILL-07
business_invariant: "на один платеж приходится не более одного успешного списания" 
owner: product-owner-биллинга 
assumptions: []
open_questions:
 - "Когда ключ идемпотентности считается истекшим?"
  - "Может ли платежный провайдер прислать статус «успешно» после локального таймаута?" 
model:
  states: [ожидание, успех, ошибка, возврат] 
  events: [создание, списание, таймаут, повтор, вебхук, возврат] 
  forbidden: ["возврат -> списание без нового платежного намерения"] 
controls:
  - type: свойство_состояний 
    oracle: счетчик_успешных_списаний_в_реестре 
    level: компонентный 
  - type: контрактный_тест 
    oracle: схема_сообщений_платежного_провайдера 
    level: сервисный 
  - type: тест_конкурентности 
    oracle: ровно_одно_списание 
    level: интеграционный 
acceptance:
  - "все обязательные инварианты выполняются" 
  - "открытых вопросов с высоким риском: 0"

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

Собираем тестовый набор: портфель страховок вместо архива сценариев

Технически можно обеспечить 100% выполненных тестов и не закрыть ни одного действительно опасного риска. Поэтому лучше взять за основу матрицу “риск - независимые способы обнаружения”. Она помогает находить дыры и необоснованное дублирование.

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

Почему большое количество автотестов может ухудшать систему?

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

Регрессия делится на четыре контура:

• обязательные проверки – не отключаются ни при каком скоринге;
• по изменениям – тесты затронутых зависимостей;
• по риску – приоритет дается рискам и историческим сигналам;
• широкая периодическая регрессия – страховка от ошибок в модели зависимостей.

Дополнительно нужен теневой прогон: исключенные тесты время от времени выполняются, чтобы увидеть пропущенные регрессии.

В 2018 году компания Meta⁴ представила систему отбора тестов, которая прогнозирует риски. При запуске примерно трети тестов, связанных через зависимости, система выявляла более 99,9 % регрессий еще до того, как изменения попадали в основную ветку кода. Это показатель для конкретной инфраструктуры – она обучалась на прошлых данных. Такую метрику нельзя автоматически переносить на новый проект.

Доли исполняемых тестов по описанию Meta, 2018. Не эквивалентны доле покрытия или риску конкретного другого продукта.

Google, 2026.⁵ Исследование стратегий отбора тестов для десяти ключевых библиотек показало: при бюджете примерно в 0,9% от полной стоимости прогона тестов удавалось выявлять регрессии в 40% коммитов, где они действительно присутствовали. Это отражает компромисс между стоимостью раннего обнаружения ошибок и полнотой проверки. Остальные регрессии при таком подходе не исчезают – их выявляют на следующих этапах контроля качества.

ML не решает проблему сам по себе. Нельзя просто оставить 1% тестов. Нужна стратегия: понятная цена риска (ложных отрицаний), контрольные прогоны, обязательная защита ключевых проверок. 

Шесть приемов, которые действительно меняют экономику тестирования

Модельные тесты вместо ручного перебора последовательностей

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

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

Границы применимости: если состояние скрыто от наблюдения или модель систематически не учитывает реальные события, автогенерация только создаст ложную уверенность в покрытии.

Комбинаторное тестирование с переменной глубиной, а не pairwise на все

Не стоит проверять всю систему с одинаковым уровнем покрытия взаимодействий. Для проверки совместимости конфигураций часто хватает парных сочетаний (по два параметра), а для комбинаций вида «тариф + валюта + региональные правила» бывает оправдан тройной уровень или усиленное покрытие отдельных зон. Обязательная часть – ограничения: явные списки допустимых и запрещенных комбинаций.

Для примера соберем простой набор без ограничений: пять факторов, число значений которых дает 3 × 3 × 2 × 3 × 2 = 108 комбинаций. Жадный алгоритм построения покрытия (это не математически минимальное решение) дал следующий набор проверенных сочетаний:

По данным исследований NIST⁶, комбинаторное покрытие – эффективный способ заметно сократить количество проверок, при этом сохранив контроль над ключевыми взаимодействиями параметров. В работе 2024 года приведены примеры, когда объем тестового набора удавалось уменьшить в 20–700 раз. Важно понимать, что такой эффект достигается не всегда: это не универсальное решение и не гарантия качества для любого проекта.

Контракты по ожиданиям потребителя вместо тяжелой инт]]> https://quality-lab.ru/blog/perestraivaem-test%E2%80%91analiz-i-test%E2%80%91dizajn-rabota-s-riskami-i-skorostyu-relizov-v-epoxu-ii/ Thu, 12 Nov 2026 16:22:41 +0300 Автор: Ханиша Арора (Hanisha Arora)
Оригинал статьи
Перевод: Ольга Алифанова

Баги появляются, съедают всё ваше время и заставляют вас сомневаться в себе, убеждая, что проблема в вас. Это не так.

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

Вот несколько приёмов отладки, которые помогали мне в такие моменты:

]]> https://www.software-testing.ru/library/testing/testing-automation/4543-10-debugging-hacks Tue, 10 Nov 2026 23:00:00 +0300 Все вокруг говорят про ИИ в тестировании. Но чаще это сводится к простому: «спроси у чата, как написать регулярку или тест-кейс». Это полезно, но это только верхушка айсберга.

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

Впрочем, агент полезен и в ручном тестировании. Он поможет разобраться, как работает функционал, напишет SQL-запрос для проверки данных, составит REST/SOAP-запрос или даст пошаговую инструкцию для воспроизведения бага.

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

Старт курса: 24 ноября.

Подробная программа и условия участия по ссылке: https://software-testing.ru/edu/3-online/354-ii

]]> https://www.software-testing.ru/events/4571-ai Sun, 08 Nov 2026 23:00:00 +0300

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

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

Представьте: вы несколько месяцев готовили большую распродажу. Закупили товары, согласовали скидки, запустили рекламные кампании, прогрели аудиторию. В день старта трафик вырос в несколько раз, покупатели добавляют товары в корзину, но оформить заказ не могут. Сайт тормозит, платежная форма выдает ошибки, остатки не обновляются. Реклама продолжает приводить людей, маркетинговый бюджет расходуется, а продажи стоят.

Упавший чекаут в разгар распродажи – это не просто технический инцидент. Это потерянная выручка, недовольные покупатели и испорченная репутация магазина.

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

Сезон распродаж 2026

Самое важное, что в 2026 году ритейлеры сознательно уходят от точечных коротких акций и по максимуму растягивают скидки. Ozon, к примеру, объединил 11.11 и «Черную пятницу» в шестинедельную кампанию, Wildberries стартует 13 ноября на целых 18 дней.  Дальше Новый год, 14 и 23 февраля, 8 Марта. Тенденция к увеличению продолжительности акций прослеживается на фоне слабого потребительского спроса. Покупатели все более осторожно тратят деньги, подавляя в себе порывы к эмоциональному потреблению. 

11 ноября 2024 года оборот интернет-магазинов вырос на 32% год к году, число оплат на 45%. В 2025-м прирост составил 12% и 7%. Для ноября 2026 года сервис прогнозирует рост на 15–20%. Участвовать в распродажах планируют 51% работающих россиян, из них 21% уже выбрали покупки. Каждый пятый (21%) заранее кладет товар в корзину и ждет скидки.

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

Независимых интернет-магазинов всё больше

Есть и второй фактор, особенно заметный в 2026 году. Продавцы уходят с маркетплейсов в свои магазины: по прогнозу INFOLine, оборот независимого e-commerce в 2026 году достигнет 5,75 трлн ₽ (+25,8%). За год зарегистрировали 9775 новых e-commerce-доменов, на 12% больше.

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

К примеру, буквально 2 ноября 2026 года сбой хостинг-провайдера Beget затронул тысячи сайтов и создал риск остановки онлайн-продаж. Да вы и сами видите в новостях, насколько частыми стали глобальные сбои в сети и как участники рынка делятся информацией о крупных финансовых издержках в связи с этим. Получается интересная ситуация: у бизнеса появляются собственные каналы продаж, но вместе с ними – и больше ответственности за техническую сторону торговли.

Где интернет-магазины теряют деньги?

Потери редко происходят из-за рекламы или ассортимента (хотя это база и тоже очень важно). Чаще всего утечки в воронке происходят по техническим причинам, особенно когда все силы и деньги бросили на открытие своего интернет-магазина (чтобы защититься от всем известных логистических рисков), но никто не проверил систему под нагрузкой и на разных устройствах.

Зона	Что ломается?	Чем это грозит?
Чекаут и оплата	Платеж зависает, промокод обнуляется, кнопка «Оформить» активна при невалидных данных	Прямая потеря выручки, брошенные заказы
Мобильная версия	Виджет чата закрывает кнопку «Войти», футер перекрывает элементы каталога и т.д.	Падение мобильной конверсии
Цены и остатки	Разные цены на площадках, продажа товара, которого нет на складе	Отмены заказов, жалобы, репутационные риски
Поиск и фильтры	Поиск по артикулу дублирует товары, фильтр цены сбрасывается	Покупатель уходит к конкурентам
Интеграции	Сбои в платежах, доставке, проблемы с логистикой из-за проблем с API	Оплаченный заказ не доходит до склада
Инфраструктура	Сайт не держит трафик, сбои и торможения из-за пиковых нагрузок	Падение продаж в ключевой момент

Пример из нашей практики: когда делали аудит магазина автозапчастей, нашли 67 дефектов, 9 из которых оказались критическими. Они блокировали ключевые сценарии, в том числе поиск и оформление заказа (разбор кейса). В итоге заказчик увидел свой сайт глазами клиента, был неприятно удивлен, но выразил нам благодарность.

Вывод простой: веб-аналитика покажет, что конверсия просела, маркетолог это подтвердит расширенными данными. Но только тестировщики проверят и подсветят технические проблемы. Баг это, неудобный интерфейс, сезонный спад или случайные обстоятельства? Хватит гадать на кофейной гуще, просто обратитесь к QA-команде. 

Какое виды тестирования интернет-магазина стоит подключить?

Если распродажа уже на носу, а уверенности в технической устойчивости инфраструктуры нет, то в план важно включить эти проверки. 

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

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

Что проверить:

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

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

Функциональное тестирование покупательской воронки

Особое внимание стоит уделить:

• поиску и фильтрам;
• карточкам товаров;
• расчету скидок и применению промокодов;
• добавлению и удалению товаров из корзины;
• выбору доставки и способа оплаты;
• оформлению и отмене заказа;
• личному кабинету и истории покупок.

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

Кросс-девайс и кроссбраузерная проверка

Эти тесты нужны, потому что маркетолог смотрит сайт на новом iPhone, а покупатель открывает его на пятилетнем Android. 

Отдельно стоит проверить сценарий покупки на небольшом экране. Удобно ли выбрать товар? Не перекрывает ли клавиатура поле ввода? Можно ли применить промокод? Не исчезает ли кнопка оформления заказа за пределами экрана? Одна ошибка в мобильном чекауте способна стоить магазину значительной части потенциальных заказов.

Интеграционное тестирование

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

Например, после оформления заказа данные должны попасть в систему учета, товар – зарезервироваться, а покупатель – получить подтверждение. Если один из этапов не сработал, заказ может потеряться или продублироваться.

Юзабилити-аудит

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

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

Другие проверки

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

Регрессия после каждой правки перед стартом гарантирует, что вчерашний фикс не сломал сегодняшний чекаут.

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

Кейс: сделали нагрузочное тестирование, которое сэкономило заказчику 28 млн ₽

Крупный федеральный ритейлер бытовой техники запускал новую e-commerce-платформу. Мы сымитировали поведение 50 000 одновременных пользователей, оформляющих заказы, и быстро нашли критические узкие места: неэффективные запросы к базе данных (классическая проблема «N+1») и неверно настроенное кэширование. Система падала уже при 10% от ожидаемой нагрузки.

Показатель	Значение
Стоимость нагрузочного тестирования	1,8 млн ₽
Потенциальные убытки от простоя	> 30 млн ₽
Чистая экономия	> 28 млн ₽
Рентабельность инвестиций (ROI)	> 1000%

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

Чек-лист подготовки интернет-магазина к распродаже

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

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

Сфера	Что делать?
Сайт	Нагрузочное тестирование (в идеале за месяц до старта распродаж), чтобы успеть внести нужные изменения для усиления отказоустойчивости.
Цены	Исключить ручной ввод цен на разных площадках. В ERP задать минимальную цену, ниже которой скидка не опустится ни при каких условиях.
Остатки	Единая система учета с моментальным резервированием товара в корзине.
Чекаут	Проверить все способы оплаты, промокоды, сценарии с ошибкой банка и повторным заказом из истории. Протестировать интеграции.
Мобильная версия	Пройти воронку на реальных устройствах, разных экранах и в разных ориентациях.
Юридическая защита	Провести комплаенс-тестирование, прописать в оферте пункт о технической ошибке. В суде отмену заказа защитить сложно, поэтому надежнее блокировать корзину при аномальной скидке.
Мониторинг	Алерты на доступность, скорость страниц и ошибки оплаты на время акции.

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

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

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

Экспресс-план подготовки интернет-магазина к сезону распродаж

Если до старта акции осталось несколько недель, действуйте последовательно.

За 4–6 недель: аудит и планирование

• Проанализируйте прошлогодние показатели посещаемости и продаж.
• Определите ожидаемую пиковую нагрузку.
• Составьте список критических пользовательских сценариев.
• Проведите первичную оценку технического состояния интернет-магазина.
• Запланируйте нагрузочные испытания.

За 2–4 недели: тестирование и исправление ошибок

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

За 1–2 недели: контрольная проверка

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

Во время распродажи: мониторинг

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

Что делать дальше?

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

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

Читайте также:

• 5 смертных грехов подготовки к Black Friday
• Как баги снижают продажи в ритейле
• Инструменты автоматической проверки и мониторинга сайта перед распродажей

]]> https://quality-lab.ru/blog/kak-podgotovit-internet-magazin-k-rasprodazhe-testirovanie-i-plan-dejstvij/ Fri, 06 Nov 2026 17:57:11 +0300 Автор — Гайнутдинов Роман, senior QA automation, Компания «БКС».
Оригинальная публикация

Самый дорогой регрессионный набор не тот, который долго выполняется, а тот, которому команда перестала верить. Когда команда внедряет автоматизацию, она быстро приходит к соблазнительной идее: если автотесты ускоряют проверки и исключают человеческий фактор, значит автоматизировать нужно всё, до чего можно дотянуться. Но здесь и начинается ошибка. Автоматизировать всё, что можно, и автоматизировать то, что действительно нужно, не одно и то же.

Меня зовут Гайнутдинов Роман, я старший инженер по автоматизированному тестированию в компании «БКС Мир инвестиций». За плечами построение автоматизации с нуля, поддержка готовых решений и оптимизация уже раздутых регрессионных наборов.

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

]]> https://www.software-testing.ru/library/testing/testing-automation/4569-regression-without-regression Wed, 04 Nov 2026 23:00:00 +0300 А один дядя решил, что теперь-то у него развязаны муки руки творчества, и он напишет программу, которая должна помогать людям экономить время. Не сам, конечно, а глядя в консоль с AI, но кому какое дело.

И вот он таки «написал» эту программу, а потом ВНЕЗАПНО понял, что ничего не изменилось. Программа сама по себе ничего не значит. Её нужно превратить в полноценный продукт, а там установка, интерфейс, обновления, тестирование, поддержка, распространение, инструкции, продажи, для чего нужны реклама, маркетинг, материалы, а он реально подзастрял на багфиксинге.

AI очень хорошо в этом помогает…

А ещё ему хотелось написать книгу про всякое важное. И музыку. И фильм. И оплачивать коммуналку. Всё это мог бы делать за него AI, но до зарабатывания дядя никак не мог дойти. Надо же довести продукт до ума? Надо. Надо заняться продвижением? Надо. Надо искать покупателей? Надо. И багфиксы тоже надо забагфиксить.

Дядя творчески воображал, что AI будет за него делать всё, освобождая время для, эээ, творчества. Оказывается, надо сперва уметь что-то делать, чтобы суметь это делегировать кому-то и, раздавая ценные указания, довести проект до успеха. И надо найти правильных исполнителей.

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

Но знаете, в том Agile никто не говорил, что будут нужны тестировщики — их туда не придумывали. И когда обещали, что в конце каждого спринта у вас будет работающий софт, никто же не уточнял, что это будет ПРАВИЛЬНО работающий софт, лишённый багов.

А, но если найдётся баг, то мы его быстро пофиксим. А если десять? А если сто?

А, но если вы захотите всё переделать, то мы просто всё переделаем. А за чей счёт? А сколько это будет стоить вообще? А сколько времени на это понадобится?

Постоянно продолжается уйма дел, которые надо делать или самому, или делегировать. Что вы можете это делегировать AI? Вы можете делегировать ему любую задачу и пойти заниматься другой задачей, или вы может делегировать ему условную задачу, сесть рядом и постоянно указывать, как её надо делать и что надо переделать? Насколько это является «делегированием»?

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

Не каждый программист захочет вернуться в мир живых за мелкий прайсик. Некоторые ещё мыкаются с лицом зомби, который помнит прекрасные времена своей дикой востребованности, которые так ВНЕЗАПНО миновали, но то некоторые, а которые-то уже начинают согласно махать киньцывками, потому что даже мёртвым голодно и холодно жить.

Йоеснь, йопт…

На этом мы того дядю оставим (в окружении голодных зомбаков, которые помнят как назвать класс в Java) и подумаем о том, что эту проблему уже решали специально обученные люди — бизнесмены же.

Бизнесмен умеет договариваться. Иногда с добрым пистолетом, иногда словом, иногда несолоно хлебавши, но умеет. И поэтому умеет делегировать задачи. То есть, бизнесмен может сказать «Я делаю софт, пишу книгу и снимаю фильм», не уточняя, что он не делает, а финансирует. Делают всё отдельно нанятые люди, но в целом результат представляет заказывающий, так что да, софт и книгу и фильм в итоге «делает» делегирующий бизнесмен. А ещё эти процессы запускаются им в параллель, поэтому книги и фильмы и софт у него появляются часто и условно быстро.

А в чем тогда разница между бизнесменом и дядей с AI в кармане? Огромная. Бизнесмен делегирует задачу человеку и не вынужден стоять рядом с ним на раздаче постоянных указаний о том, как всё надо переделать. А дядя вынужден сидеть с AI и заниматься только той задачей, которую должен делать AI. Это не делегирование. Это вас так зомбируют, чтобы вы сами выдернули из ноута всю оперативку и отнесли её тому, кому она нужнее…

А в чем тогда разница между бизнесменом и бизнесменом с AI в кармане? А такая же, как между бизнесменом и упомянутым дядей — мечты о дешёвом делегировании разбиваются о жестокий быт людей, которые веруют в неверное.

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

Ну возьмёт добрый молодец все задачки свои, и что? Какие он может отложить и забыть? Никакие, вы чо, с ума сошли? Какие он может делегировать? Да никакие, бо второго такого же тимлида рядом нет, а все задачи, которые могут выполнять его подчинённые, его подчинённые уже выполняют. Какие задачи он может сделать сам? Да все! А какие может отложить? Да все же…

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

Надо быть бизнесменом-президентом США!

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

Будет ли прорыв в технологиях, когда условный AI будет способным выполнять задачи, которые ему будут делегировать дяди без ресурсов, неспособные нанимать других дядей? Да, наверное. Следим за новостями — если там некий неизвестный начнёт непредсказуемо выпиливать всех программистов, которые ещё смогут конкурировать с ним за ещё не разделегированные рабочие задачи очередного президента США, то напрягаемся, иначе нет.

]]> https://testitquickly.com/2026/11/04/prostii-si-deznadejde/ Wed, 04 Nov 2026 21:02:23 +0300 Развлечём закисших блаародных донов, которые страдают от общего падения уровня веселия в Арканаре. Говорят, мол, плохо всё, в жизни нет смысла.

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

Относительно современных подий, которые описывают как «а если сегодня не нанимать джунов — где вы завтра возьмете сеньоров, а!!!!??!!?!?!» — так а с чего вы взяли, что завтра эти ваши сеньоры будут нужны? Завтра будут нужны сеньоры другой формации, они будут жить в другом контексте, им будет нужна другая подготовка. Это раз.

А вот вам два — джуны тоже будут нужны. Когда джуны нужны, бизнес автоматически клепает курсы и подталкивает «рынок» нагонять ему джуниоров. Отсюда взлет курсов «на рынке», потому что появляются сразу два источника спроса, готовые заплатить — 1) бизнес и 2) желающие к этому бизнесу пристроиться.

Сейчас спрос на джунов со стороны бизнеса упал, потому что непонятно, куда и как их прикладывать (прикладное программирование же?!), за этим доминошками посыпались курсы, бо нет спроса с обеих сторон и нечего обещать в обмен на деньги.

И кажется, что так уже будет всегда.

Программисты не нужны.
Тестировщики не нужны.
Заказчики не нужны.
Клиенты заказчикам не нужны.
Никто никому не нужен.

Не будет.

Это ваше рассуждение — не рассуждение, а экстраполирование отдельных эффектов на неопределенное будущее, вроде как люди образца 1890-х годов думали о будущем как о городах, полных навоза, потому что они понимали только лошадиный транспорт, который «работает на навозе». Идея автомобиля в те времена была незначительной, бо машинки были стрëмными. А сейчас вон оно как…

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

Давно уже умерли братья Ади и Руди Дасслеры, и все их работники, и все дети всех их работников, а компания Adidas всё ещё живёт и носится на чьих-то ногах. И времена она переживала более, эээ, мерзкие, нежели современные. И шо?

А если нет возможности регулярно заменять юнитов, то бизнес захочет нанимать только длинноногих, политически грамотных, юных и всесторонне развитых работников, которые будут незаменимо отвечать сразу «за всë». И вроде это логично, но от таких уникумов алгоритм бизнеса под большой угрозой, бо юнит может заболеть, взбрыкнуть, получить бан от антропика, тощо. И чо будет делать бизнес? Бизнес всегда основывается на заменяемых юнитах, а на незаменяемых ездит изредка и недолго, когда прижмёт.

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

Или ближе к нам — куда исчезли отдельные профессии тест-аналитиков и тест-дизайнеров? А мы сами начали заниматься сразу и тест-аналитикой и тест-дизайном, и их выполнением, и сегодня это уже никому не кажется странным. А это странно.

Поэтому когда джуны не нужны — они не нужны, точка. Когда джуны нужны — их начинают нанимать и обучать, и тут тоже точка. Припомните доисторический 2010-й год, например, когда надо было объяснять, что существует такое тестирование, и приходите к нам, вам будет интересно, мы вас всему научим, давайте к нам тестировать… Что было потом — вы уже знаете. А что происходит сегодня — вы знаете однозначно.

Сейчас кризисов несколько:

1. просто экономический — заказов мало, все застыли в ожидании. На работе уже нужны не много отдельных юнитов, а всего лишь несколько точечно работающих многостаночников, за мелкий прайс. В норме это смешной оксюморон, но в кризисе не до смеха. Таких найти трудно, и риски с ними опять же растут, но это логичный ход (и, ЧСХ, массовый), поэтому фулстеки фнезапно фнорме и фсем нужны
2. идейный — непонятно, кто нужен/понадобится на работе, потому что заказчиков стало мало, отчего алгоритмы бизнеса сбоят, спрос поменялся, стал неопределенным, все застыли в ожидании
3. политический — стабильность стала очень нестабильной, на пять лет вперед задачи уже не прикинуть, и мы не можем понять, кого мы будем хотеть видеть на работе завтра. Отсюда замороженный спрос, все в ступоре
4. социальный — непонятно, кого бизнес будет искать в будущем, какая профессия будет нужна (тут и дети, и мы сами), и тоже все зависли в ожидании знака свыше

Отсюда вывод: фулстеки. Усидчивые. С большим AI в кармане.

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

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

Почему тяжко тестировщикам — а потому, что тестирование это сервис для менеджеров, а не необходимость для разработчиков вообще и для бизнеса в условной частности. В расцвете рынка сервисы — самое прибыльное занятие (вы посмотрите на наш славный аутсорс образца 2000-х!). В кризис сервисы первыми идут под нож, так что…

Что же делать, когда не знаешь, что делать? Тут ничего нового не придумано — придерживайся хоть какого-то плана. Продолжай движение хоть куда-то, чтобы не остаться на месте. У тебя же был какой-то план на пять лет, вроде выучить немецкий, выучить питон и эмигрировать в Старую, скажем так, Зеландию — достаём учебник и продолжаем учить по нему питон, не обращая внимания на все эти ваши AI, просто потому, что больше заняться нечем. Может той Зеландии и не будет — будет что-то другое, сейчас неочевидное.

Если потерялась вся профессия — забываем про торты и доставку гаджетов с Amazon, смотрим кругом и коммитимся на любую чухню, которая подвернётся, просто чтобы была возможность оплачивать коммуналку, а там уже куда кривая молдавской эмигрантской мечты вывезет, stay tuned…

]]> https://testitquickly.com/2026/11/03/trebuiala/ Tue, 03 Nov 2026 14:23:22 +0300 Автор: Ренато Руджеро (Renato Ruggiero)
Оригинал статьи
Перевод: Ольга Алифанова

Тестирование программного обеспечения как можно раньше в цикле разработки – это широко признанная лучшая практика: чем раньше обнаружен дефект, тем дешевле его исправить. В этом заключается суть подхода со сдвигом влево (shift-left).

Но когда речь идёт о встроенных системах, таких как системы, используемые в промышленности, Интернете вещей (IoT) или автомобильных приложениях, слово «рано» приобретает особое значение. Представьте, что вы можете тестировать программное обеспечение вашего электронного блока управления (ECU) сразу после того, как устройство становится доступным, даже если среда, с которой оно будет взаимодействовать, например автомобиль, производственная линия или облачный сервис, ещё не готова.

Именно здесь на помощь приходит тестирование hardware-in-the-loop (HIL). HIL-тестирование — это метод тестирования в реальном времени, при котором встроенное программное обеспечение работает на целевом аппаратном обеспечении и взаимодействует с имитируемой средой, воспроизводящей реальные сигналы и поведение. Это позволяет выполнять валидацию на уровне системы ещё до появления физических прототипов.

]]> https://www.software-testing.ru/library/around-testing/processes/4542-agile-hardware-testing Sun, 01 Nov 2026 23:00:00 +0300  

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

И вот я все подняла, запускаю запрос в приложение 1, который должен скачать справочник и положить его в папку приложения 2. Огребаю «permission denied».

Перепроверили права по инструкции, все есть. Начали диагностику, в том числе снимать strace, который почему-то не сработал во время ошибки. И тут я вижу в рассуждениях ChatGPT:

У нас есть два возможных сценария:

• Ошибка появилась в приложении 2 и одновременно зафиксирована в strace — увидим конкретный системный вызов и причину отказа.

• Ошибка появилась в приложении 2, но обращения к файлу в strace нет — возможно, загрузку выполняет другой процесс, а не Java с PID 8459.

Я ж ему исходно просто лог скинула и спросила "как убедиться, что права нужные?", а в логе было "не могу положить файл в папку приложения 2", вот он и подумал, что именно оно падает.

Скидываю ему результат выполнения последних запросов и добавляю: «только ошибка в приложении 1, а не 2, оно пытается файл сохранить». Ответ чатика:

Ну, по крайней мере мы поняли, почему strace ничего не поймал ????

И чатик выдал уже новые инструкции. 

Вывод

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

 

]]> http://okiseleva.blogspot.com/2026/10/blog-post_29.html Thu, 29 Oct 2026 11:04:42 +0300

Первый опыт, второй, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 

19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34

Что это за техника

Вы собираетесь с друзьями в группу и ставите себе цели на 12 недель (3 месяца). Это могут быть как рабочие, так и личные задачи. Такие, которые вы вроде как хотите сделать, но вечно откладываете, так как «некогда, потом, щас, вот только мелочевку разгребу и тот пожарчик потушу».

Настало время заняться тем, чем действительно хочется!  Отталкиваясь от глобальных целей, составляете план на неделю. И раз в неделю встречаетесь с группой и обсуждаете, сколько успели, сколько нет. Какой план на следующую неделю. Я, правда, уже давно не встречаюсь, а просто веду файлик "что сделано", откуда потом и просматриваю всё, что успела за цикл.

Результаты кратко

Основной план:

- ????книга по тайм-менеджменту — написать 5 глав

- ????выпустить курс по ИИ

- ????сделать 1 тему нового курса

- ????1 статья на Хабр

- ????2 видео на ютуб

Осень, осень... Время года то, конечно, золотое, но это здравствуйте, болезни, и до свидания, привычный уклад — так как средний сын пошел в садик! Летом иногда получалось до прихода няни в 10 утра поспать. Ему ))) А нам развлекать только дочку. Всяко проще, чем обоих!

А я еще взяла себе больше рабочих часов на основной работе. Это очень интересно, так как активно использую ИИ-агентов, что полезно и на работе, и вне ее (как тренеру курсов). Но еще сложнее встроить сюда спортзал и отдых. И прям паникуешь в очередной "ой, я приболела" няни...

А еще я тут вписалась в SQA Days и Analyst Days и готовилась к ним, очень много времени это все выжрало. Хотя мои доклады в резерве, подготовку это не отменяет...

Но на самом деле мой основной план — это книга и курсы. Я ими и занималась. С курсами не вышло успеть, что задумала, а с книгой получилось. Уже хорошо! Что я успела за этот цикл:

1. Книга 5, ChatGPT:
1. прошли верстку
2. прошли вычитку корректором
3. сдали в печать! Ждем ))))
2. Книга 6, тайм-менеджмент — уже 18 глав ????
3. Курсы:
1. автоматизация в Postman — доделала!
2. новый курс — записала, работаю над ним ????
4. Статьи на Хабр — 0 статей ????
5. Пополнила свой youtube-канал — 3 видео ????
6. Подала доклады сразу на 2 конференции — SQA Days и Analyst Days
7. ДР Влада: 8 лет
8. Госпитализация с Катей, сделали лазер
9. Начали отмену атенолола (неужели дождалась?!!)
10. Купили 3д принтер))
11. Поседела, получив квитанцию на 80 тысяч квартплаты)

Результаты подробнее

Книга 5: ChatGPT

Прошлый цикл:

• 9 июня — начали редактуру.
• 22 июля — начали верстку (хотя редактура еще не закончилась)

В итоге:

• 30 июля — закончили редактуру
• 31 августа — закончили верстку

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

Книга 6: тайм-менеджмент

• Прошлый цикл — 5 глав
• Текущий — 18 глав

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

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

Курсы

Автоматизация в Postman

Прошлый результат — 14 уроков готовы

Текущий — все закончено, ура!

Я планировала потратить на это сильно меньше времени, но как есть. В прошлый раз у меня уже было все готово, но Постман взял и кучу всего наменял. Так что мне пришлось переписать часть видео снова. Ну и ладно, НАКОНЕЦ-ТО я это закончила!

Подробнее писала тут — Курс автоматизации в Postman полностью обновлен!

Новые курсы

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

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

В общем, отмазок громадье, но в конце сентября я ужаснулась тому, что за месяц вообще ничего не сделала. Взяла себя в руки и начала ДЕЛАТЬ, а не только планировать.

Так что скоро выйдет новый курс — по ИИ-агентам. И есть планы на следующий, постараюсь там так не тупить уже. Ну а что из этого выйдет, узнаем в следующий раз ????

Хабр

Увы, в этот раз не дошли руки, хотя была пара идей. 

Блог

Продолжаю писать посты про ИИ. Хотелось бы больше, но... Работа поглощает)

Курсор, куда ты лезешь? Эх, не прокатило...

Как мне ИИ помог в Redash разобраться

А я тебе говорю, оно работает! (ИИ косячит)

И еще один пост про книги сделала, когда мне на качество покупки пожаловались, а это оказались пираты — Осторожно, пираты! (бумажные книги на озоне).

Youtube / ВК

Мой канал — https://www.youtube.com/c/okiseleva (Дубль в ВК).

Обновления в этом цикле:

1. Курсор пропал! На что меняем?
2. Как я за пару минут сделала приложение с API через Cursor
3. Как я перенесла код с bitbucket на GitHub через Cursor

Конференции

Подала доклады сразу на 2 конференции — SQA Days и Analyst Days ＼(〇_ｏ)／

Все дело в том, что я не шибко выездная пока, так что мне подходит вариант "конференция в Москве". А тут обе в Москве, а у меня идеи есть!

В итоге подала доклады, и понеслось. На этой неделе встреча с кураторами одной конференции, надо готовиться. На следующей — встреча с кураторами второй конференции, надо готовиться...

На SQA Days я подавалась на волнах эйфории от крутой штуки с ИИ, но, пообщавшись с кураторами, поняла, что конкретно эта тема неинтересна. Переобулась, поменяла направление доклада, мне поменяли кураторов (разные направления, технический и обычный доклады). Снова готовиться!

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

Ну а пока... Я в резерве, на конференциях буду, может даже буду выступать. А если нет, буду думать, куда отнести потом свои доклады, а то жалко же, готовилась... В Московский клуб тестировщиков, наверное))

Магия утра

Вернулась к этой технике тайм-менеджмента, пока радует:

Магия утра! Катя спит, ура ура

Такой кайф, когда дети спят, а у тебя есть свободное время! Жаль, это было ровно до сентября ))) Да и Катя то спала до 9-10, то подскакивала в 7 утра, так что магия у меня не каждый день...

Но практикую, как могу. Посмотрим, надолго ли ее хватит в этот раз. За лето я выдохлась, тяжело вставать в 7 утра КАЖДЫЙ день, без выходных. Но есть планы продолжать вставать и после отмены лекарства (об этом ниже), просто уже через день. Поспать - поработать, и так по кругу.

Внерабочее

ДР Влада: 8 лет

Старшенький уже большой, во второй класс пошел! Фоткаться на 1 сентября, правда, отказался, уже не по возрасту )

А на день рождения Влада мы купили... 3д принтер)) 

Он решил на него копить, а муж говорит "неправильно будет, если ребенок купит, а мы будем пользоваться", я то тоже давно хотела. Решили вместе копить, а потом ему бабушки почти половину суммы подарили! В итоге взяли принтер, печатаем всякое, таких драконов, например:

Сын доволен!

ДР бабушки

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

Младшие детки

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

Леша уже разговаривает неплохо, "я сын!", "я сам бай" и так далее. У него много событий новых. Мы подстриглись, например!

Буквально полгода назад это были истерики и слезы, последний раз он уже понимал, что ничего страшного нет, в этот раз совсем спокойный был. Растет!

В сентябре Леша пошел в садик на полный день. Но не с 1 числа, а с 15-ого, так как у нас была госпитализация с Катей и я каждый раз паникую, что она заболеет невовремя, а это может отодвинуть госпитализацию аж на 2 месяца, и снова все анализы пересдавать...

Тем не менее в садик вышел, и ему понравилось! А я так и думала, что ему садик зайдет. Мы еще и велосипед для двойни купили, потому что сначала отвели сына одного, а Катя уже встала к тому времени и очень громко возмущалась, почему это брат пошел гулять, а она нет )))

Потом мы стали возить их так: 

• в садик — сын в велосипеде, дочь в коляске
• назад — дочь в велосипеде, второй родитель везет пустую коляску

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

Так что заказали такую красоту (поискала на авито, на озоне в итоге дешевле вышло, и привезли через неделю):

Теперь у нас один спит / работает, второй развозит детей — туда оба едут, назад одна)) 

И благодаря этому муж может доспать, а у меня есть магия утра! 

Госпитализация

Снова были с Катюшкой в больнице Святого Владимира, красиво там:

Нам сделали лазер (гемангиомы, это как огромная родинка) и сказали, что всё, можно отменять Атенолол — а это сильное лекарство, поэтому отмена идет 7,5 недель.

И вот сейчас я пишу эти строки, а у нас сегодня первый день БЕЗ лекарства, ю-ху! Я так ненавидела его порой, ведь его надо давать СТРОГО по часам. Летом бывало, что я принесу лекарство в 8 утра, доча спит. Я ей впрыскиваю из шприца в рот, она проглотит, отвернется и дальше спать.

А у меня счастье и релакс. Но чаще всего она просыпалась при попытке дать ей лекарство, и я в это время всегда его ненавидела. И вот, наконец! Дождалась! Больше этого делать НЕ надо, ура-а-а-а! 

Год принимали лекарство и ездили на лазер. И вот она, свобода!

Няни

Началась осень, пора простуд... Няни болели, мы выкручивались. Повезло, замену всего 1 раз не нашли, и как раз тогда ко мне Наташа в гости приехала, пока я с Катюхой гуляла (а Леша вроде в садике был).

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

Но, тьфу-тьфу-тьфу, это редкость. Пока на работе дети не сказываются практически)

Всякое

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

А еще я получила квитанцию за квартиру, которую мы сдаем — на 80 тысяч рублей... Там квартиранты пару лет живут, они сначала сдавали показания счетчиков, потом забили и платили по общедомовому. 

А тут пора было поверку делать, ну мастер пришел, все сделал, в итоге показания автоматически подали. И выяснилось, что они тратят ОЧЕНЬ много воды... Ходили в УК, разбирались, и нет, это не ошибка (((

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

Проверка планов, поставленных в прошлый раз

Основные цели:

• ????Книга по ChatGpt — закончить редактуру → и редактуру, и верстку закончили!
• ???? Книга по тайм-менеджменту — написать 3 главы, по одной в месяц норм план! → сделала 13! ????
• ???? Курсы — закончить с постманом уже!
• ???? Курсы — сделать 1 тему нового курса → одну тему, кстати, сделала)
• ???? Статья на Хабр — ну хоть одну! 

Найс ту ду:

• ???? Youtube-канал — 2 шт 
• ???? Книга по Python — прочитать 100 страниц (хочется снова к ней вернуться)
• ???? Встретиться с друзьями 

Планы на следующие 12 недель

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

Основные цели:

• Книга по тайм-менеджменту — написать 6 глав, по 2 в месяц!
• Курсы — выпустить курс про ИИ
• Курсы — сделать 1 тему нового курса
• Статья на Хабр — ну хоть одну! 

Найс ту ду:

• Youtube-канал — 2 шт 
• Встретиться с друзьями 

Итого

Ого, в этом цикле я еще вычитывала книгу по ИИ! Кажется, что так давно это было)))

Всегда забавно оглядываться назад, особенно на самое начало цикла. Перелистать заметки и заметить, как много я успела сделать, а то ведь кажется, что почти ничего. А так вроде получается, и это при том, что я вышла на работу и взяла себе побольше часов (поменьше на остальные активности осталось).

Планов на следующий цикл громадье! Да там не на один цикл теперь хватит, поэтому надо пахать, что я и пошла делать)

]]> http://okiseleva.blogspot.com/2026/10/12-35-8.html Thu, 29 Oct 2026 07:58:21 +0300

Статья из блога компании ИнфоТеКС Tech

Как тестировать систему, если половина её компонентов — это «чёрные ящики» с уникальными протоколами, а стандартные API-mocks не справляются? С точки зрения готовых решений — тупик… 

Меня зовут Дмитрий, я AQA-инженер в ИнфоТеКС. Мы с командой столкнулись с этой проблемой и создали собственные API-mocks, которые не просто отвечают шаблонными сообщениями, а ведут себя как настоящие компоненты системы. В этой статье — наш путь от идеи до работающего решения, которое можно адаптировать под ваши задачи. 

]]> https://www.software-testing.ru/library/testing/testing-automation/4568-api-mocks Tue, 27 Oct 2026 23:00:00 +0300 Автор: Эди Стоукс (Ady Stokes)
Оригинал статьи
Перевод: Ольга Алифанова

Странно, правда, получать деньги за использование своего мозга?

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

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

]]> https://www.software-testing.ru/library/testing/general-testing/4541-i-think-therefore-i-test-the-importance-of-thinking-for-testers Sun, 25 Oct 2026 23:00:00 +0300

Меня зовут Семён Ремезов, я Senior QA в компании «Гринатом» (мы пишем софт для «Росатома»).

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

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

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

Мы внедрили у себя security-лейблы в Postgres Pro Enterprise для анонимизации, и этот путь был, мягко говоря, тернистым. Если вы думаете, что анонимизация — это просто скрипт UPDATE users SET name = 'Ivan', то у меня для вас плохие новости.

Давайте разберём, как мы построили процесс, почему отказались от дорогих «коробочных» решений и как заставили Postgres 15-й версии работать нормально.

]]> https://www.software-testing.ru/library/testing/security/4566-security Tue, 20 Oct 2026 23:00:00 +0300

От функциональной приемки до нагрузочных и аварийных испытаний. Полезно для CTO, CIO и владельцев продуктов.

Мы вошли в эру все более нестабильного интернета. Прежняя уверенность в неуязвимости облачных систем рассыпалась, оставив трезвое осознание, что так как раньше, больше не будет. Недавняя критическая ситуация с дата-центрами в России показала бизнесу, как важно иметь план Б. Практически все игроки IT-рынка получили повод серьезно задуматься о диверсификации данных по разным ЦОД. 

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

Представьте, сервера запустились, база перенеслась, мониторинг светится зеленым. Миграция удалась, не так ли? 

Не обязательно. Пользователь не покупает виртуальную машину: он оплачивает заказ, получает выписку, оформляет заявку. Если эти операции после переезда перестали работать или выполняются втрое дольше, то бизнес несет потери.

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

Что меняется при IT-миграции, даже если код не трогали?

Начнем с определения. Миграция – это перенос приложения или его частей на другую технологическую базу: в новый ЦОД, облако, кластер Kubernetes, СУБД, хранилище, либо к другому поставщику API. При смене хоста меняется в основном среда; при смене платформы – платформенные компоненты; при рефакторе – еще и поведение приложения. 

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

Чтобы структурировать результаты, удобно делить критерии успеха на три уровня: 

• технический (компонент работает);
• продуктовый (сквозной пользовательский сценарий работает);
• операционный (сервис выдерживает реальную нагрузку, сбой и восстановление). 

Именно третий уровень (операционный) позволяет отвечать за непрерывность бизнеса.

Риск после переезда	Что видит бизнес?	Как QA закрывает риски?
Скрытая зависимость или новый сетевой маршрут	Иногда не проходит оплата, пропадают уведомления	Сквозные сценарии, контрактные тесты, сбои внешних API
Ошибки переноса данных и CDC	Разошлись остатки, заказы, права доступа	Сверка ключевых сущностей, сумм, связей, лагов репликации
Новая конфигурация вычислений/БД	Падение конверсии и нарушение SLA	Базовая линия, реалистичная нагрузка, p95/p99, ошибки
Непроверенное восстановление	Простой длится часы вместо минут	Failover/restore, измерение RTO/RPO и репетиция отката
Новые IAM, секреты, сетевые правила	Утечка данных или доступы не работают	Проверки ролей, запретов, TLS, секретов, аудита

Объясняем на примерах: как компании обжигались при миграции данных

TSB Bank: перенести данные – не значит перенести сервис

В апреле 2018 года шотландский TSB переводил банковские сервисы на новую IT-платформу. Перенос данных сам по себе состоялся, но после переключения возникли серьезные проблемы с обслуживанием через отделения, контакт-центр, цифровой и мобильный банк. Регуляторы указывали на недостатки управления миграцией, испытаний, контроля рисков и готовности к инцидентам. Проблемы затронули значительную долю 5,2 млн клиентов; в 2022 году FCA и PRA (британские регуляторы) оштрафовали банк на £48,65 млн.

Да, возможно, дополнительное QA-тестирование не предотвратило бы катастрофу гарантированно, так как причины были организационными и техническими. Но именно комплексная приемка реальных бизнес-процессов, проверка объема и пиков нагрузки, заранее заданные критерии Go/No-Go и операционные репетиции дали бы руководству основания вовремя остановить переключение.

Knight Capital: одна ошибка вызвала крах бизнеса

В августе 2012 года Knight Capital (один из крупнейших участников фондового рынка США) ошибочно развернула торговое ПО: обновление попало не на все серверы, а старый компонент неожиданно начал отправлять некорректные заявки. По данным SEC, за 45 минут система отправила более 4 млн заявок, а убытки превысили $460 млн. Это не пример инфраструктурной миграции в узком смысле, но точная иллюстрация риска перехода.

Контрмеры для миграции в QA: контроль артефактов и конфигурации на каждом узле, проверки однородности среды, канарейки, ограничение масштаба ошибок, кнопка остановки и мониторинг бизнес-эффектов, а не только CPU. 

Кстати, KCG так и не смогла оправиться от инцидента как независимый бизнес. Технический сбой 1 августа 2012 года нанес фирме непоправимый ущерб, который привел к потере самостоятельности и последующему поглощению.

Cloudflare: пример грамотного переноса инфраструктуры

В 2024 году Cloudflare описала в своем блоге перенос активной DNS-базы, содержащей миллиарды записей. Команда применяла: перенос партиями, многонедельную синхронизацию изменений, проверки исходной и целевой базы и контролируемое переключение записи. Обнаружились даже редко используемые сервисы, упущенные при инвентаризации, а предусмотренный путь возврата помог их обработать. Это не универсальный рецепт для любой СУБД, но сильный пример совмещения проверки данных, постепенности и готовности к исключениям.

Что именно проверяет команда тестирования?

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

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

Тестируются полные цепочки: авторизация — действие — запись в БД — событие — внешний сервис — статус пользователя — журнал аудита. 

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

Интеграции и данные

Проверяются API-контракты, версии схем, TLS, сертификаты, DNS, тайм-ауты, ретраи, идемпотентность, DLQ, порядок и доставка событий. 

Для миграции СУБД дополнительно нужны полнота, уникальность, контрольные суммы, агрегаты и референциальная целостность. Равенство количества строк – лишь первый фильтр: 10 млн перенесенных записей не гарантируют, что верно посчитан баланс каждого клиента.

Если использована CDC-репликация, QA отдельно фиксирует допустимый лаг, момент остановки записи, финальную сверку, специфические сценарии и то, кто является единственным источником истины после перехода. Автоматическая валидация в AWS, например, сравнивает строки, но сама по себе не заменяет проверку бизнес-инвариантов.

Нагрузка, производительность и устойчивость

Руководителю важно знать не сколько RPS выдержал кластер, а как меняются успешные заказы, задержка и ошибки при реальной структуре трафика. Грамотно сначала снять базовые показатели на старой платформе: профиль запросов, суточные пики, распределение транзакций, p50/p95/p99, долю ошибок, очередь, CPU, память, DB locks и внешние лимиты. Затем повторить профиль в сопоставимой целевой среде.

Набор испытаний: baseline-сравнение; ожидаемый пик; spike-тест (резкий всплеск); стресс-тест до найденной точки деградации; отказоустойчивости под нагрузкой. Генератор должен создавать не абстрактные запросы к главной странице, а сочетание чтений, изменений, фоновых задач и вызовов подрядчиков. Особое внимание – «тихим» отказам: очередь растет, но HTTP по-прежнему отвечает 200.

Например, для сервиса с 100 заказами/мин в обычный час и 400 в промо-пик можно согласовать испытание на 400 заказах/мин плюс реалистичный фоновый поток и запас, выведенный из прогноза роста. Критерий не «150% потому что так принято», а бизнес-SLO: скажем, 99,9% корректно оформленных заказов за целевой период, p95 времени оформления по утвержденному порогу, отсутствие потери и дублирования. Все числа в этом примере условные, не отраслевой стандарт.

Безопасность, отказоустойчивость, наблюдаемость

При смене платформы проверяют по принципу минимальных привилегий, service accounts, смотрят секреты и их ротацию, шифрование и маскирование, сегментацию сети, логи доступа и аудит. Технический пентест не заменяет проверки бизнес-прав: менеджер не должен внезапно видеть чужие договоры.

Отдельно моделируются недоступность ноды, зоны, БД, очереди, платежного шлюза. Измеряются RTO – фактическое время восстановления – и RPO – фактический объем потери данных во времени; их сравнивают с заранее согласованными пределами. Проверяется именно восстановление из резервной копии, а не сообщение «backup successful». Также чекаются алерты: кто, по какому сигналу и за сколько минут узнает о сбое.

На каком этапе миграции приглашать QA и как организовать работу?

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

Этап	Работа QA и команды	Артефакт для решения
0. До выбора окна	Product + QA выделяют 5–10 критических путей; Infra/Data строят карту зависимостей; SRE снимает базовые показатели	Согласованы ущерб, SLO, RTO/RPO и границы тестирования
1. Среда готова	Infra разворачивает целевую инфраструктуру; QA проверяет соответствие конфигураций,  также интеграции, данные, права	Target пригоден для функциональных и нагрузочных прогонов
2. Перед переносом	QA ведет регресс/UAT; performance команда – профили нагрузки; SRE – отказоустойчивость; все репетируют пошаговый план и откат на случай если все пойдет не по плану	Протокол дефектов, доказательства SLO и восстановление
3. Переключение	Infra исполняет пошаговую карту; QA – смоук-тесты критических сценариев; SRE – метрики и алерты; РП принимает бизнес-показатели	Разрешено расширить трафик либо выполнен откат
4. После старта	QA и SRE сравнивают базовые показатели, сверяют данные/очереди, наблюдают суточные циклы и фоновые задания	Закрыт испытательный период, ответственность передана эксплуатации

Роли и зоны ответственности нужно назначить конкретно: владелец продукта отвечает за допустимый бизнес-риск; руководитель миграции – за последовательность и окно; QA lead – за стратегию, качество доказательств и остаточные дефекты; Infra/Data – за среду и миграцию; SRE – за SLI, реакции на аварии и восстановление; Безопасность – за доступы и контроль данных.

QA формирует рекомендацию, а решение по конкретным действиям принимает уполномоченный владелец риска. Не тестировщик, который поставил галочку.

Мини-план: какие именно проверки запускать перед переключением

Шаг 1.  Составить реестр компонентов и невидимых зависимостей: сервисы, БД, очереди, планировщики, batch, FTP/SFTP, SMTP, SSO, DNS, API партнеров, сертификаты, IP allowlists. Для каждой зависимости – ответственный и сценарий отказа.

Шаг 2.  Снять базовые показатели старой системы на одной и той же модели данных и нагрузки. Установить пороги выхода: SLI, SLO, бизнес-ошибки, p95/p99, объем очередей, долю тайм-аутов; пороги утвердить с продуктом.

Шаг 3.  Подготовить правдоподобную целевую инфраструктуру: версии, лимиты, сетевые пути, объемы данных, обезличенные или синтетические наборы. Отдельно отметить отличия тестовой среды от продакшена – иначе нагрузочные выводы ограничены.

Шаг 4.  Исполнить риск-ориентированный набор проверок: smoke — сквозные сценарии — сверка данных — безопасность — нагрузка — аварии. Критические сценарии автоматизировать и сохранять трассы, логи, результаты прогонов.

Шаг 5.  Провести репетицию переезда на копии: синхронизация, финальная сверка, «заморозка» записи, переключение, прогон smoke, возврат трафика. Измерить время каждого действия. План отката проверять с учетом изменений данных, появившихся уже после старта.

Шаг 6.  Установить режим поэтапного включения.

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

Как выглядит конкретный тест: от риска до доказательства корректности миграции

Сценарий	Проверка и ожидаемый результат
Пользователь платит, но API отвечает timeout	Повтор запроса с тем же ключом идемпотентности: деньги не списаны дважды; итог виден в заказе и финансовом реестре.
Перенос данных прерван на середине	Повторная догрузка без потери/дублирования, сверка критичных сумм, контроль ссылок и временных меток.
Падение узла под пиковым трафиком	Ошибки и p95 остаются в согласованных пределах либо система деградирует предсказуемо; фиксируется время восстановления.
Новое сетевое правило блокирует callback	Проверка всех партнерских интеграций с реальными TLS/DNS-маршрутами, ретраями и DLQ.
Решено откатиться спустя 20 минут	Проверяется процедура возврата трафика и согласования накопившихся записей; если обратная синхронизация невозможна – заранее определен forward-fix.

Тест считается полезным потому, что у него есть в основе закрытие конкретного риска, предусловия, шаги, наблюдаемый оракул и сохраненное свидетельство: ID транзакций, diff данных, график p95, трасса и время восстановления. Именно эти факты должны рассматриваться миграционным комитетом.

Главный вопрос CTO перед переносом инфраструктуры в идеале должен звучать так: «Какие бизнес-потери мы уже исключили с помощью тестирования, какие еще возможны и что мы сделаем в первые 5 минут, если прогноз окажется неверным?» Если у команды есть четкий и, главное, аргументированный ответ, миграция становится предсказуемой. 

Кого привлекать: своих тестеров или внешнюю QA-команду?

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

Мы в «Лаборатории Качества» предлагаем начать разумно: не с закупки тысячи тест-кейсов, а с короткой диагностической сессии, где разберем: тип миграции, карту сервисов, критичные операции, доступные стенды, базовые показатели, допустимый простой и цену ошибок. По результатам составим план испытаний с оценкой трудозатрат, приоритетов, артефактов и точек принятия решения. Начать очень просто – запишитесь на бесплатную консультацию. 30 минут концентрированного профессионального общения без продаж и обязательств.

]]> https://quality-lab.ru/blog/prakticheskoe-rukovodstvo-po-testirovaniyu-migracii-cifrovoj-infrastruktury/ Mon, 19 Oct 2026 17:38:22 +0300 Автор: Джуди Мосли (Judy Mosley)
Оригинал статьи
Перевод: Ольга Алифанова

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

Спустя годы работы в тестировании я поняла, что QA — это не просто проверка того, есть ли тут баг. Качество — это умение отстраниться и оценить все типы циклов обратной связи. Это может быть процесс, встречи, в которых мы участвуем, отчёты или формы регистрации багов. Оценка наших циклов обратной связи может помочь нам понять, получаем ли мы эффективную обратную связь, необходимую для принятия чётких решений.

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

]]> https://www.software-testing.ru/library/around-testing/management/4539-candy Sun, 18 Oct 2026 23:00:00 +0300 Автор: Поролло Глеб Владимирович, Инженер по нагрузочному тестированию

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

Через неделю тебя включают в список на сокращение. Это не страшилка. Это реальность для тестировщиков, которые считают, что быстрая личка эффективнее формального баг-трекера. В этой статье я расскажу, с какими рисками сталкиваются тестировщики ЛАНИТ и других ИТ-компаний, когда заменяют баг-трекер личными переписками, и как это защитит твою карьеру.

]]> https://www.software-testing.ru/library/around-testing/processes/4564-minor-bug Wed, 14 Oct 2026 23:00:00 +0300

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

Теперь поговорим о метриках, российской специфике и плане наведения порядка в QA-процессах за 90 дней. Пристегните ремни, приступаем! Полезно тестировщикам, техлидам и продакт-менеджерам, которые работают на проектах без чётких требований и ТЗ.

На какие метрики опираться?

Трудно измерять то, что не прописано в ТЗ. Привычные способы здесь не работают. Процент покрытия требований посчитать нельзя, количество тест-кейсов не показывает ничего, кроме усердия QA-инженеров, а число найденных багов двусмысленно: их много, потому что тестировщики хорошие или потому что разработка плохая? Мы предлагаем остановиться на 5 честных показателях – всего 30 минут в неделю на сбор и вы получите качественные данные для управленческих решений.

Пять метрик и что с ними делать

Метрика	Как считать	На какой вопрос отвечает	Что делать, если плохо
Первопричина дефектов	Каждый баг помечается: непонятое требование, код, интеграция, данные, среда	Мы вообще ту проблему решаем?	Доля «требований» выше 30% — вкладывайтесь в контур 1, а не в автотесты
Утечка в прод	Дефекты, найденные пользователями, к найденным до релиза	Работает ли приёмка в принципе?	Разбирайте каждый утёкший баг вопросом «в каком контуре он должен был всплыть»
Возраст открытых вопросов	Сколько дней живут красные карточки и вопросы из сессий	Отвечает ли бизнес на наши вопросы?	Выше пяти дней — проблема не в QA, а в доступности того, кто принимает решения
Доля переделок	Задачи, вернувшиеся на доработку после демо, к общему числу	Насколько мы попадаем в ожидания?	Растёт — учащайте контур 2. Обычно спасает переход на показ раз в два дня
Доля неудачных релизов	Релизы с откатом или срочным хотфиксом (change failure rate из DORA)	Сколько стоит наша скорость?	Выше 20% — не ускоряйте тестирование, а стройте быстрый откат и фича-флаги

Практика. Про первую метрику хочется сказать отдельно: нам она буквально перевернула приоритеты. Полгода классификации багов на 4 проектах дали среднюю картину – 34% дефектов возникали из-за неправильно понятого требования. Треть работы обеих команд уходила на исправление недоговоренностей. Это поменяло расчет вложений в тестирование, так как автоматизация не уменьшала эти 34% ошибок, а только проверяла реализацию того же непонятого требования. Нашли проблему с Example Mapping за 20 минут. После трёх месяцев работы первого контура доля таких дефектов упала до 12–15%.

Стек в российских реалиях

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

Инструментальный контур приёмки

Задача	Международный стандарт	Что работает у нас	Комментарий
Карта продукта, журнал решений	Confluence, Notion	Yandex Wiki, Teamly, Yonote, Outline, Wiki.js	Требование одно: версии и поиск
Трекер задач и рисков	Jira, Linear	Яндекс Трекер, Kaiten, YouGile, Weeek, EvaTeam	Реестр рисков живёт отдельной доской. Для Example Mapping хватит Яндекс Борда или бумажных стикеров
Управление тестированием	TestRail, Xray, Zephyr	Test IT, ТестОпс (Qameta), DoQA, Devprom ALM	Нужен, когда появились регресс-чек-листы и автотесты
Автотесты, контракты, нагрузка	Playwright, Postman, Pact, k6	Playwright, Selenium, Hoppscotch, Apidog, Яндекс.Танк; Pact ставится локально	Открытый код, ограничений нет. OpenAPI держите рядом с кодом
Мониторинг и алерты	Datadog, New Relic	Grafana + VictoriaMetrics, Zabbix, GlitchTip	Контур «ловим в проде» без этого не строится вообще
Фича-флаги	LaunchDarkly	Unleash, Flipt, самописные на конфиге	Самое дешёвое вложение с самой высокой отдачей. Начните с него

Кейс: миграция биллинга без актуальных требований и нормального ТЗ

Кейс обезличен (NDA): региональный телеком-оператор, миграция биллинга, 11 месяцев работы.

Ситуация

Заказчик готовился к переезду со старой биллинговой системы, которая работала уже 11 лет, на новую. Подрядчик, создавший первоначальную архитектуру, уже не существовал. Документация состояла из 4 томов 2014 года про систему, с тех пор изменившуюся до неузнаваемости. Людей, помнящих логику, осталось всего двое, но оба уже работали в других департаментах. Требование к проекту было написано одной строкой: «Абонент не должен заметить перехода». За ним стояли 340 тысяч абонентов, 60 тарифов, 14 акций и 11 лет истории начислений с перерасчетами и ручными корректировками.

Что мы предприняли?

Первые два месяца были в режиме Шерлока Холмса: аналитики восстанавливали требования по документам и интервью. Описали 40% тарифной логики, наткнулись на противоречие – и выяснили, что описание расходится с реальностью примерно в каждом пятом случае.

Люди помнили, как задумывалось, а не как получилось после 11 лет правок. Сроки переехали на квартал, подход пришлось менять целиком.

• Сменили диагноз. Начали с утерянных знаний, а лечили чуть другим способом. Эталоном объявили поведение старой системы, а не представления о нем.
• Построили карту продукта по SFDIPOT за 9 дней. Нашли 11 фоновых задач, о которых не знал никто из действующих сотрудников. Например, одна ежемесячно корректировала начисления 900 корпоративным клиентам.
• Собрали дифференциальный стенд. Обе системы получали один поток обезличенных событий за реальный месяц – 47 млн триггеров тарификации. Результаты сравнивались автоматически. Расхождения раскладывали на три корзины: ошибка новой системы, ошибка старой, сознательное изменение. Третья корзина и стала тем документом требований, который не получалось написать заранее.
• Ввели журнал решений. 214 записей для решений, воспроизводим то или иное поведение или исправляем. Журнал позже стал документацией к новой системе.
• Приемку сделали в 9 волн: 200 абонентов на простейшем тарифе, потом 5000, потом сегмент за сегментом. После каждой – сверка начислений.

Результат

Миграция заняла 11 месяцев вместо плановых восьми. Но план строился на основе фантазий о том, что требования можно восстановить всего за два месяца. От смены подхода до финала прошло 9 месяцев без сдвигов. Нашли 1 847 расхождений, из них 1 203 оказались ошибками старой системы, которые годами никто не замечал. Жалоб на начисления за первый месяц – 34 при прогнозе в несколько тысяч.

47 млн

событий прогнали через обе системы на дифференциальном стенде

1 203

ошибки старой системы, о которых не знали одиннадцать лет

214

записей в журнале решений, ставших документацией к новой системе

34

жалобы абонентов за первый месяц после перехода

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

План внедрения QA-стратегии на проектах без требований на 90 дней

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

90 дней: от хаоса к предсказуемой приёмке

День 1

День 30

День 60

День 90

Месяц 1 · Видимость Ничего не ломаем, только смотрим Поставить диагноз (раздел 1) Собрать карту продукта Начать журнал решений Размечать баги по первопричине Результат месяца: знаете, из чего состоит продукт и откуда берутся дефекты

Месяц 2 · Контур входа Самая высокая отдача на вложение Три вопроса на каждой задаче Example Mapping на сложных Первый RiskStorming на релиз Показ заказчику раз в 2–3 дня Результат месяца: доля дефектов из-за требований падает вдвое

Месяц 3 · Форма и защита Закрепляем и защищаем от отката Перейти на чартеры и сессии Ввести протокол приёмки Фича-флаги на рискованное Автотесты на стабильное ядро Результат месяца: решение о релизе принимается по документу, а не по ощущениям

Соблазн начать с третьего месяца велик — там всё выглядит солиднее. Но протокол приёмки без карты и реестра рисков превращается в бумажку.

Отдельно про то, как преподнести план команде

Не называйте это методологией, чтобы не вызвать сопротивление. Мы начинали с малого, в стиле «давайте месяц помечать баги по типам причин, интересно же». Это было в легкой непринужденной форме, и через месяц цифры сказали все сами.

Внедряйте первым то, что снимает боль команды, а не вашу. Разработчиков мучают переделки – начинайте с контура входа, и вас поддержат. Бесполезно проводить для всей команды обучающий воркшоп на полдня. У нас не сработало ни разу: люди кивают, а в понедельник работают как раньше. Лучше показывайте на своем примере: делаете задачу и демонстрируете результат. А заодно показываете, как это вам удалось. Обучение происходит органически.

Распространённые ошибки в QA без ТЗ

Четыре ошибки, с которыми сталкиваются почти все. Предупрежден — значит вооружен. 

1. Отказ приступать к работе без ТЗ – после такой позиции вас перестают звать на ранние обсуждения.
2. Тест-кейсы на все подряд: через два месяца их 300, актуальны 100, и все пятницы уходят на выяснение, какие именно действительно нужны. 
3. Автоматизация первым ходом – на меняющемся продукте UI-автотесты дают обходится очень дорого при сомнительной пользе.
4. Баги на все, что не нравится: без ТЗ граница между багом и сомнительным моментом, о котором просто не договорились — размыта. Спорное заводите вопросом в журнал решений.

Теперь важные оговорки

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

Вторая: подход требует QA-инженеров высокого уровня. Прогнать 200 тест-кейсов может человек после двухмесячных курсов. Провести сессию по чартеру, задать правильные вопросы на Example Mapping и понять, что мелочь на экране – это симптом крупной проблемы, может только человек с опытом и знанием предметной области. Если ваша стратегия – набирать джунов на поток и давать им сценарии, то эта методология не подойдет.

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

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

Что ещё почитать по теме?

• James Bach, Heuristic Test Strategy Model – SFDIPOT и эвристики Rapid Software Testing. Michael Bolton, FEW HICCUPPS – оракулы с разбором каждого.
• Jonathan Bach, Session-Based Test Management (2000) — сессии, чартеры, метрики T/B/S. Matt Wynne, Introducing Example Mapping.
• ISO/IEC 25010:2023 – модель качества продукта, в редакции 2023 года девять характеристик; годится как чек-лист забытых аспектов.

]]> https://quality-lab.ru/blog/testirovanie-bez-trebovanij-kak-navesti-poryadok-v-qa-za-90-dnej/ Tue, 13 Oct 2026 17:36:59 +0300 Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

В пространстве Rapid Software Testing критическое мышление — это мышление о мышлении с целью не быть обманутыми. У нас есть простая мнемоника, которая запускает критическое мышление: WHeReAS. Задавайте вопросы: Кто? А? Правда? И что? И что с того?

Долгое время в нашем списке вопросов были только последние четыре пункта. Оценка наблюдения или утверждения зависит от того, убедились ли мы, что поняли утверждение или идею, которую рассматриваем. Это «А?». «Правда?» — о достоверности утверждений. «И что?» побуждает подумать о том, что могло быть упущено. А «И что с того?» — о последствиях и о том, стоит ли предпринимать какие-то действия.

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

]]> https://www.software-testing.ru/library/around-testing/job/4509-experts Mon, 12 Oct 2026 23:00:00 +0300 Часть 1 — Про древнегреков

Итак, на стыке 17-го и 18-го века время было очень неприятное, Европа была истощена постоянными войнами «всех со всеми», продолжающимися локальными чумными эпидемиями, которые в те времена никто не мог лечить, знать жила в долгах, бедняки в обносках, монахи во грехе чревоугодия.

Он был готов дидактировать напропалую

Внезапно в 1699-м году французский писатель Франсуа Фенелон создал на основе уже подзабытых древних текстов Гомера новый, продвинутый (проапгрейженный же!) литературный образ Ментора, который всячески воспитывает сына своего друга в наилучших традициях благородного, книжного рыцарства в сеттинге приключений в «прекрасной античности прошлого». Он не просто вещает дидактическую идеологию, а ещё и всячески довлеет своим поведением — то берёт меч и встаёт во главе чужой армии, то попадает в рабство и благородно не убегает, выполняя волю своего новоявленного хозяина, то ещё что-то.

Не все знают, что к 12-му веку рыцарство оформилось в отдельную социальную группу, а к 14-му веку над ними уже смеялись все собаки, потому что придуманные «рыцарские правила» не стыковались ни с их образом, ни с их поведением (вооруженные гопники), ни с окружающей всех нас реальностью. На исходе 17-го века рыцари рыцари как самостоятельная военная сила практически исчезают, потому что артиллерия, регулярные армии, увядание феодальной экономики.

Но мы и сегодня знаем о том, что «ради прекрасной дамы рыцарь должен…»

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

Проблема в том, что это всё — полная ерунда, которая воображается через набор устойчивых иллюзий, мол:

• ментор — это опытный наставник, который уже «…достиг успеха и может им поделиться», он знает путь к успешному успеху, он подскажет куда идти, он научит, он в беде не бросит,
• и он даст тебе преимущество в конкуренции за блага всего сего мира,
• и с ним не придётся познавать всё на своей шкуре, ведь ментор будет советовать «…вот из этой книги прочитай семь страниц, всё остальное не читай, оно лишнее…» — а это преимущество в конкуренции всех со всеми,
• и это не опостылевший учитель, и не репетитор по отдельным предметам, и не назойливый коуч (coach, тренер), и не дорогостоящий консультант (знает рабочий алгоритм решения объявленной проблемы), он всего лишь даёт советы и рекомендации, а советы советовать — не мешки таскать,
• и поэтому платить за менторство не нужно. Или нужно, но немного, да и только если он «доведёт до трудоустройства».

Кагбэ да, но нет.

Менторов книжного образца не существует. Увы. И даже не каждый отец справляется с такой ролью.

Ментор не может просто «мудро» посоветовать джуну какой-нибудь верный путь к успеху — нет такого пути. Советы есть, пути — нет.

Никто не может посоветовать что-то умное и сразу отойти, чтобы не мешать. Люди не браузеры и не AI, которые можно вызывать при необходимости и отключать за ненадобностью.

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

— Я боюсь, что не найду работу.
— Не бойся. Продолжай искать.

— У меня не получается освоить программирование…
— Начни с основ. Сделай что-нибудь, чтобы получилось.

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

Это не совсем просьбы просто что-то посоветовать. Это запросы на разбор проблемы, и в поисках решения на раз-два выясняется, что в тёмной глубине разума ой мама родная какие демоны могут прятаться и какие причины могут выясниться… А играть в психоаналитика принципиально нельзя, харам, табу, гунда!

«Не советую, гражданин… мнэ-э… не советую. Съедят».

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

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

Или отстранённо покивать и посоветовать не унывать и что-то прочитать про тест-дизайн… но что именно? Гомера Канера?! Многие уже не читают книги, а предпочитают короткие, минутные видео, но такие видео всего лишь дадут ощущение «а, понятно». Да и если читать книги, то надо проверять, что было прочитано и как оно было понято.

«На этой неделе я прочитала всего Канера. Что именно — ну, вот это я пропустила, потому что уже знаю. Это тоже знаю. Это мне не нужно. Это тоже непонятно что. А вот эти три главы прочитала, но там ничего не понятно, зачем вообще такие книги нужны?!»

Ой, как вспомню…

По каким-то темам я уже не знаю, какие книги можно рекомендовать. Какие-то вещи в теории тестирования мне проще самому объяснять, потому что это концепции, абстрактные, их нет в нашем быту, и я реально не знаю, какие книги про них рассказывают так, чтобы было понятно. Какие-то концепции уже я сам сформулировал, их просто нет в книгах. А это всё уже роль учителя, добро пожаловать за парту, советовать тут нечего, тут учить надо, даже если это всё очень нудно.

Далее. Если составить джуну план действий или milestones, которые ему надо пройти, то этот путь надо отслеживать, отсюда — роль куратора, тьютора, супервизора, научного руководителя, но никак не ментора, который мудро советует нужное и мудро не советует ненужное.

А ещё какие-то аспекты поведения джуна надо корректировать через подсказки, указания и запреты — это роль тренера.

Например, кто бы знал, что современные тестировщики боятся заходить в настройки операционной системы…

А надо!

Решение каких-то технических проблем на стороне воспитанника возможна только после детального погружения в контекст, а это — роль технического консультанта, и не каждый «ментор» захочет это делать в принципе, даже за деньги. Восторженный джун очень быстро переходит от «Я не знаю, как продвинуться по карьере…» к «Помоги мне автоматизировать получение логов из Kibana, там ещё Elasticsearch надо настроить, ну ты же умеешь…», а ментор смотрит на это всё и пытается понять, в какой момент мы перешли от обсуждения карьеры к настройке твоего рабочего окружения…

И после этого всего есть ещё совершенно неочевидные аспекты в менторстве — ментор не обязательно должен разбираться в твоей теме. Неожиданно, да?!

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

Ментор — необязательно премудрый старец. Иногда джун джуну лучший ментор, и там вообще нет параметра «…уже достиг успеха и может им поделиться». Один чёрт придётся всё познавать на своей шкуре. Иногда просто объяснить взрослому менеджеру проектов, почему невозможно раз и навсегда автоматизировать тестирование на условном проекте и таким образом уменьшить расходы по этой статье — тоже менторинг, и внезапно — от младшего к старшему. Седовласая борода вообще нигде не показатель.

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

А ещё менторы иногда назначаются насильно, и это иногда очень эффективно, а иногда абсолютно лишний головняк…

А ещё каждому ментору, даже если он уже, ээ, старец, тоже периодически нужен наставник.

А ещё платить за менторство обязательно надо, но не деньгами, а отношением, потому что так устроено социальное взаимодействие.

Далее рассмотрим, чем конкретно ментор отличается от учителя. Это важно понимать, а не просто знать.

]]> https://testitquickly.com/2026/10/12/bate-capul-de-perete-asistat-profesional/ Mon, 12 Oct 2026 00:54:37 +0300

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

Сегодня рассмотрим практические инструменты. Давайте честно, все бы мы хотели конкретики, но проекты без ТЗ – привычная ситуация на рынке. Тестировать в таких условиях вполне реально: нужно только выстроить системный подход и не терять в качестве.

В статье мы делимся практиками, которые помогают справляться с самыми острыми проблемами. Рассказываем, как оперативно фиксировать требования, отслеживать прогресс без громоздкой документации и уберечь команду от лишних переделок. Покажем, как применять Example Mapping для быстрой фиксации правил, использовать сессии вместо устаревающих тест‑кейсов, выстраивать приемку в три контура и вести журнал решений (который будет играть роль памяти проекта). Даем понятные алгоритмы, которые можно сразу применять на практике.

План–перехват требований

Требования не прописаны, а решения каждый день принимают десятками. До тестировщика они просто не доходят в виде понятного текста. Нужны способы вовремя их перехватывать и фиксировать. Ловите эффективные техники.

Example Mapping: как за 25 минут вытащить скрытые правила и вопросы

Example Mapping – простая и очень полезная техника: всего 25 минут работы, четыре цвета карточек – и сразу видно, чего не хватает в задаче. Это метод Мэтта Уинна из команды Cucumber. Мы в компании его активно используем: четверть часа на старте здорово экономит время потом.

Собираем троих – продакта, разработчика и тестировщика (их еще называют «три амиго») – и раскладываем задачу по карточкам. 

Все наглядно:

• Желтая карточка – это сама задача. Она всего одна на встречу: коротко и по делу.
• Синяя – правило работы функции. Например: «скидка не суммируется с промокодом». Обычно таких правил получается 3–7 штук, и нередко половину из них до этой встречи вообще никто вслух не формулировал.
• Зеленая – конкретный пример с цифрами. Например: «корзина 5000 ₽, промокод SALE20, статус „серебро“, итог 4000 ₽». Такой пример сразу становится готовым сценарием для теста.
• Красная – вопрос, на который прямо сейчас никто в комнате не знает ответа.

Особенно важны красные карточки. Если их больше трех – значит, задачу рано отдавать в разработку. Это видно сразу: карточки лежат перед глазами, спорить тут сложно. Такой подход помогает договориться еще до начала работ – даже там, где про формальные критерии готовности задачи не слышали.

По нашим данным, на типичную задачу выходит 4–6 правил, 8–12 примеров и 2–4 вопроса. И примерно каждый третий из этих вопросов – как раз тот, который иначе всплыл бы уже на демонстрации и обернулся бы серьезной переделкой.

Из практики: была задача по логистике – пересчитывать стоимость доставки при изменении состава заказа. Казалось, хватит 2 дней. Но на сессии Example Mapping всего за 20 минут выявили 7 непроясненных моментов: заказ уже собран на складе, новая цена ниже предоплаченной, сменился тарифный пояс, клиент – юрлицо с постоплатой. В итоге оценку скорректировали до 9 дней. Это помогло не сорвать сроки: нужное время сразу заложили в план, а не столкнулись с нехваткой времени в конце спринта.

Выявление и проработка неоднозначностей с помощью слов–детекторов

Практику проверки на неоднозначность описала Элизабет Хендриксон в книге «Explore It!». В описании задачи часто прячутся непринятые решения – их можно заметить по определенным словам. Мы держим список таких слов на виду и быстро проверяем каждую задачу перед стартом – хватает 30 секунд. И вам советуем.

Слова-детекторы: что переспросить прежде, чем начинать

Формулировка в задаче	Что за ней прячется	Вопрос, который вы задаёте
«Корректно обрабатывать»	Никто не решил, что считать корректным	Два примера: корректный и некорректный. Что видит пользователь во втором случае?
«Быстро», «без задержек»	Нет числа, а значит, нет критерия приёмки	Сколько секунд приемлемо, а сколько уже жалоба? При какой нагрузке?
«Все пользователи»	Забыли про роли, права, неавторизованных, ботов	Администратор тоже? А заблокированный? А по прямой ссылке без входа?
«Просто добавить поле»	Слово «просто» почти всегда маркер невидимых связей	Куда это поле попадёт дальше: в отчёты, выгрузки, поиск, историю, интеграции?
«Пока без этого»	Отложенное решение, которое забудут	Что произойдёт, если пользователь всё-таки это сделает? Запрещаем или падаем?

Правило 15 минут! 

Если не понял требование – не гадай. Дай себе 15 минут, чтобы разобраться самому. Если ответа нет – сразу иди спрашивать. Звучит банально, но правило постоянно нарушают. Тестировщику бывает неловко задавать вопросы, и он строит свою гипотезу. Потом заводит по ней баг, а разработчик закрывает его как by design. В итоге обе стороны теряют по полдня. Неловкость уходит, если правило закреплено официально: у нас оно прямо прописано в договоренностях.

Сессии как единицы работы вместо тест‑кейсов

Тест‑кейс плохо справляется с изменениями: он фиксирует конкретные шаги для конкретного поведения системы. Стоит поведению поменяться – и кейс становится бесполезным. В проектах, где продукт обновляется каждую неделю, на поддержку тест‑кейсов уходит больше времени, чем на само тестирование. Знакомая ситуация: есть 180 кейсов, из них реально работают примерно 70, но никто точно не знает, какие именно.

Альтернативу предложил Джонатан Бах еще в 2000 году – это Session‑Based Test Management. Здесь основная единица работы – сессия: отрезок времени с четкой целью и отчетом по итогам.

Анатомия сессии: 90 минут, которые можно предъявить

Тайм-бокс не про дисциплину, а про то, чтобы работу можно было планировать и оценивать

Чартер

5 мин

Подготовка

15 мин · данные, доступы

Исследование по цели

55 мин · сюда же уходят находки не по теме

Оформление

15 мин · баги

Разбор

5 мин

0

20 мин

75 мин

90 мин

Что попадает в отчёт

— что исследовали и чем

— что нашли

— что осталось непроверенным

— какие вопросы открылись

Разбивка времени

Тест / Баг / Подготовка

Норма: 60 / 25 / 15

Подготовка выше 30% — чините стенды, а не людей

По теме / не по теме

Доля времени вне цели сессии.

Стабильно выше 40% — значит, чартеры сформулированы плохо

либо продукт горит целиком

Краткость чартера – залог эффективности

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

# Плохие чартеры (так делали мы первые полгода)
Протестировать корзину                    ← это не цель, это область
Проверить, что всё работает               ← непроверяемо
Регресс личного кабинета                  ← на 8 часов? на 3 дня?

# Рабочие чартеры
Исследовать пересчёт корзины при изменении из двух вкладок сразу,
  чтобы найти рассинхрон итоговой суммы и состава

Исследовать оформление заказа при медленном ответе шлюза
  (задержка 3–10 с), чтобы найти двойные списания

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

Берутся чартеры из реестра рисков: каждый риск верхних квадрантов превращается в один-два. Цепочка получается прозрачная и объяснимая заказчику: риск → чартер → сессия → отчёт → строка в протоколе приёмки. При этом кейсы никуда не деваются — здоровая пропорция на проекте без ТЗ примерно такая: 15–25% работы в жёстких проверках критичных потоков, остальное сессии.

Чартеры берут из реестра рисков: каждый значимый риск превращается в один‑два чартера. Цепочка получается понятной и прозрачной для заказчика: от риска – к чартеру, от чартера – к сессии, потом – к отчету и строке в протоколе приемки.

При этом тест‑кейсы остаются в работе. На проекте без ТЗ разумно держать такую пропорцию: 15–25% усилий – на жесткие проверки самых критичных потоков, остальное – на исследовательские сессии.

Когда все‑таки нужны тест‑кейсы (критерии выбора)

Принцип, который способен здорово упорядочить работу: артефакт должен жить не дольше, чем то, что он описывает. Если функцию переделывают каждые две недели, подробный тест‑кейс на нее – просто потраченные время и деньги. А вот модуль расчета НДС не меняется годами – пока не поменяется налоговый кодекс. Тут можно смело писать автотест и не переживать.

Поэтому советуем сортировать задачи по сроку годности: что быстро устаревает – тестируем гибко, что стабильно – автоматизируем.

Иерархия артефактов: что писать в зависимости от скорости изменений

Артефакт	Поддержка	Когда оправдан	Когда вреден
Карта продукта	низкая	Всегда. Первое, что делаете на проекте, и последнее, от чего откажетесь	Не бывает. Разве что вы описали в ней поведение вместо состава
Реестр рисков	низкая	Всегда. Обновляется раз в релиз за час	Когда разрастается до сорока пунктов и перестаёт читаться
Чартеры сессий	низкая	Всё, что меняется чаще раза в месяц. Основной рабочий инструмент	Когда нужна воспроизводимость шаг-в-шаг для аудитора
Тест-кейсы	высокая	Деньги, права доступа, юридически значимые операции, сложные расчёты	На всё подряд. Особенно на UI новой фичи в первые два месяца жизни
Автотесты API	средняя	Контракты между сервисами: меняются раз в пять реже интерфейса	Пока API проектируется и меняется по три раза в неделю
Автотесты UI	высокая	Два-три ключевых сквозных сценария, не больше	Как основная стратегия на меняющемся продукте — самая дорогая ошибка из списка
Характеризующие тесты	низкая	Легаси без документации: фиксируем как есть, ловим незаметные изменения	Когда систему как раз собираются переписывать по-новому

Отдельно про легаси: характеризующие тесты

Когда кажется, что «знание утеряно», помогает прием Майкла Физерса из книги «Эффективная работа с унаследованным кодом». Смысл в том, чтобы зафиксировать, как система работает в моменте, – так проще будет заметить, если поведение незаметно изменится в будущем.

Берем тысячу обезличенных запросов с продакшена, прогоняем через текущую версию и сохраняем ответы как эталон. Потом с каждой правкой кода снова прогоняем ту же тысячу. Если есть расхождение – значит, либо баг, либо осознанная правка. В любом случае вы узнаете об этом до релиза, а не от клиента. Это подход из семейства approval testing.

Для интеграций есть похожий вариант – контрактное тестирование. Если сервисов много, а описания их взаимодействия нет, контракты собирают из реального трафика – и дальше они работают как техзадание на стыках. Так мы в своей практике восстанавливали правила взаимодействия там, где все описание хранилось в одном чате разработчиков – еще с 2021 года.

Из практики.

Работали с системой расчета комиссий. Представьте восемь лет разработки, три поколения авторов, а документации нет совсем. Задача стояла простая: добавить новый тип комиссии и ничего не сломать. При этом в компании никто не мог даже перечислить существующие типы. Взяли выгрузку за квартал – 240 000 расчетов, – прогнали через текущую версию и сохранили как эталон. При первой же правке всплыло расхождение в 1,8% случаев: оказалось, пересекались старая акция и округление вниз. Ошибка жила в проде четыре года и стоила 3,2 млн рублей недоплаченных комиссий. Нашли ее не люди, а простое сравнение системы с самой собой.

Приемка в три контура

Дошли до главного: все, о чем говорили раньше, нужно, чтобы приемка перестала быть сюрпризом (и чаще всего неприятным). Обычно бывает так: в конце спринта показывают результат, а заказчик говорит, что ожидал другого результата. Начинается непростой разговор. Виноватых нет – просто ожидания нигде не зафиксировали. Через две недели ситуация повторяется.

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

Три контура приёмки: чем раньше поймали, тем дешевле

Контур 1 · На входе

Частота: каждая задача

Занимает: 20–30 минут

Example Mapping на задачу

Прогон по словам-детекторам

Три вопроса готовности

Что ловим:

непринятые решения, противоречия, забытые роли

Цена исправления: 1×

Контур 2 · По ходу

Частота: каждые 2–3 дня

Занимает: 15 минут

Показ куска на живом стенде

Заказчик кликает сам

Решения — сразу в журнал

Что ловим:

расхождение картинки в голове заказчика и того, что вышло

Цена исправления: 5–10×

Контур 3 · На выходе

Частота: релиз

Занимает: 2–4 часа

Протокол приёмки

Закрытие рисков из реестра

Явный список непроверенного

Что ловим:

системные эффекты, регресс, то, что вылезло на стыках

Цена исправления: 30–100×

Если контуры 1 и 2 не работают, весь груз падает на третий — тот, где исправление стоит дороже всего.

Ощущается это как «тестировщики опять всё завернули перед релизом». Причина не в тестировщиках.

Что проверить до начала работ?

На меняющихся проектах полноценный Definition of Ready часто не работает: он либо превращается в формальность, либо тормозит работу. Мы упростили подход и оставили всего три вопроса, на которых нужно ответить до старта. Если ответов нет – не берем задачу в работу.

## Три вопроса готовности задачи

1. Зачем. Что изменится для пользователя или бизнеса, когда это заработает?
   Одно предложение. Не «сделать форму», а «клиент оплатит без звонка менеджеру».

2. Как поймём, что получилось. Один пример с конкретными данными,
   где видно, что задача решена.
   Не критерии приёмки. Один пример. С цифрами.

3. Что точно не входит. Какие смежные случаи мы сознательно
   не делаем в этой задаче?
   Самый недооценённый вопрос: снимает половину споров на приёмке.

Работает и в чате. Прилетело «сделайте фильтр по дате» — отвечаете тремя вопросами. В 80% случаев ответы приходят и они полезны. В остальных выясняется, что задачу никто не продумывал — тоже результат.

Протокол приемки, который способен поменять все

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

ПРОТОКОЛ ПРИЁМКИ · Релиз 2.14 · 12.03

1. ЧТО ПРОВЕРЕНО
   Оформление заказа с оплатой картой ... 4 сессии, 6 ч
   Пересчёт корзины ..................... 2 сессии, 3 ч
   Регрессионный чек-лист ............... 62 пункта, пройден

2. РИСКИ ИЗ РЕЕСТРА
   Закрыто проверками ... 6 из 10   Передано в мониторинг ... 2
   Принято бизнесом без проверки ... 2  (см. п. 4)

3. ЧТО НЕ ПРОВЕРЯЛОСЬ  ← раздел, ради которого всё затевалось
   Мобильные браузеры старше двух лет — нет устройств на стенде
   Импорт файлов свыше 50 МБ — нет тестовых данных нужного объёма
   Больше 200 одновременных пользователей — нет нагрузочного стенда
   Отмена после частичной отгрузки — не успели, риск средний

4. ПРИНЯТЫЕ РИСКИ       ← подписывает бизнес, не QA
   Вёрстка в браузерах старше двух лет (0,4% аудитории)  — принял: П. (продукт)
   Отчёт «Остатки» грузится 40 с на крупных клиентах     — принял: П. (продукт)

5. РЕКОМЕНДАЦИЯ
   Выпускать на 10% трафика, флаг new_checkout, наблюдение 24 ч.

Пункты 3 и 4 отличают этот документ от отчёта о тестировании. Один раз показав такой протокол заказчику, вы навсегда меняете характер разговора о качестве.

Что это даёт менеджеру

Решение о релизе больше не зависит от эмоций. Не будет фраз вроде «вроде все нормально» – вместо этого есть четкая картина: вот что проверили, вот что проверить не успели, какие риски осознанно приняли и кто это подтвердил. Если потом что‑то сломается, у вас будет документ, который показывает: решение принимали, зная про все слабые места. А тестировщику такая прозрачность помогает защититься от упреков «почему не нашли»: все, что было известно, уже зафиксировано.

Журнал решений: как не терять контекст в условиях постоянных изменений

Отдельная беда проектов без ТЗ – всеобщая амнезия. Договорились на созвоне, все кивнули, через месяц никто не помнит. Хуже – помнят по–разному, причем каждый искренне.

Лечится журналом решений. Идея заимствована у разработчиков, у них это Architecture Decision Records; то же самое, только про продуктовые договоренности. Формат – пять строк, больше никто вести не будет. Наш первый шаблон имел пятнадцать полей, и поэтому прожил всего три недели.

#47 · 14.02 · Промокод и статус лояльности

Вопрос:    Суммируются ли скидка по промокоду и скидка за статус?
Решение:   Не суммируются, применяется большая из двух.
Принял:    Марина (владелец продукта), созвон 14.02
Причина:   Суммарная скидка выше 25% уводит заказ в минус
Следствие: Чартер C-12 переписан, обновлены 4 автотеста корзины,
           на баннере акции нужна сноска — задача PROD-882.

Строка «следствие» превращает журнал из архива в рабочий инструмент: сразу видно, что в тестах надо трогать.

в ленте блогов.

Содержание рассылки доступно по ссылке.

Подписаться на рассылку

]]> https://www.software-testing.ru/news/4567-mail-october Thu, 08 Oct 2026 12:04:57 +0300 Автор: Макарий Петров

Работая в Сбере, я столкнулся с тем, что общепринятым инструментом для функционального тестирования в моем трайбе был JMeter. Нравится ли мне это? Вопрос второстепенный. Приходилось работать с тем, что есть. По мере того как разрастались наши компоненты и их функциональность - разрастались и JMeter-тесты. Если кто не сталкивался - вся логика JMeter-тестов описана в файле с расширением .jmx. По сути это XML-файл, содержащий в себе всю логику тестов: вызовы endpoints, проверки JSON и прочая логика. И если подойти к этому вопросу без знания, то можно столкнуться с такой же проблемой, как у нас: файл разросся до 50 000+ строк и вносить/ревьюить/поддерживать его стало крайне сложно. Я нашёл способ уменьшить размер файла в 10 раз. Давайте же вместе распилим этот монолит)

]]> https://www.software-testing.ru/library/testing/performance-testing/4563-jmx Tue, 06 Oct 2026 23:00:00 +0300 Курс Автоматизация тестов для REST API при помощи Postman полностью перезаписан — обновлены все лекции, скорректированы домашние задания, добавлена новая тема автоматизации с помощью ИИ.

Этот курс поможет начать автоматизировать API-тесты, если вы этим ранее не занимались. Он проведет от простого к сложному, чтобы уложить знания в голове.

Несмотря на то, что ИИ поможет вам непосредственно в написании кода тестов, базовые знания «как писать такие автотесты» всё равно необходимы, они помогут:

• правильно сформулировать задачу для автоматизации;
• проверить, что именно ИИ написал (а он может сделать неправильно, но, чтобы это понять, нужна база, которую дает курс)

Подробнее об обновлениях можно прочитать в блоге Ольги Назиной.

]]> https://www.software-testing.ru/news/4565-postman Mon, 05 Oct 2026 15:48:20 +0300 Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Мы с Джеймсом Бахом разработали предварительный набор эвристик-ориентиров для «синдромов» нежелательного поведения больших языковых моделей — устойчивых паттернов проблем, которые мы наблюдали и за которыми теперь можно системно следить.

Это не взаимоисключающие категории; они могут пересекаться или взаимодействовать друг с другом.

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

]]> https://www.software-testing.ru/library/testing/general-testing/4510-large-language-model-syndromes Sun, 04 Oct 2026 23:00:00 +0300 Жизнь продолжается. Мы умираем от невозможности принять всю ту бубуйню, що тут и там коїться, а новые тестировщики постоянно откуда-то рождаются и ходят по кругу с удивительно одинаковым вопросом:

Где найти ментора?

Ответов сразу несколько:

1) (правильный) Подходишь к живому тестировщику, устанавливаешь с ним социальную связь и спрашиваешь о работе — делаю то и это, должно получаться так, а не получается. Можешь помочь, подсказать, объяснить? Повторять в цикле с разными живыми тестировщиками.

2) (социально-одобряемый) Идёшь в Moldova QA Community, выпаливаешь самого адекватного, устанавливаешь с ним социальную связь и спрашиваешь о работе (см. выше).

3) (псевдо-адекватный) Идёшь в любое коммьюнити тестировщиков и спрашиваешь, где тут бесплатно раздают бесплатных менторов.

Коммьюнити с менторами у нас аж два:

• Moldova QA Community

На первый взгляд это тихо-мирно существующий tg-канал, преисполненный патриархальной тишины всех провинциальных городов. Но внутри — движуха, беготня, надежды, вылазки на природу и подкоммьюнити, в котором периодически рассматриваются заявки на менторство для тестировщиков. Участие в нём добровольное, с кем посчитаю интересным поговорить — с тем и свяжусь, дальше посмотрим. Ну или не я, а кто-то ещё, чего вы ко мне привязались-то?!

• TechWomen Moldova

Глобальное коммьюнити про IT в Молдове. Это отдельная экосистема, в которой раз в год организовывают масштабную программу менторинга по разным направлениям, в том числе и для QA. Тоже абсолютно добровольное участие для всех сторон, но уже с вайбом большого проекта с семью директорами с восемью печатями — есть центральное управление, условия участия, сбор фидбэка с оценками, торжественно-парадная ритуальная церемония открытия и закрытия программы. В этом году я к этой программе подконнектился по линии QA на русском языке (на родном мне про тестирование говорить сложновато).

Торжественно-парадная фото-пикча автора на фоне автора же, подвисшего на карусельках на Ботанике, с церемонии открытия программы менторинга 2026-го в TechWomenMoldova

Программа “2026” уже завершилась, но всё ещё есть о чём подумать, например о том, что менторы будут существовать даже в нашем будущем, которое мне представляется как сплошной сериал Star Trek в бандитско-неустроенной вселенной Star Wars, где отважные старшип-капитаны и их грамотные намбер-уаны на протяжении всех серий преисполнены дипломатии и сочувствия ко всем живым тестировщикам существам. Короче, всем смотреть. Вон как красиво там раскрывается тема менторинга джунов (Shut up Wesley! ©)!

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

Важный дисклэймер в эти дурацкие времена: весь текст написан вручную с применением типографики, которую я разумею как правильную (в KDE она включается на раз-два и очень удобно используется), с длинными тире и французскими кавычками-ёлочками. Текста много, потому что я его писал не в один присест — в прекрасном десктопном вики-редакторе Zim (см. скриншот оригинала), по своему усмотрению усмиряя пухнущие и расползающиеся абзацы. А из-за того, что в наборе таки были орфо или даже стилевые ошибки, мне приходится по мере их выявления там и сям обновлять уже опубликованный текст. Понять и пrостить.

Кто такой «ментор»

Начнём ооочень издалека, чтобы прояснить лор* и бэкграунд** нашей темы.

* Лор (от англ. lore) — история, устройство и внутренние правила вымышленного, как правило, игрового мира. Он объясняет персонажей и предисторию событий, в которые игрок начнёт погружаться, иногда поверхностно, иногда очень детально, от происхождения сторон до скрытых связей и событий, которые могут быть неочевидными, но важными.

** Бэкграунд — background же!

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

Про названия

Не все знают, что называть греков греками некорректно. Они изначально не были единым народом, это был народный сборник племён и народов, разбросанный по островам, и все называли себя кто во что горазд — данайцы (иногда данаи), аригвяне, ионийцы, дорийцы, эолийцы, грайки, локры, ахейцы…

Некоторое время греки жили даже на территории современного Севастополя в городе с изысканным названием Херсонес Таврический (не путать с более современным украинским Херсоном), но местные их называли то херсонесцами, то херценосцами, и греки ушли оттуда ещё во времена поздней античности в IV–V веках нашей эры.

В русской литературе древнегреков издревле привыкли называть ахейцами. Например:

…Куда плывете вы? Когда бы не Елена,
Что Троя вам одна, ахейские мужи?

Или

Смотрите —
Лечу, словно в сказке,
[…]
И в край незапамятный тот,
Где снова ахейские старцы
Ладьи снаряжают в поход.

Чужое и глупое горе
Велит им на Трою грести.
А мне — за Эгейское море,
А мне еще дальше расти!

А ещё в древности в принципе не было единого греческого национального государства. Было слово Хелла́с (Ἑλλάς) — обозначение греческого мира вообще, которое со временем превратилось в Элла́с. Местные называли себя, соответственно, э́ллины (ударение смещено на «э» по правилам их языка) с уточнениями, мол, здравствуйте, я эллин-ахеец, кофе будете? А я эллин-данаец, здравствуйте-калимерствуйте, кофе мы ещё не изобрели, поэтому налейте мне вина! А, точно, и овечьей брынзы возьмите… Овечьей, из овечьего молока, иногда с добавлением козьего, то есть, фета? Да, фета… А виноград будет? А по наглой морде? А священная ксени́я? Ах, да…

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

Позже они переназвали свою страну Элла́да согласно уточнённым нормам своего осовремененного языка. Слова «грек» и «Греция» они и сегодня не признают и употребляют только в общении с глупыми иностранцами, деньгиприносящими.

«Илиада»

Можно подумать, что это искаженное «Эллада», но нет.

Много веков назад на побережье Эгейского моря на полуострове Троада (сегодня он называется Бига и принадлежит Турции) некий Ил, сын некоего Троса, основал новый город. Город он назвал имени самого себя, конечно же — И́лион (в оригинале Ἴλιον, звучит ближе к Ийон), а местность назвал по имени своего незабываемого папы Троса — Тро́я.

Столицу полуострова Троада древние греки называли то как полагается, Илион, то упрощённо Троя, потому что на Троаде же, и в те времена города иногда были одновременно и государствами, и когда один говорил «Троя», миллионы понимали, что имеется ввиду город-государство Илион с полуострова Троада.

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

Ну и да, термин «лаконичность» — манера говорит немногословно — происходит от манеры древних жителей Лаконии говорить кратко и по делу.

И как-то случилась в этом тройском царстве-NOT-государстве занятная история. Летним тёплым вечерком XII-го века до н. э. некий Парис, сын Приама, тогдашнего царя Трои, припёрся в гости к Менелаю, царю Спарты. Да-да-да, та самая THIS IS SPARTAAAA!

Менелаич принял царевича Трои радушно, по-человечески, или как говорили греки, «cu un paharel de jin și mămăliguță proaspătă», но тут юный мистер Пэрис Приамович увидел менелаеву жену с редким именем Елена… Увидел да не развидел, потому что там было на что посмотреть, в наше время она считалась бы победительницей конкурса «мисс tech Вселенная», всем встать, тётя-бомбуэ! Ну и захотел он Елене, эээ, подарить всего себя.

Елена, конечно, пошла в отказ, мол, женатая же я, не надо мне таких подарочков, но богиня Афродита мимо пробегала и насильно влюбила Елену в Париса. Елена разумом всё понимает, но внутренней Афродите не перечит и решительно прихватив заметную часть сокровища мужа (воровство в большом масштабе, да) а также двух молчаливых рабынь, чтобы сундуки тащили, сваливает с Парисом в Трою. Дома остались разгром, её девятилетняя дочь Гермиона и сын Никострат (с неопределенным количество лет; возможно, он даже ещё и не родился к тому моменту). Ну не таскать же детей за море в компании «нового папы»…

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

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

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

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

Боги эти были не только бессмертными и мудрыми, но и очень стервозными мудаками, потому что были они беспредельно всемогущи и развращены бесконечной властью. Они могли принять облик любого, буквально любого древнего грека и действовать от его имени. Или могли одарить человека чем-то вроде мудрости или богатства. Или превратить в лягушку.

Например, один славный древнегрек Актео́н увидел, как плещется в проточной воде Артемида, вечно юная богиня Луны, охоты и женского целомудрия, по совместительству покровительница всего живого на Земле, дающая счастье в браке и помощь при родах, а также сестра Аполлона, который был олицетворением Солнца. Артемида обозлилась на глазастого Актеона и нет, не выцарапала ему глаза, а превратила его в оленя. И кто же знал, что у Актеона есть аж 92 собаки, которые не унюхали своего хозяина за «оленьими» глазами, обгавкали его разными обидными древнегреческими словами и разорвали его на 92 клочка. Не становитесь оленями, мужики!

А ещё боги могли кого угодно просто взять и оплодотворить, отчего бедные греки то и дело рожали полубогов, которые наследовали от своих разнузданных предков только часть божественных возможностей (ну, типа как герои комиксов Marvel), но и от этого им тоже знатно срывало башню и они начинали жить да озорничать в меру своих ополовиненных боговских возможностей.

Наконец, отсидевшие десять лет под стенами Илиона греки протрезвели, поговорили с богами, трезво оценили тактическо-стратегическую обстановку, прекратили неэффективную драчку у неприступных ворот и сделали эффектный ход в Трою деревянным конём. На боку коня, чтобы троянцы не заподозрили троянского коня, было написано: «Этот дар приносят Афине Воительнице уходящие данайцы*», а то, что внутри спрятались хитрые греческие воины — не написали. Троянцы написанное на заборе прочитали, прочитанному нотариально поверили, затащили эту деревянную ерунду в город всё разверте…

* Помним, что данайцы — одно из греческих племён, которых, как мы знаем, нельзя называть греками. Но древние римляне называли всех греков обобщающе «данайцы», отсюда и стихотворное «Timeo Danaos et dona ferentes».

Так вот, коня затащили в Трою, в коне сидели хитрые древние греки (Менелай, Одиссей, Диомед и др), которые ночью выползли из коня с мечами наголо ну и end of story, всем секир-башка, усталые, но довольные греки вернулись домой с богатой добычей, а усталые и недовольные жители Трои медленно умирали на развалинах империи от злости на свою же глупость. Руины Трои хорошенько поросли травой забвения и были обнаружены только в конце 1860-х годов настырным археологом Генрихом Шлиманом (тот ещё шлемазл!).

А ведь всё могло бы быть иначе. Греческие ахейцы могли бы и не рваться в Трою, мол, Менелаич, ну сбежала твоя жинка — та найди себе новую, ты же царь Спарты, ёпта. Да и нужна тебе новая жена? Было бы у нас столько рабынь, сколько у тебя, мы, может, и не женились бы…

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

Или сами тройцы могли бы прикинуть кое-чего к носу, собрать армию и приплыть из своего Иллинойса проведать самих древнегреков сразу с Парисом и мечами наголо… Кагбэ, ой.

Со временем все герои всей истории последовательно умерли: кто-то от старости, кто-то случайно, того же Ахиллеса застрелили (стрелами), Парис был выпилен очень ядовитой древнегреческой стрелой в ходе рутинных военных действий при осаде города-государства, а Елена Прекрасная — кхм…

А Елена Прекрасная после смерти Париса быстро переоформила документы и стала женой другого царевича, парисового брата Деифоба. А когда Троя пала, Менелай внутрь города зашёл, этого Деифоба нашёл и зарезал, после чего мрачно поехал домой с «любимой» женой. В пути их помотало так круто, что домой они доплыли только через восемь лет, после чего Менелай чинно пожил да и помер, раздав свою душу многочисленным олимпийским богам.

Тут же всё ещё прекрасная, но уже вдова Елена была выпнута из дворца и вообще из Спарты своим же сыном Никостратом «за неподобающее поведение лица, облечённого высшей административной властью» (ах вы хочете беспоследственно воровать мужнины драгоценности и ездить по заграничным троянским курортам!?; так что ехайте вы, мамаша, куды завгодно).

Ну и бедная вдова послала сообщение на ближайший остров Родос к своей подруге-королевне Поликсо, мол, давай я приеду, посидим-поболтаем, как две равные царствующие вдовушки, я о Трое расскажу, фотки фресок покажу.

SMS на весь экран: «Приезжай )))))!!!11!!!11!…»

Елена приехала, но не учла, что подруга-Поликсо стала вдовой потому, что муж ейный (Тлеполем) был убит под стенами той самой Трои, и безутешная вдова НЕ забыла, из-за кого вся эта илионско-троянская история началась. Пока прекрасная гостья принимала душ после долгой дороги, хозяйка Родоса велела своим служанкам достать «нашу прекрасную гостью» из ванной и as is, с голой Жэ, повесить на любом дереве. Было исполнено.

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

Война закончилась, все переключились на другие войны (в те времена мирных лет было крайне мало) и позабыли про всю эту Трою, но 2825 лет назад, уже в VIII-м веке до нашей эры, через 400 лет после всей этой истории, в Элладе возник слепой поэт Гомер, который сделал по данной теме исторический реферат в стихах — без рифм, зато особым устаревшим дактило-хореическим размером, который называют гекзаметром. И назвал он эту эпическую историю «Илиада» — по первозданному названию упомянутого города-государства.

По факту оказалось, что Гомер создал первую в истории мировой литературы и культуры трагедию, так-то. Да ещё на документальном материале. До него многие так делали, да не очень удачно. После него многие пытались повторить его подвиг, но увы, не осилили, и вся эта культура трагических возвышенных песнопений, гм, канула в Лету.

А мы, мировая культура (или надо говорить мы, мировые культуристы?) получили из всей этой гомеровской истории меметично-известные имена героев: Ахиллес (благородный дон, поражённый в пятку), Одиссей (благородный дон, который долго не хотел возвращаться домой, а когда вернулся — убил всех гостей в своём дворце), Аякс (их, как закарпатских деревень, сразу двое — Великий и Малый), Гекто-о-о-о-ор, Лаокоон (под видом статуи голого мужика с сыновьями и змеёй; походу, его запечатлели в процессе яростного развода) и прорицательница Кассандра (к слову, сестра Париса), которая проницательно предвидела, что данайский конь — это бэмц, но не предвидела, что ей грозит за это прорицание. Памятники ей не ставили, но один нерукотворный сам Высоцкий ей своими руками сотворил.

Ок, бро, это прохладная история, а причём здесь ментор? Пока что ни при чём, разве что есть любопытное совпадение — In Real Life в IV веке до н. э. одного из правителей той самой Трои звали Ментор! То есть, Ментор — это просто имя человеческое, вроде Владислав или Ярослав или Славослав… Во как!

«Одиссея»

Гомера все так хвалили за «Илиаду», что он забыл остановиться и выкатил в прод вторую стиховорную поэму на ту же тему — «Одиссе́я».

Помним, что среди участников троянского сражения и сидельцев внутри троянского коня был такой товарищ Одиссей — тоже очень благородный дон, итакиец, царь острова-государства Итака (всё ещё открыт для посещения).

В поздней латинской интерпретации Одиссея упёрто называют Улисс (Ulysses).

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

А дело было так. После одоления/поражения Трои все разъехались по домам. Но, например, Одиссей подзадержался в пути аж на десять лет — там то одно, то другое… Одиссея все эти десять лет на Итаке ждут его верная жена Пенело́па, верный сын Теле́мах, верный пёс А́ргус и неверные соседи, которые хотят зохавать себе всю Итаку и жену и собаку, раз уж хозяина нет дома. Они толпой тусят в доме Одиссея, их всех бесплатно кормят жители Итаки, и двенадцать рабынь Одиссея уже стали их любовницами, кагбэ, успех пришёл к пацанам.

Но тут на сцену выскакивает взрослеющий сын Одиссея Теле́мах.

В оригинале говорят Тэле́макхос, там «xэ» надо произносить манерно, как в «LaTeX». И ударение, как видим, на «е». Но я чаще слышал ударение на «а». Ну, мы Кема Кейнера называем Сэмом Канером и ничо, живы все.

Как-то получилось, что чем ближе к нам, тем чаще Тэле́маха начали называть Телема́х, и ничего с этим уже не поделать.

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

В те времена дети не боялись шариться до поздней ночи по округе, потому что каждый древнегреческий пацан знал названия минимум 300 звезд на небе и носил с собой острый ножик, из-за чего считалось, что юный древнегрек в принципе не может заблудиться. Но выходить за пределы своего района было опасно — у всех есть ножи, и всем нужны рабы… Мы же помним, что в Древней Греции не только придумали демократию, но и постоянно поддерживали рабовладельческий строй.

Собственно, Одиссей тоже был рабовладельцем и ничо, и норм.

А в этом строю будь ты хоть Телемах, хоть сам Максимус Ундецимус Меридианус Прайм, командующий северными армиями, генерал испанских легионов, верный слуга истинного Императора, отец убитого сына, муж убитой жены, сосед убитого соседа, нетленный автор постов и комментариев, но если тебя ВНЕЗАПНО стукают по башке каменюкой, связывают и на ближайшем рынке продают в рабство, то увы тебе и всем твоим титулам… А ещё в их мире не было паспортов, полиции и конституционных прав (потому что и самой конституации не было). А ещё в их мире постоянно шастают олимпийские боги, отчего ЛЮБОЙ человек на твоём на жизненном пути мог оказаться богом…

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

Некоторые наши современники, пересмотревшись фильмографии режиссёра Нолана, уже знают о том, что в Древней Греции существовал ранее упомянутый ксени́я (ξενία) — закон/обычай гостеприимства, который придумал Зевс:

• хозяин обязан принять путника, накормить и предоставить ему ночлег;
• гостя нельзя оскорблять или причинять ему вред;
• гость обязан уважать хозяина и не злоупотреблять его гостеприимством;
• между сторонами устанавливались долговременные взаимные обязательства.

В случае проделок Париса с Елены нарушение ксении особенно вопиюще: Парис и Елена не просто грубо обошлись с Менелаем, а нарушили священный порядок гостеприимства, который установил сам Зевс. Так-то.

И да, от этого обычая происходят женское имя Ксе́ния (др.-греч. ξενία «гостеприимство»). Сегодня не каждая Ксю знает, что носит имя, которое придумал Зевс, разве что ударение сместилось…

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

Ну да, ну да… Священное гостеприимство от людей, у которых есть рабы, и которым всегда нужны новые рабы.

И лёг спать усталый условный Максимус Ундецимус Меридианус Прайм, командующий северными армиями, генерал испанских легионов, ублаженный ласковыми рабынями и хмельными винами, и проснулся связанным и с комком (чужих) носков во рту по пути к ближайшей агоре на продажу… Ну и что? Ну и всё. Надо было успеть первым зарезать гостеприимных хозяев. End of story.

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

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

 

Телемахус и Ментор тыкают друг друга палкой по пальцам ног и мужественно терпят все невзгоды

Ааааааа, скажем мы, так вот почему ментор называется ментором! Он сопровождает юного Телемаха в путешествии и даёт ему мудрые советы…

Нет.

Смотрим дальше.

В какой-то момент во время этого путешествия облик Ментора незаметно принимает Афина — богиня мудрости, знаний, искусств и ремёсел, наук и мастерства, ума, сноровки, изобретательности, военной стратегии и тактики, которая заводит с ничего не подозревающим Телемахом прелюбопытные разговоры, в ходе которых мы понимаем, что пацан был вообще не дурак, мог сперва подумать/поразмыслить, и только после действовать.

Прямая цитата:

«Но, – отвечал рассудительный
сын Одиссеев, —
Как подойти мне?
Какое скажу я приветствие, Ментор?
Мало ещё в разговорах разумных
с людьми я искусен;
Также не знаю, прилично ли младшим
расспрашивать старших?»

Дочь светлоокая Зевса Афина ему отвечала:
«Многое сам, Телемах, ты своим
угадаешь рассудком;
Многое демон откроет
тебе благосклонный…»

Ааааааа, снова скажем мы, так вот почему ментор называется ментором! Это сама богиня мудрости сопровождает юного Телемаха в путешествии и даёт ему мудрые советы…

Это очень логичный вывод, но снова

НЕТ!

Смотрим ещё дальше.

Ментор в этой истории Гомера мудростью не блистал. Афина блистала, а Ментор — ну, просто взрослый, знатный человек, друг Одиссея и доверенное лицо, которому Одиссей поручает присматривать за домом (не справился) и Телемахом (почти справился). Никак не учитель, наставник или там, просветленный мудрец, просто сопровождал, ксению показывал. Да и не было ему нужды заниматься менторированием, для этого использовались другие люди и понятия — например, были люди с названием παιδαγωγός (paidagōgós). Как правило, педагогами называли рабов, которые должны были довести юного господина до школы и обратно, чтобы не прогуливал, ну и заодно посоветовать что-нибудь здравое, если будет необходимость, например, как приложить подорожник, если ушибся или что нельзя сосать сосульки. Ну или можно, но чтобы никто не видел.

А ещё у эллинов было слово διδάσκαλος (didáskalos) — буквально «Учитель», но надо учесть, что к нам это слово пришло из уже поздних библейских текстов, в которых так называли, например, самого Джызус Крайста. То есть, это не профессия, а призвание человека, который олицетворяет какую-то доктрину и «ведёт за собой» слушателей своих, аки пастырь овец.

В Румынии это древнее слово превратилось в dascăl и поныне обозначает сразу два явления: и устаревшее «учитель» и устойчивое «дьяк», который в церкви тянет «мнооооогая лееееета». Зачастую эти два понятия используются вместе и обозначают одного человека, потому что в церковно-приходских школах детей грамоте учили те же духовные (или придуховненные) лица, которые читали вслух религиозную пропаганду.

Поэтому факт — менторов, которых мы сегодня подразумеваем, в «Одиссее» не было. Было просто имя «Ментор».

А как, например, называла самого Ментора его мама? У любого ребенка есть уменьшительно-ласкательное имя, вероятно, Мент? И если бы Гомер назвал Ментора Ментом, то youtube > «Как найти мента по Java»…

Тут вдвойне любопытно — у Гомера таки упоминается мент! Даже два! Первый гомеровский Мент (греч. Μέντης, Méntēs) упоминается в «Илиаде» ― царь каких-то киконов. Второй Мент упоминается в «Одиссее» — царь мифического народа тафийцев.

Имя второго почему-то приобрело в древнегреческом народе уничижительное значение и стало обозначать зловещего посланника… Вероятно, бил подчиненных резиновыми дубинками по почкам.

В «Одиссее» Афина вольготно буйствует, и по ходу дела принимает как облик Ментора, так и облик Мента. Ух… Смена масок в древнегреческом театре была нормой.

Ещё скажем пару слов про образ Телемаха. Его образ — это такой себе эпик про взросление. Изначально это незначительный персонаж, рос без отца, в школу не ходил, в доме бардак, в голове кавардак, характер ненордический, не женат. Однако после упомянутого путешествия он вернулся домой слегка позврослевшим. И когда его отец таки является и говорит «Я твой father, Люк!», Телемах на пару с папой начинает недрогнувшей рукой методично убивать тех самых гостей, которые жрали, разлагались и домогались занять вакантное место царя Итаки. То есть, Телемах ДО путешествия — просто юноша. Телемах ПОСЛЕ путешествия — это взрослый тип с мачете. Machete kills.

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

«Приключения Телемака»

Итак, у нас уже несколько дядей с именем ментор:

• один из IRL правителей той самой Трои в IV веке до н. э.
• персонаж Ментор из Одиссеи

и ни один из них не олицетворяет связку «ментор — наставник». Противоречие…

Не все знают о том, что прохладные былины Гомера были топом во время их появления, но затем медленно исчезли из общественного поля зрения. Причин тому множество — чтобы их читать, надо было, соппсно, уметь читать… а это умели не все. Древний Рим, конечно, перенял много из эллинской культуры, но и там надо было сперва уметь читать, и желательно на эпическом древнегреческом. А гомеровский язык — это не совсем древнегреческий язык. Он не рассказывал, а пел поэтические песни, поэтому он использовал искусственный поэтический язык, в котором есть множество ОООООчень древних форм, которые дико необходимы для эпического стихосложения, но так же дико устарели и стали непонятными. Как выразился один из исследователей, «Эпическое повествование поэмы напоминает сон — событийный, красочный, жуткий, эротический, захватывающий и трогательный одновременно. Ни одна другая книга не подарит читателю такого сна». Язык — оружие, це однозначно.

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

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

А переводить все эти гекзаметры на певучую латынь — та ещё задача. И когда развалились древние римляне, читать это всё даже на латыни стало интересно немногим. Ну, серьезно, предположим, что на дворе условно 1699-й год, просвещенный 17-й век перетекает в 18-й, в Европе всё ещё пытаются оклематься от последствий безумной религиозной тридцатилетней войны и вообще не очень здравая обстановка. Идёт какой-нибудь молодой человек в библиотеку и просит что-нибудь интересного… Какова вероятность, что ему предложат почитать гомеровские тексты, которым уже 2500 лет!?

Но случилось непредсказуемое. В этом самом 1699-м году во Франции некий Франсуа Фенелон подхватывает древние тексты и выпускает приквел — якобы расширенные «Приключения Телемака» (Les Aventures de Télémaque).

Имя уже известного нам Телемаха на французский манер однозначно произносится как Телема́к, и можно предположить, что с тех времён исчезает Тэле́мах и появляется Телема́х, он же Телема́к.

Бить по рукам Фенелону некому, он берёт уже изрядно подзабытых за две тысячи лет древнегреческих персонажей и клепает по данному сюжету собственную историю путешествия юного древнегрека по мифическо-исторической Древнегреции, и в книге Фенелона Ментор становится уже не просто туда-сюда ходящим персонажем, а тем самым образцом «мудрого наставника», который направляет и обучает молодого человека.

У Фенелона история начинается сразу с того, что Телемак и Ментор почему-то выброшены бурей на остров бессмертной богини Калипсо — там, где ранее уже провёл много лет Одиссей. Богиня предлагает кораблекрушельным гостям переодеться в сухое, после чего она расскажет им про Одиссея… ну и всё такое. Телемак восхищается предложенным одеянием — тонкая ткань, одно снега белизны, другое багряного цвета с богатым золотым шитьем… И тут начинаются первые же слова Ментора, сказанные строгим голосом:

– Такие ли мысли, Телемак, должны занимать сердце сына Улиссова? Поддержать славу родителя, победить судьбу, тебя преследующую – вот что должно быть предметом твоих мыслей! Юноша, любящий, как женщина, драгоценное убранство, недостоин мудрости и славы. Слава есть достояние сердца, которое умеет страдать, отвергая забавы. Страшись, чтобы она не ввергнула тебя в новые бедствия. Страшись обворожительных ее прелестей более, нежели камней под водой. Кораблекрушение, самая смерть не столь опасны, как удовольствия, подмывающие в нас добродетель. Не верь хитрым вымыслам. Юность высокомерна, возлагает всю надежду на свою крепость, слабая трость мечтает быть всемогущей и, никогда не пребывая на страже у сердца, легкомысленно отдает его всякому. Не внимай сладким и льстивым словам коварной Калипсо. Они будут вкрадываться в тебя, как змея под цветами. Трепещи тайного яда, не верь себе и ничего не начинай без совета твоего верного друга.

Мог бы просто врезать палкой по спине. И тэ дэ, и дальше много всякого, чего у Гомера не было в принципе. Отсебятина, короче.

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

А ведь Гомер мог бы назвать упомянутого персонажа иначе, например, Ав]]> https://testitquickly.com/2026/10/03/cauta-ti-mentorul-singurel/ Sat, 03 Oct 2026 01:03:25 +0300

Что такое ТЗ в QA?

ТЗ – это документ, который описывает, как система должна работать: требования к функционалу, поведению, ограничениям и условиям приёмки. Тестировщик использует его как эталон: сравнивает реальное поведение системы с тем, что записано, и фиксирует расхождения как баги. На практике ТЗ часто либо нет, либо оно устарело, либо написано под тендер и расходится с реальностью.

Когда эталона нет, роль ТЗ берут на себя оракулы – другие источники истины: закон, договор, поведение прошлой версии, модель данных, ожидания пользователей. Отсутствие ТЗ не означает, что тестировать невозможно – оно означает, что нужно перестать искать один документ и начать собирать критерии, по которым вы будете проверять систему. 

---

О чём статья?

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

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

Утро понедельника. Открываешь трекер – «Протестировать личный кабинет, релиз в пятницу». Идёшь за подробностями: чат на 400 сообщений, два макета в Фигме, оба подписаны «финал», а разница между ними – половина экранов. И условный Коля в помощь, который вроде как точно в курсе и передаст контексты, но не факт.

Если у вас так не бывает – вы работаете по ГОСТ 34.602, где требования заморожены. Искренне поздравляем, дальше можно не читать.

Остальных сразу предупреждаем. Статья не о том, как заставить бизнес писать техзадание. Мы пробовали – это работает только там, где за документ платят отдельно. В остальных случаях бизнес по-своему прав: пока продукт ищет форму, подробное ТЗ устаревает быстрее, чем проходит согласование. Речь о том, как выстроить приёмку, которая не разваливается от изменений.

Практики, о которых пойдёт речь, придуманы не нами – на первоисточники мы дадим ссылки. Но имейте ввиду, что они создавались для среды, где в команде есть Product Owner с полномочиями, аналитик и культура письменных договорённостей. У нас чаще иначе: PM, который сам себе аналитик и заказчик, передающий знания голосовыми сообщениями, ну и релиз в пятницу. Поэтому адаптируем под наши реалии.

Почему нет ТЗ: 5 разных причин и что с этим делать

Первая ошибка, которую многие допускают годами, – реагировать на отсутствие ТЗ одинаково. Хватать чек-лист, идти смотреть продукт, писать вопросы. Иногда срабатывает, но чаще нет. На самом деле, отсутствие ТЗ указывает сразу на 5 проблем на проекте. Самое важное, вовремя понять, с чем имеете дело и построить адекватный план. 

Дифференциальная диагностика: почему у вас нет требований

Диагноз	Как выглядит снаружи	Что работает	Что делает хуже
Продукт в поиске	Гипотезы меняются каждые две недели. «Давайте попробуем, а там посмотрим»	Короткие циклы приёмки, артефакты со сроком жизни в один спринт	Требовать спецификацию до старта: затормозите поиск и получите документ, который врёт через месяц
Знание в головах	Есть 2–3 человека, которые «всё знают». Ответ получить можно, если поймать носителя	Извлечение знаний: Example Mapping, сессии с записью, журнал решений	Ждать, пока носители сами напишут. Не напишут: у них в голове всё структурировано, им не больно
Знание рассыпано	Документов сорок в четырёх системах, часть противоречит друг другу, актуальной не знает никто	Карта продукта, ранжирование источников по достоверности, пометки «это протухло»	Читать всё подряд: утонете и всё равно соберёте неверную картину
Документ врёт	ТЗ толстое и красивое, писалось под тендер. Реальность разошлась с ним процентов на семьдесят	Сверка с продом на выборке, фиксация дельты, дальше тестирование по факту	Заводить баги на каждое расхождение: утоните в спорах и потеряете доверие команды
Знание утеряно	Легаси. Авторы уволились в 2019-м. Есть код, логи и живые пользователи, больше ничего	Характеризующие тесты, анализ логов и БД, поведение прода как эталон	Спрашивать «а как должно быть?». Источник истины один — то, как оно работает сейчас

Диагноз ставится быстро. Соберите PM, разработчика и того, кто ближе всех к заказчику, и задайте четыре вопроса. 

1. Кто последним менял логику?
2. Где это записано?
3. Кто первым узнает, если поведение изменится?
4. Что будет, если через месяц спросить, почему сделано именно так?

Всё будет понятно уже по реакции на вопросы, даже если вам не ответят вслух.

Дальше действуйте по ситуации. Если продукт в поиске – нужны лёгкие артефакты и короткая обратная связь. Если знание утеряно – наоборот, тяжёлая автоматизация поведения: оно как раз стабильное, просто неизвестное. Поймите, одинаковый подход к разным случаям съест бюджет впустую.

Вы ищете требования, а нужны оракулы

Принято считать, что без требований тестировать невозможно. Логика простая: есть документ с эталоном, есть система, мы их сравниваем. Нет документа – нет сравнения. И это неправда. Вы открываете приложение, нажимаете «Оплатить», деньги списываются дважды. Нужен ли документ, чтобы понять, что это баг? Вы и так это знаете.

Механизм, который позволяет распознать проблему, в теории тестирования называется оракулом. В нынешнем виде термин оформили Джеймс Бах и Майкл Болтон в рамках подхода Rapid Software Testing. Суть простая: спецификация – лишь один оракул из десятка, причём не самый надёжный, ведь документ тоже пишет человек. Отсутствие ТЗ означает потерю одного оракула, остальные остаются на месте. Задача тест-инженера без документации – собрать и явно назвать доступные оракулы. Болтон свёл их в мнемонику FEW HICCUPPS, ниже – наш перевод под российские реалии.

Оракулы: чем заменить отсутствующее ТЗ

Оракул	Вопрос, который вы задаёте продукту	Где брать на практике
Прошлое системы	Раньше эта функция работала иначе. Изменение осознанное или случайное?	Прод, предыдущий релиз, скриншоты саппорта, записи демо. Самый мощный оракул на легаси
Внутренняя согласованность	Почему в одном разделе даты в формате ДД.ММ.ГГГГ, а в соседнем — ISO?	Сам продукт. Ищется бесплатно, чинится дёшево, заказчиком ценится высоко
Сравнимые продукты	Как эту задачу решают те, у кого миллионы пользователей?	Конкуренты, госуслуги, банковские приложения — для вопроса «мы точно осознанно сделали иначе?»
Заявленное вовне	На лендинге написано «выгрузка в 1С в один клик». Оно так?	Маркетинг, презентации продажникам, КП, договор. Юридически самое сильное «ТЗ» из имеющихся
Ожидания пользователя	Человек нажал «Назад» и потерял заполненную форму. Он этого ждал?	Обращения в поддержку, отзывы в сторах, записи сессий. Тикеты за квартал — золотая жила
Назначение	Зачем эта функция бизнесу? Она эту задачу решает?	Одно предложение заказчика: «мы это делаем, чтобы ___». Не формулируется — проблема крупнее тестирования
Стандарты и закон	Мы обязаны это делать по 152-ФЗ / 54-ФЗ / правилам платёжной системы?	Регуляторка, ГОСТы, требования НСПК. Единственная категория, где «мы так решили» не аргумент
Модель данных	В базе поле NOT NULL, а форма отправляет пустое. Кто прав?	Схема БД, миграции, OpenAPI. Технический слепок замысла честнее словесных описаний
Здравый смысл	Мне пришлось перечитать это сообщение об ошибке трижды. Так и было задумано?	Ваша собственная голова. Самый спорный оракул и одновременно тот, за который вам платят

Из практики. Личный кабинет страховой. Техзадания не было, только переписка за три месяца. Мы выписали оракулы за два дня и в итоге нашли в коммерческом предложении обещание, данное клиенту: расчёт полиса за 30 секунд. Разработка об этом ничего не знала, а расчёт шёл синхронным запросом к внешнему сервису и в пике занимал до четырёх минут. Проблему нашли до релиза просто потому, что догадались посмотреть коммерческое предложение, а не только трекер.

Менеджеру это даёт формулировку, которую не стыдно произнести перед заказчиком. Сказать «мы не можем тестировать, дайте требования» – значит поставить команду в позицию жалобщика. Сказать «мы принимаем систему по восьми критериям: закон, договор, поведение прошлой версии, согласованность, данные, ожидания пользователей, назначение и статистика продаж – вот результат по каждому» – значит поставить команду в позицию эксперта. Разница колоссальная. 

Карта продукта: документ, который при правильном подходе не устаревает

Оракулы говорят, по чему сверять – осталось понять, что сверять.

Карта продукта описывает не поведение системы, а перечень того, что в системе есть. Поэтому от изменения требований она не устаревает, только от изменения состава. Структуру карты можно взять из Heuristic Test Strategy Model Джеймса Баха, там она называется SFDIPOT.

Семь срезов, по которым раскладывается любая система

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

Структура

Из каких кусков физически собран продукт?

Функции

Что он умеет делать — включая скрытое?

Данные

Чем он оперирует и что накопил за годы?

Интерфейсы

Через что с ним общаются люди и машины?

Платформа

От чего чужого он зависит и не управляет?

Сценарии

Как им реально пользуются, а не как задумано?

Время

Что ломается от дат?

Что обычно забывают, когда работают по ТЗ:

Фоновые задачи и крон — их нет в макетах, но именно они портят отчётность

Данные, накопленные за годы: у пользователя 4000 заказов, а список грузит все

Административные интерфейсы: их «как-нибудь потом», а через них меняют тарифы

Переходы через полночь, конец месяца, 29 февраля, смена тарифного периода

Внешние зависимости в состоянии «медленно отвечает», а не «упало»

Модель SFDIPOT из Heuristic Test Strategy Model (J. Bach). Красным — области, которые выпадают из ТЗ систематически: техзадание пишут про то, что видно на макете.

Как собрать карту за два дня без аналитика?

Начинайте с самых честных источников и далее уже к разговорам с людьми.

1. Схема базы и миграции. Здесь за 90 минут выясняется, что типов пользователей три, а рассказывали про два.
2. Роутинг и точки входа. Займёт час. Все URL и эндпоинты, включая забытые. Плюс OpenAPI, если живой.
3. Логи за месяц и конфиги. Три часа. Что реально вызывается и как часто, топ ошибок, крон, очереди, флаги. Обычно тут обнаруживается, что в проде ежедневно что-то падает и все привыкли.
4. Тикеты поддержки за квартал. Три часа, самое полезное вложение из списка. Боли живых людей, отсортированные по частоте. Заодно словарь: как пользователи называют то, что в коде зовётся иначе.
5. И только теперь сбор информации у людей. Хватит половины дня. Но сразу приходите с конкретными вопросами и наработками карты продукта.

Осторожно! Никогда не начинайте с разговоров. Человек описывает не систему, а свою модель системы: ту часть, с которой работал, в том виде, в каком запомнил. Придёте с картой и конкретикой – получите уточнения и опровержения. Придёте с пустым блокнотом – получите пересказ счастливого пути и уйдёте в уверенности, что всё поняли. 

Держите карту в вики в виде дерева на 1-2 страницы, чтобы она работала как общий актив: разработчик сможет проверить, не забыл ли админку, PM возьмёт для оценки объёма, новичок за час поймёт устройство продукта. Договоритесь о правиле: карта обновляется в том же PR, где меняется состав системы. Новый эндпоинт – строчка. Это единственный известный нам способ не дать документу устареть. 

Как перестать думать про покрытие и начать говорить о рисках?

Рано или поздно менеджер задаёт неприятный вопрос: какой у нас процент покрытия требований? На проекте без ТЗ честный ответ – знаменателя не существует. Но так отвечать нельзя, после этого разговор о качестве просто заканчивается.

Выход есть, и он лучше: говорить не о покрытии, а о рисках – какие из них мы сознательно принимаем, выпуская релиз в прод. Бизнес это понимает, потому что риски – это про деньги и последствия. Полного покрытия не бывает никогда: даже с идеальным ТЗ вы не проверите всё. Значит, вопрос всегда был не «покрыто или нет», а «чем именно мы решили рискнуть».

Метод называется RiskStorming. Собираете всю команду на час, обязательно с разработчиками – они знают, где тонко.

Каждое действие не больше 15 минут.

1. Каждый молча пишет, что может пойти не так с релизом. По пункту на стикер. Молчать принципиально, иначе первый заговоривший задаст настроение и рамку обсуждения.
2. Раскладываем по карте продукта. Обращайте внимание на перекосы: девять рисков на платежах, а на импорте прайсов ни одного? Это не потому что там безопасно, а потому что про импорт никто не подумал.
3. Раскладываем по двум осям: вероятность и ущерб, по квадрантам, без баллов и формул. Спор тут полезнее результата – команда впервые вслух проговаривает самые острые риски.
4. Решаем судьбу каждого: проверяем, автоматизируем, страхуемся флагом, мониторим в проде или принимаем.

Карта рисков релиза: что мы делаем с каждым квадрантом

Высокий ущерб · Низкая вероятность

СТРАХУЕМ

Проверяем точечно, закрываем фича-флагом, готовим план отката

«Двойное списание при повторной отправке формы»

Высокий ущерб · Высокая вероятность

ГЛУБОКО ТЕСТИРУЕМ

Сессии + автотесты + мониторинг. Сюда уходит до 60% всего времени

«Расчёт скидки по новым правилам лояльности»

Низкий ущерб · Низкая вероятность

ПРИНИМАЕМ

Записываем в протокол и не трогаем. Это тоже решение, и оно осознанное

«Съехала вёрстка футера в старом Safari»

Низкий ущерб · Высокая вероятность

ЛОВИМ В ПРОДЕ

Алерт + быстрый откат дешевле, чем ловить на стенде

«Тормозит выгрузка отчёта у крупных клиентов»

Правило десяти строк

• На каждый релиз — не больше десяти рисков.
• Каждый риск формулируется письменно, в одном месте, с указанием владельца.
• Одиннадцатый риск означает, что вы не приоритизировали, а перечислили всё подряд.
• Список из сорока рисков не читает никто, включая того, кто его составил.
• Проверено на себе: наш первый реестр был на 63 пункта.

Потом эти риски нужно перенести в таблицу – она станет основой протокола приёмки. Колонок пять: риск, оценка, что делаем, владелец, статус. Строк тоже около пяти, не сорок – иначе реестр не будет читать никто, включая того, кто его составил. Самая важная строка та, где в статусе стоит «принят»: в этот момент ответственность за решение переходит от тестировщика к бизнесу, причём письменно. Запись вида «вёрстка съезжает в браузерах старше двух лет, доля таких пользователей 0,4%, принимаем» – это полноценная строка реестра, и она закрывает вопрос навсегда. 

Что это даёт менеджеру? Разговор о том, почему баг ушёл в прод, превращается из поиска виноватого в сверку по списку. Либо риск был в реестре и его приняли – тогда обсуждаем, верным ли оказалось решение. Либо его там не было – тогда обсуждаем, почему команда его не увидела. Оба разговора продуктивны. А разговор в формате «кто пропустил» не продуктивен никогда.

Вывод

Если на вашем проекте нет ТЗ, а вопрос про покрытие каждый раз заканчивается неловкой тишиной – запишитесь на бесплатную консультацию. За 30 минут разберём конкретно ваш случай: посмотрим, что болит, и подскажем, как собрать рабочий набор – оракулы, карту продукта, реестр рисков. Поделимся своими методами, которые работают, когда требований не предвидится. Запишитесь, и уже на следующем релизе разговор с менеджером пойдёт по-другому.

Помните, отсутствие ТЗ – это показатель пяти проблем, и каждая решается своим инструментом. Оракулы дают, с чем сравнивать. Карта продукта – что проверять. Реестр рисков заменяет бессмысленный разговор о покрытии тестами. В итоге вы приходите к заказчику не с жалобой на отсутствие требований, а с протоколом: вот критерии приёмки, вот риски, вот что приняли и т.д. Это позиция эксперта и профессионала.

Во второй части будет больше практики. Вы узнаете, как проводить Example Mapping, какие артефакты заводить, как выстроить три контура приёмки и вести журнал решений. Расскажем, на какие метрики смотреть без ТЗ и какие инструменты использовать. Следите за обновлениями!

]]> https://quality-lab.ru/blog/testirovanie-bez-trebovanij-orakuly-karta-produkta-i-risk-orientirovannoe-testirovanie/ Fri, 02 Oct 2026 18:57:00 +0300

Когда-то я хотела сделать мини-курс «автоматизируем в Postman», а потом начала делать уроки и-и-и-и... Вышло 14 тем! ????

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

Ведь можно научить писать автотесты и за 1-2 урока, но мы подробно разбирали каждую тему, и циклы, и мат. функции, и многое другое. В общем, отличный курс для старта в автоматизации!

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

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

Однако «время пришло». Когда я чуток подосвободилась, я решила перезаписать курс и снять эти претензии. Что в итоге получилось?

Что обновлено

Видеолекции

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

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

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

Также около года назад я добавила в курс тему про ИИ, в том числе Postbot-a, ИИ от постмана. И вот он за этот год поумнел! И стал спрашивать разрешение на правки, как делают это другие AI-агенты. А год назад я просила исправить один автотест, а он вырезал еще десяток, причем молча.

Так что и это переписала, показала новое AI. Плюс добавила кусок про Cursor, куда же без него.

Потом постман сделал функцию загрузки файлов платной — и снова пришлось обновлять лекции.

В общем, перезаписано все, что-то даже пару раз =))

Дополнительные материалы

За этот год я написала пачку новых дополнительных материалов, которые добавила в курс. Но все они опубликованы на Хабре или у меня в блоге, так что вы могли их видеть.

Почистила неактуальные ссылки, добавила новые. В общем, немного причесала доп материалы.

Домашние задания

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

• что-то убрала совсем
• что-то сделала необязательным
• что-то немного упростила / изменила

Вопросы и ответы

1. Я недавно прошел курс, а он теперь новый, могу я увидеть свежие лекции?

Да, можете! И они есть прямо у вас в СДО. После апреля я дописала пару последних тем, но они чисто обновлены, сам текст лекции не изменился.

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

2. А если я уже проходил курс, мне есть смысл его повторить?

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

А вот если вы брали курс и забросили его на первых уроках, то можно прийти сейчас на обновленный поток! Только обязательно напишите менеджерам на почту, так как уже проходившим курс будет 50% скидка (если не было возврата). 

]]> http://okiseleva.blogspot.com/2026/10/postman.html Thu, 01 Oct 2026 20:01:08 +0300 Написала мне вчера на почту читательница Ольга. Она купила книгу «SQL. Курс молодого бойца» на Озоне, но что-то пошло не так:

Артикул на Озон —  5380148987

Мне очень кажется что это не ваша книг,  а копия. Плохая копия (Буквы плывут, картинки тоже и снизу каждой страницы присутствует какая-то ссылка. 

Ваши книги у меня уже есть и мне есть с чем сравнить типографскую печать и какую-то «неофициальную» печать. 

 

Показала издателю, он подтвердил — да, это ПИРАТЫ.

На это намекает название продавца, явно китайского:

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

Чтобы быть уверенным в продавце, лучше брать напрямую у издательства БХФ, они на Озоне — Торговый дом ИКС, вот книга про SQL.

Тогда, если будет плохая печать, можно писать издателю напрямую и они заменят книгу. С браком работают. 

На что обращать внимание на озоне:

• По названию продавца — не китаец (русские названия могут быть партнерами издательства)
• По названию книги — у издательства название четкое, «SQL. Курс молодого бойца», у подделки вместо названия описание книги «Популярный самоучитель по SQL от Назиной Ольги»

Цветные книги продавали на Озоне «Линукс-центр», они напрямую у меня брали. Сейчас их там не вижу, тогда оригинал будет только у меня на Авито.

Как-то так. Остерегайтесь подделок, иначе это будут деньги "вникуда" ????

]]> http://okiseleva.blogspot.com/2026/10/blog-post.html Thu, 01 Oct 2026 19:24:24 +0300 Автор: Александр Поляков, Управление развития платформенных сервисов кибербезопасности, Департамент „Сервисы“ и безопасности

Меня зовут Александр, я из Сбера, лидер по автоматизации в Департаменте Сервисы и Безопасности. В тестировании я около 13 лет, и последние лет 10 занимаюсь автоматизацией и её развитием в своём подразделении.

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

Где мы сейчас: ИИ уже в разработке, но почти не в автотестах

По данным недавнего опроса StackOverflow, 84% разработчиков постоянно используют ИИ‑ассистенты в своей работе. Для них это такой же привычный инструмент, как IDE или Git.

Как обычно работает подобный ИИ‑помощник в IDE:

• анализирует открытые файлы;

• дополнительно смотрит на соседние файлы в проекте;

• учитывает локальный контекст: какие вопросы вы задавали и какой код меняли.

А вот автотестировщики часто оказываются как будто «на обочине» этой ИИ‑революции.

]]> https://www.software-testing.ru/library/testing/testing-automation/4562-rag-llm Tue, 29 Sep 2026 23:00:00 +0300 Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Как можно использовать GPT в тестировании? Некоторые предлагают использовать его для генерации тестовых данных. Случайные тестовые данные могут помочь предвзятости меньше влиять на тестирование.

Можно предположить, что заставить бота генерировать случайные данные по простому промпту — это легко. Поэтому я провёл небольшой разовый эксперимент «первого барьера» 24 июля 2025 года, используя Google Gemini 2.5. Здесь отмечу случаи, соответствующие пунктам из нашего списка синдромов больших языковых моделей — шаблонов неправильного поведения, которые мы с Джеймсом Бахом наблюдали у LLM.

Сторонники ИИ часто делают чрезмерно громкие заявления о том, что GPT может делать что-то «как человек» — и нередко намекают, что GPT лучше людей, потому что быстрее и имеет мгновенный доступ к информации в интернете. Чтобы это было правдой, нужно на разумных основаниях ожидать, что GPT выполнит задачу так, как было запрошено, и учтёт возможные недопонимания по ходу дела. Это ожидание не оправдывается.

]]> https://www.software-testing.ru/library/testing/test-analysis/4540-experiment-generating-random-test-data Sun, 27 Sep 2026 23:00:00 +0300

Что такое тестовый контур?

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

---

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

В заключительной статье Олег разберёт российскую специфику: ИНН, СНИЛС, ФИАС, паспортные данные и часовые пояса. Расскажет о трёх реальных кейсах – с конкретными цифрами до и после. Покажет инструменты, применимые в российских реалиях, посчитает экономику внедрения и даст план, по которому команда сможет получить первый рабочий домен за 90 дней.

Тонкости работы с синтетическими данными в России

Это та часть, с которой нельзя работать по шаблону. Международные инструменты в российских реалиях могут выдавать номер социального страхования вместо СНИЛС и адрес в формате улица, город, штат. Даже локаль ru_RU в популярных библиотеках выдаёт правдоподобные строки, которые не проходят валидацию.

Следствие простое и обидное: сгенерируете ИНН как двенадцать случайных цифр – на входном валидаторе отвалится примерно 90% записей. Вы будете тестировать не систему, а свой генератор. И узнаете об этом дня через три.

Правила, которые придётся написать самим

Атрибут	Как ломается по умолчанию	Как делать	Источник справочника
ИНН	Случайные цифры не проходят проверку контрольного разряда	Генерировать первые 9 (или 10) цифр, считать контрольные по весовым коэффициентам. Для юрлица — следить, чтобы первые две цифры соответствовали региону из адреса	Алгоритм ФНС, коды регионов
СНИЛС	То же самое плюс забывают про правило «остаток 100 или 101 даёт 00»	Веса 9…1 по девяти цифрам, остаток от деления на 101, особый случай для 100 и 101	Алгоритм СФР
КПП, ОГРН, БИК	Генерируются независимо от ИНН — и получается юрлицо из Владивостока с московским КПП	Генерировать связкой: регион — ИНН — КПП — БИК обслуживающего банка. Связность важнее правдоподобия отдельных полей	Справочник БИК, коды регионов
Номер карты	Алгоритм Луна соблюли, а БИН взяли реальный действующий — и получили номер, который может существовать	Луна плюс БИН из тестовых диапазонов платёжных систем. Никогда не используйте боевые БИН своего банка	Тестовые диапазоны платёжных систем
Номер телефона	Все записи вида +7 999 000-00-00, либо реальные существующие номера — и рассылка из тестового контура уходит живым людям	В России нет зарезервированного диапазона по аналогии с американскими 555. Берите неназначенные диапазоны из реестра нумерации и держите отдельный чёрный список	Реестр российской системы и плана нумерации (открытые данные Минцифры), выгрузки ЦНИИС
Адрес	Готовые локали склеивают случайный город со случайной улицей и случайным индексом. Валидатор адреса такое отбрасывает	Идти сверху вниз по иерархии ФИАС/ГАР: регион — город — улица — существующий дом — индекс этого дома	ФИАС / ГАР
Паспорт	Серия не соответствует региону выдачи, дата выдачи раньше даты рождения, возраст не бьётся с обязательной заменой в 20 и 45 лет	Серия = код региона + год выпуска бланка; проверять правило замены документа по возрасту	Коды регионов
ФИО	Транслит или короткие латинские строки. Ломается сортировка, ширина колонок, поиск	Кириллица, обязательно «ё», двойные фамилии, отчества на -оглы и -кызы, склонения в тех местах, где система их показывает	частотные словари имён
Даты и время	Всё в UTC либо всё в московском времени	Одиннадцать часовых поясов в одной таблице. Отдельно — исторические данные до 2014 года, где был переход на летнее время	tzdata
Календарь нагрузки	Равномерное распределение дат по году	Производственный календарь: провалы 1–8 января и 9 мая, пики перед праздниками, всплеск в дни зарплат (обычно 5-е и 20-е числа)	производственный календарь
Суммы и НДС	Нормальное распределение сумм и одна ставка НДС	Логнормаль плюс «магнит» на круглые суммы (1000, 5000). Ставки 20 / 10 / 0 в правильных пропорциях по видам товаров, банковское округление	—

Отдельно про кириллицу – здесь я как-то потерял два дня

В разных колляциях буква ё встаёт то после е, то в конце алфавита, и результат сортировки по полю ФИО на синтетике отличается от прода. Если автотесты сравнивают выдачу списка построчно, вы получите красные тесты на ровном месте и потратите день на выяснение, почему база сортирует не так, как ожидал разработчик. Проверяйте колляции до, а не после.

Три кейса из практики

Три истории для понимания. Компании и цифры изменены из-за NDA, но ситуации повторяются от проекта к проекту.

Кейс первый: процессинг, эквайринг

Стенд был зелёный, но прод лёг через 40 минут после релиза

Что было?

Нагрузочный контур на 1,2 млрд транзакций. Данные сгенерировали честно, но равномерно: мерчантов раскидали поровну по 40 тыс. значений, даты распределили ровно по трём годам. Тесты показывали p99 в 180 мс, релиз выпустили. Через 40 минут после выкатки p99 на проде достиг 4,2 секунды, и дежурная смена откатывала всё вручную.

Что оказалось?

Два распределения оказались сломанными, и казалось, что это мелочи. А ещё была скошенность. В проде 0,4% мерчантов давали 61% трафика. На равномерных данных планировщик оценивал селективность как одну сорокатысячную и выбирал индексный доступ. В проде для горячих мерчантов эта оценка врала в сотни раз, и план запроса разваливался в чтение половины таблицы.

Профиль партиций. Данные равномерно распределены по трём годам, а в проде 70% объёма приходится на последние 90 дней. Горячая партиция на стенде была в 12 раз меньше реальной и целиком помещалась в память.

Что сделали?

Обучили копула-модель на срезе в 30 млн строк – заняло 40 минут, без GPU. Вытащили распределение мерчантов: закон Ципфа с показателем около 1,1, профиль по часам суток, долю возвратов, распределение сумм. Размножили до 1,3 млрд строк на восьми воркерах, добавили 900 записей из каталога патологий и, что оказалось важным, перемешали данные перед загрузкой.

Что стало?

Сравнение стендов «до» и «после»

Показатель	Прод	Стенд «до»	Стенд «после»
p99 на проблемном запросе	4 200 мс	180 мс	3 800 мс
Джини по мерчантам	0,81	0,02	0,79
Доля объёма в последних 90 днях	70%	8%	69%
Размер таблицы на диске	4,1 ТБ	1,6 ТБ	4,0 ТБ
Совпадение планов на топ-50 запросов	—	54%	94%

Дальше всё пошло легче: стенд стал ошибаться в ту же сторону, что и прод. Нашли три проблемных запроса, два переписали, к одному добавили индекс – p99 упал до 240 мс. Генерация 1,3 млрд строк заняла около четырёх часов.

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

Кейс второй: медицинская информационная система

Модель запомнила семь наших маячков – значит, запомнила и пациентов

Что было?

40 млн текстовых протоколов приёма. Данные нужны для тестирования поиска и извлечения сущностей: без реальных текстов поиск не проверить, а реальные тексты – это специальная категория персональных данных, и за их утечку штрафуют на 10–15 млн.

Взяли локальную русскоязычную модель на 7 млрд параметров, дообучили на срезе из 2 млн протоколов, сгенерировали 12 млн новых. Метрики похожести – отличные, различимость 0,54. Врачи читали и говорили: выглядит как настоящее.

Что нашли?

Перед обучением мы спрятали в срез 500 маячков – вымышленных пациентов с редкой фамилией, редким диагнозом и точной датой рождения. После генерации простой поиск нашёл семь маячков почти дословно, а один – с полной датой и фамилией в одном предложении. Значит, модель буквально воспроизводит обучающие записи. И если она вытащила наши маячки, то вытащила и реальных пациентов – просто мы их не узнаём.

Вылезло и второе: 0,6% сгенерированных протоколов содержат настоящие названия отделений и фамилии врачей. Их не считали персональными данными – зря. Фамилия врача + отделение + дата – это почти паспорт человека.

Что сделали?

Убрали дубликаты из обучающего среза через MinHash с порогом 0,8 – выкинули 11% записей, в основном шаблонные протоколы. Сократили обучение с 8 эпох до 2: похожесть почти не просела, а запоминание упало резко. Подняли температуру до 0,9, ограничили top-p до 0,92. Добавили пост-фильтр: если запись совпадает с обучающей на 8-грамму длиннее 60 символов – выбрасываем. Теряли около 0,4%, терпимо. Включили фамилии врачей и названия отделений в список замещаемых сущностей.

Что стало?

Маячки перестали появляться на трёх прогонах подряд. Качество поиска на синтетике осталось в пределах 4% от реальных данных – для регрессии годится. Проверка на маячки теперь живёт в CI и занимает восемь минут.

Вывод: без активной проверки на запоминание вы не узнаете, что модель плывёт. Метрики похожести этого не показывают – наоборот, чем сильнее модель запомнила, тем красивее у неё метрики.

Кейс третий: крупный ритейл, 11 систем

60% сквозных тестов падали не из-за багов

Что было?

11 систем: сайт, приложение, CRM, склад, доставка, лояльность, биллинг, поддержка, аналитика и две партнёрские интеграции. Каждая маскировала данные по-своему, со своим ключом. В итоге 8827 клиент в CRM не имел ничего общего с клиентом 8827 в биллинге. Простой сценарий – оформил заказ, оплатил, вернул часть, получил бонусы – разваливался на втором шаге. Команда сквозного тестирования тратила около 60% времени на разбор падений, вызванных не багами, а рассогласованием данных.

Отдельным удовольствием была подготовка окружения: заявка в ИБ, согласование, работа DBA, маскирование, выгрузка – 9 рабочих дней в среднем при двухнедельных спринтах.

Что сделали?

Ввели единый сервис идентичности: псевдоним считается детерминированно через HMAC-SHA256 от натурального ключа сущности с общей солью, соль лежит в защищённом хранилище. Один реальный клиент во всех 11 системах превращается в одного и того же синтетического – без обмена данными и без общей таблицы соответствий.

Второе решение не менее важное: генерировать не поля, а личность целиком. ФИО, телефон, адрес, документы, дата рождения, пол – один согласованный объект, который потом раскладывается по системам. Раньше каждая система генерировала своё, и получался клиент по имени Мария Петрович с мужским обращением в письмах.

Третье: срез вместо полной копии. Обошли граф из 340 таблиц и 1 100 внешних ключей, взяли связный подграф на 2,5% клиентов – 50 ГБ вместо 6 ТБ.

Что стало?

Что изменилось после перехода на синтетику

Показатель	Было	Стало
Падения сквозных тестов из-за данных	60%	4%
Подготовка окружения	9 рабочих дней	40 минут по кнопке
Объём тестового контура	6 ТБ × 14 команд	50 ГБ × 14 команд
Систем с реальными ПДн в тестовом контуре	11	0

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

Какие двенадцать ошибок поджидают вас по мере роста проекта?

1. Обучили генератор на полном проде в незащищённом контуре. Юридический риск: копия боевых данных всё равно побывала там, где не должна была.
2. Положили обезличенную копию рядом с исходной. Прямое нарушение приказа № 140 – совместное хранение запрещено. А это ровно то, что делает CREATE TABLE clients_masked AS SELECT … в той же базе.
3. Считали маскирование обезличиванием. Пока есть ключ обратимости, у вас на руках персональные данные. Самая частая и самая дорогая путаница из всех.
4. Мерили качество по средним. Среднее совпало, распределение развалилось. Смотрите перцентили, кардинальность и скошенность; среднее не смотрите вообще, оно обманет.
5. Забыли про NULL. В проде 12% пустых, в синтетике ноль. Ни одного падения на пустом значении не поймали – все сразу пришлось ловить уже на проде.
6. Не зафиксировали seed. Баг «воспроизводится через раз», вы проводите два дня расследований, и выясняется, что это не баг, а другой датасет.
7. Сгенерировали справочники. ОКВЭД, регионы, коды валют, МСС – это не ПДн, их копируют один в один. Синтетический справочник ломает соединения и половину бизнес-логики.
8. Убрали все дубли. В проде дубли есть, и система обязана их переваривать. Стерильные данные не проверяют то, ради чего писалась дедупликация.
9. Не проверили контрольные суммы. Девяносто процентов записей отваливаются на валидаторе, тесты «проходят» по трём процентам данных, и месяцами никто не замечает.
10. Оставили реальные «неперсональные» идентификаторы. Номер договора, полиса, обращения. По ним обычно есть публичная форма проверки статуса – это и есть та самая дополнительная информация из определения обезличивания.
11. Не поставили срок жизни датасета. Через год сорок терабайт «на всякий случай», и никто не помнит, где среди них выгрузка двухлетней давности с настоящими ПДн. Ставьте TTL сразу, потом не соберётесь.
12. Сделали данные чище прода. В боевой базе грязь, битые кодировки, «Ошибка» в поле «Город» и клиенты, зарегистрированные в 1970 году. Грязь надо воспроизводить намеренно и в правильной доле.

Инструменты: что выбрать с учётом российских реалий?

Ландшафт собран по слоям, а не по вендорам: вендоры меняются, слои – нет. Часть зарубежных платформ недоступна, а часть неприменима просто потому, что это SaaS – данные для обучения из периметра не выпускают. Открытые библиотеки при этом ставятся локально и работают у всех одинаково.

Стек инструментов по слоям

Слой	Международная практика	Что применимо в РФ	Комментарий
Поиск чувствительных данных и профилирование	Microsoft Presidio, ydata-profiling, Great Expectations, Soda	Всё перечисленное ставится локально; из коммерческих — «Гарда Data Masking» с ML-поиском ПДн, решения InfoWatch	Начните с открытых, коробочное берите, когда схема больше пары тысяч таблиц
Табличный синтез	SDV (GaussianCopula, CTGAN, TVAE, CopulaGAN), synthpop, Gretel, MOSTLY AI, Tonic, Syntho, Hazy, K2view	SDV и synthpop — локально, без ограничений. Из отечественного развивается сервис SyntData у Сбера	SaaS-платформы отпадают сами: данные для обучения наружу не выпустишь
Последовательности и временные ряды	PAR из SDV, TimeGAN, DoppelGANger	То же самое, всё открытое	Марковская цепь плюс распределение интервалов часто не хуже и в разы дешевле
Текст	Крупные LLM через API + Presidio для деидентификации	Только self-hosted модели с хорошим русским. Для NER — Natasha, Slovnet, DeepPavlov	Отправлять реальные ПДн во внешний API нельзя. Обучать на них — только локально
Правила и фикстуры	Faker, Mockaroo, Datafaker, dsdgen из TPC-DS	Faker с локалью ru_RU, Mimesis — плюс обязательная своя надстройка под контрольные суммы и справочники	Это тот слой, который вы всё равно допишете сами. Заложите на него две-три недели
Маскирование и подмена	Delphix, Informatica TDM, IBM Optim	«Гарда Data Masking», решения на pgcrypto и FF1	Помните: обратимое маскирование не выводит данные из-под 152-ФЗ
Масштабирование до терабайт	Spark, Trino, dbt	Spark, ClickHouse (numbers_mt, generateRandom, словари), Greenplum и его российские сборки, YTsaurus	ClickHouse на генерации плоских таблиц вне конкуренции по скорости
Оценка качества и приватности	SDMetrics, Anonymeter, TAPAS	Всё открытое, работает. Как рамка для отчётности — ПНСТ 1066-2026	Отчёт по ПНСТ — то, что теперь спрашивают на комитете вместо рассуждений
Оркестрация и доставка	Airflow, Dagster, Tonic Ephemeral	Airflow, NiFi, собственный сервис выдачи окружений	Цель — «данные по кнопке за минуты», а не «заявка в ИБ на девять дней»

Защита бюджета: четыре статьи, без которых расчёт не работает

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

Из чего складывается экономический эффект

Статья	Как считать	Пример: 14 команд, 24 спринта в год
1. Простой в ожидании данных	Дней ожидания × число команд × спринтов × стоимость дня команды	2 дня × 14 × 24 × 180 тыс. ₽ ≈ 121 млн ₽ в год
2. Дефекты, пропущенные из-за нерепрезентативных данных	Доля инцидентов прода, помеченных «на тесте не воспроизводилось» × средняя стоимость инцидента	18 инцидентов × 1,4 млн ₽ ≈ 25 млн ₽ в год
3. Хранение и сопровождение копий	Терабайты × число контуров × стоимость хранения и администрирования	6 ТБ × 14 × стоимость СХД и работ ≈ 8–12 млн ₽ в год
4. Хвостовой риск утечки	Вероятность × размер штрафа плюс репутационные потери. По 420-ФЗ для повторного нарушения — 1–3% годовой выручки, минимум 25 млн	Считается отдельно, но именно эта строчка снимает вопросы у правления
Продолжаю рассказывать про косяки ИИ. Нужно всегда помнить, что за ним глаз да глаз нужен! Есть у меня задача, я ее проверила уже вручную — все работает. Осталось автотесты написать. Это можно и ИИ делегировать, особенно если "списать" неоткуда. Создала папку с автотестом,  накидала куда примерный запрос-ответ (SOAP-метод),  добавила description.md, описав тест отдала это Курсору — на, поправь тест Обычно он нормально тесты правит, посмотрит на падение, почитает описание теста и все сделает. Но тут я смотрю — в код полез! И пишет такой: А вот в методе save в ответе не считывается вот этот блок, я исправил такой-то Java-класс, и теперь тест зеленый! Стоп-стоп-стоп! Я же проверяла вручную, оно работало. Но, может, в тесте меня угораздило попасть в какой-то другой класс эквивалентности?  Уточнила у Курсора: — Но у меня вручную все работаело. Как воспроизвести вручную? — Ты, наверное, не в ответ от save смотрела, а потом другой метод дергала. Смотри, делай раз, делай два... (выдал инструкцию) Ок, пойдем проверять. Сервер приложения я поднимаю локально, но он тяжелый, не взлетает, когда открыто IDE + Cursor. Так что ИИ закрыла, сервер подняла, у меня как раз была сборка до этих изменений. Сижу, проверяю. Хм, все работает... Погасила сервер, пошла дальше общаться с ИИ: — Вручную работает! — Ты, наверное, не тот метод смотришь (ля-ля-ля тот же текст, что говорил в прошлый раз) — Нет, я смотрю именно текущий save! — Да ты гонишь! (он другими словами это говорит, но смысл именно такой) Попрепиралась, пошла через командную строку тест запустить, проверить. И тут вижу, Курсор написал на мое последнее сообщение: — А, да, откатил правку кода, а тест остался зеленым. ???????? А сначала то как напугал! Я то уж думала "ща, пара тестиков и задачу закрываю", а тут баг! Это ж надо к разработчику идти, чтобы он проревьюил код ИИ, внес эти правки, потом думать, какие тесты еще написать...  Ну а чтобы не идти с "ой, мне тут ИИ насоветовал", решила перепроверить. И не зря! Мораль сей басни такова — ИИ как типичный разработчик, нет ему веры ???? Всегда проверяйте, что он там насочинял в коде =) ]]> http://okiseleva.blogspot.com/2026/09/blog-post.html Wed, 23 Sep 2026 21:58:49 +0300 Что такое конвейер синтетических данных? Конвейер синтетических данных – это процесс генерации искусственных тестовых данных. Они повторяют статистические свойства боевых: распределения, пропорции, корреляции и редкие случаи, – но не содержат персональных данных пользователей. Результат конвейера – синтетические данные, которые ведут себя как реальные, но при этом без юридических рисков. Наш ведущий эксперт Олег написал цикл из трёх статей, где пошагово показывает, как построить конвейер для обезличенных данных в промышленных объёмах и убедиться, что всё работает корректно. В первой части разобрались, где заканчивается маскирование и начинается синтез, и почему граница между ними не техническая, а правовая. Теперь переходим к практике: от минимизации хаоса в тестовых данных до автоматизации за 7 шагов. Порядок действий здесь важен: пропустите первый – развалится третий и т.д. Это проверенный на практике план, поэтому лучше придерживаться указанной методологии. Шаг 1. Инвентаризация и профилирование: этап, который вечно хотят пропустить Кажется, понять, что лежит в базе, проще простого. Но если посмотреть на реальные данные, а не на названия колонок, картина оказывается другой. На каждом проекте я повторяю одно и то же: классифицировать поля нужно по содержимому, а не по именам. В колонке field_17 в старой таблице легко может оказаться что-то вроде паспортных данных, тогда как колонка с красивым именем passport пуста с 2019 года. Автоматический классификатор, который смотрит на заголовки, найдет passport и пропустит field_17, а отвечать за утечку придется именно за field_17. Для каждого поля нужно выяснить: какой там тип данных, сколько пустых значений – и отдельно пустых строк. Это не одно и то же, и разница между ними ломает код чаще, чем кажется. Ещё считаем количество уникальных значений и полезно собрать топ-20 из них, чтобы посмотреть их суммарную долю – так сразу видны перекосы в распределении. Вместо средней длины строки нагляднее строить гистограмму распределения длин. Что почти всегда всплывает и портит планы? Поля-помойки, где лежит и телефон, и адрес, и переписка с юристом. Справочники, которые внезапно оказываются ПД: к примеру, контрагенты, где половина записей – ИП, а ИП это физлицо с ФИО в названии. И косвенные идентификаторы: номер офиса, дата открытия счёта и сумма первого взноса (в небольшом городе этого достаточно, чтобы найти конкретного человека). Профилирование делаем внутри защищённого контура. Наружу выносим только агрегаты. Никаких «выгрузим немного, посмотрим глазами» – с этой фразы часто начинается утечка тестовых данных. Инструменты: ydata-profiling для быстрого старта, Great Expectations или Soda для повторяемых проверок, обычный SQL на ClickHouse для больших таблиц – он быстрее любой библиотеки. Для поиска персональных данных из коробки – «Гарда Data Masking» с машинным обучением: на старых схемах с полями f_01…f_88 это экономит недели. Метрика готовности к следующему шагу – доля полей с подтверждённой классификацией. Если меньше 95%, дальше идти бессмысленно: вы просто перенесёте неизвестность на следующий этап и найдёте её в проде. Да, скучно. Да, две-три недели. Обойти нельзя – я пробовал трижды. Шаг 2. Зачем нужен контракт на данные и что в нём должно быть? Дальше то, что вас защитит от того, чтобы проект не превратился в бесконечную переписку. Нужен документ – контракт на данные, который отвечает на вопрос: какой датасет мы считаем правильным. Пишет его потребитель, а не тот, кто генерирует. Это принципиально: если контракт пишет генератор, он напишет то, что умеет. Формат – YAML в репозитории рядом с кодом, чтобы версионировался и проходил ревью.  # contracts/acquiring_load.yaml dataset: acquiring_load_4tb purpose: performance # одна из четырёх задач, не «универсальный» owner: perf-team source_profile: profiles/acquiring@2026-07-14.json volume: rows: 1_300_000_000 size_tb: 4.1 tolerance: 0.03 must_preserve: cardinality: merchant_id: { value: 41_000, tol: 0.05 } card_token: { value: 78_000_000, tol: 0.05 } skew: merchant_id: { gini: 0.81, tol: 0.03 } partitions: last_90d_share: { value: 0.70, tol: 0.02 } nulls: mcc: { value: 0.031, tol: 0.005 } string_length: merchant_name: { mean: 34.2, p95: 61, tol: 0.10 } must_not_contain: [ real_pan, real_msisdn, real_fio, real_contract_no, real_inn ] edge_cases: # ссылки на каталог патологий, см. шаг 6 include: [ EC-014, EC-021, EC-088, EC-102, EC-137 ] min_occurrences: 200 privacy_gates: exact_row_match: 0 dcr_p5: ">= holdout" mia_auc: "<= 0.55" reproducibility: seed: 20260901 generator_version: "2.3.1" lifecycle: ttl_days: 14 storage_class: restricted-test Выглядит как бюрократия, а работает как страховка: через полгода на вопрос, почему у вас сорок одна тысяча мерчантов, а не двенадцать, ответит конкретный файл, а не уволившийся коллега по памяти. Три поля, которые все норовят выкинуть и потом жалеют: seed, ttl_days и min_occurrences. Шаг 3. Как подобрать генератор для каждого типа данных? Главное не то, какой генератор выбрать. Правильный вопрос: какой из генераторов подходит каждой группе полей. В типичной корпоративной базе примерно 80% данных спокойно генерируются правилами, ещё 15% требуют статистики, и только оставшиеся 5% – те, ради которых и нужна нейросеть. Разбивка по группам полей Что генерируем Чем Почему именно так Инструменты Первичные и внешние ключи, токены Детерминированные функции: HMAC-SHA256, формат-сохраняющее шифрование FF1 Нужна воспроизводимость и согласованность между системами. Нейросеть здесь не нужна и опасна: она может «запомнить» реальный идентификатор pgcrypto, библиотеки FF1, собственный сервис идентичности Форматные атрибуты РФ: ИНН, СНИЛС, БИК, номер карты Правила с корректными контрольными разрядами Валидаторы на входе отбракуют всё остальное, и вы будете тестировать не систему, а свой генератор Собственные функции, Faker(ru_RU), Mimesis — с обязательной доработкой Числовые и категориальные поля с зависимостями Гауссовы копулы, CTGAN, TVAE Ловят совместное распределение и корреляции. Копула часто не хуже GAN и в десятки раз быстрее — начинайте с неё SDV (GaussianCopula, CTGAN, TVAE), synthpop в R Цепочки событий: транзакции, сессии, статусы заявок PAR из SDV, DoppelGANger, либо марковская цепь + распределение интервалов Порядок и интервалы важнее значений. В восьми случаях из десяти марковской модели достаточно, а стоит она в пятьдесят раз дешевле SDV PARSynthesizer, свои реализации на NumPy Свободный текст: обращения, комментарии, протоколы Локальная LLM с жёсткими ограничителями и пост-фильтрами Единственное место, где без нейросети правда никак. И единственное, где реален риск дословного запоминания Self-hosted модели с русским языком; для деидентификации — NER: Natasha, DeepPavlov, Presidio Ссылочная структура между таблицами Обход графа FK сверху вниз, генерация родителей раньше детей Многотабличные синтезаторы формально не гарантируют целостность — это известная проблема, проверяйте руками SDV HMASynthesizer + собственные проверки, K2view и подобные — в коммерческом сегменте Справочники: ОКВЭД, регионы, валюты, МСС Копируем как есть Это не персональные данные. Синтезировать их — вредительство: сломаете join и потратите неделю на отладку — Шаг 4. Чем кормить генератор, чтобы синтетика была похожа на реальные данные? Правило одно: модель учится там же, где живут исходные данные. Тот же контур, тот же уровень защиты, те же журналы доступа. Наружу выходит только готовая модель – и только после проверки на утечку. Дальше 4 вещи, о которых редко пишут, хотя именно они всё решают. Размер обучающей выборки. Для табличной модели хватает 1-5 млн строк. Больше – модель дольше учится и легче запоминает конкретные записи. Казалось бы, чем больше данных, тем лучше, но здесь всё наоборот. Дедупликация обязательна. Дубликаты и почти-дубликаты – главная причина, по которой модель запоминает данные вместо того, чтобы их обобщать. Используем MinHash или SimHash, порог схожести 0,8, всё лишнее убираем. На одном проекте только это снизило долю протекающих записей в 10 раз. Канарейки – дешёвый и очень полезный приём. Перед обучением вшиваем в выборку 300–1000 искусственных записей с редкими сочетаниями: необычная фамилия, редкий диагноз, точная дата. После генерации ищем их в результате. Нашли хоть одну – модель течёт. Не нашли – гарантии нет, но зато есть дешёвый сигнал, который можно запускать в CI каждый день. Дифференциальная приватность. Честно: для внутреннего контура обычно избыточна. При ε ≤ 1 хвосты распределения вымываются, а именно ради хвостов всё и затевалось. Ещё один неприятный эффект: на синтетике с дифференциальной приватностью статистические тесты массово выдают ложноположительные результаты – аналитик принимает добавленный шум за значимый эффект. Если данные уходят за периметр, дифференциальная приватность нужна. Если остаются внутри – почти наверняка обойдётесь без неё. Шаг 5. Терабайты синтетики:  двухконтурная схема, без которой ничего не получится Смотрите, в чём суть. Нейросеть даёт структуру, а не объём. Если попытаться прогнать миллиард строк напрямую через CTGAN, выйдет как возить щебень на велосипеде: вроде технически можно, но смысла нет. Вот цифры для примера. Глубокая табличная модель на нормальной видеокарте делает десятки тысяч строк в секунду. Значит, миллиард – это несколько дней непрерывной работы, и всё это время видеокарта занята. А копула или обычный сэмплер на Spark и ClickHouse выдают миллионы строк в секунду с одной машины, и масштабируются они линейно. Разница – три-четыре порядка. Поэтому нужно два контура: первый, медленный, учит модель; второй, быстрый, размножает результат по требованию. КОНТУР А — медленный. Раз в квартал или при дрейфе данных. Внутри защищённого периметра Срез прода 1–5 млн строк после дедупликации Профилирование кардинальность, skew, NULL, длины Обучение копула / CTGAN / TVAE / LLM Эталонный корпус 5–20 млн строк полная валидация СЛЕПОК параметры распределений, условные таблицы, словари, хеш + версия Наружу выходит только слепок — и только после прохождения ворот приватности ↓ КОНТУР Б — быстрый. По кнопке, минуты. Обычный тестовый контур, никаких ПДн Слепок + seed + контракт на данные Правила и ключи Каталог патологий Справочники as is РАЗМНОЖИТЕЛЬ Spark / ClickHouse, N воркеров по диапазонам Перемешивание Загрузка в СУБД Ворота качества 4,1 ТБ за 4 часа на 8 воркерах Теперь о самом размножителе. Тут главное – предсказуемость. Если заданы три параметра: слепок модели, seed и диапазон номеров строк, результат будет один и тот же всегда. За счёт этого каждый воркер генерирует свой кусок сам, без общего состояния и координации, в результате сходится побайтово. -- ClickHouse: скелет размножителя. Zipf по мерчантам через словарь весов, -- детерминированный PRNG от (seed, номер строки) INSERT INTO tx_synth SELECT cityHash64(:seed, n) AS rid, dictGet('merchant_zipf', 'merchant_id', toUInt64(zipf_bucket(rid))) AS merchant_id, dictGet('card_pool', 'token', toUInt64(rid % 78000000)) AS card_token, -- 70% объёма — в последние 90 дней, как в проде now() - toIntervalSecond( if(rid % 100 < 70, rid % 7776000, 7776000 + rid % 86400000)) AS ts, -- логнормаль по суммам + магнит на круглые значения round_magnet(exp(4.1 + 0.92 * randNormal(rid))) AS amount, if(rid % 1000 < 31, NULL, dictGet('mcc', 'code', rid % 400)) AS mcc FROM numbers_mt(:row_from, :row_count) И три тонкости, которые я узнал через сломанный нагрузочный тест Физический порядок вставки. Сгенерируете данные по возрастанию ключа – и получите идеальную локальность: соседние строки похожи, страницы сжимаются гораздо лучше, индексы плотные. Четыре терабайта прода на стенде превратятся в полтора, всё уляжется в кэш, и нагрузочный тест покажет чудесные цифры. Но в проде данные приходят вперемешку. Поэтому перед загрузкой перемешивайте их, хотя бы блоками по несколько миллионов строк. Одна строчка кода – а на диске разница вдвое. Длина строк и доля пустых значений. Две скучные метрики, но обе работают. В проде merchant_name в среднем 34 символа, а генератор выдаёт 12 – таблица становится меньше в два с половиной раза. В проде 3,1% пустых значений в MCC, а у вас ноль – не словите ни одного падения на пустом поле и заодно получите другой размер строки в колоночном хранилище. Сколько вообще нужно терабайт. Спорно, но я настаиваю: большинству команд терабайты не нужны. Они нужны только нагрузочникам и тем, кто отлаживает планы запросов на больших таблицах. Остальным хватает правильного среза: 2–3% от прода с сохранением ссылочной целостности покрывают примерно 95% функциональных сценариев, генерируются за минуты и влезают на ноутбук. Когда каждая команда просит полную копию, это не потребность в данных, а недоверие к срезу. Лечится контрактом из шага 2, а не терабайтами. Шаг 6. Что такое каталог патологий и зачем его вести? Теперь самое важное во всей статье. Если дальше не осилите – прочитайте хотя бы этот подраздел. Генеративная модель по своей природе сглаживает редкие случаи. Это не дефект реализации, а её работа: она учитывает плотность распределения, а нестандартные события по определению имеют низкую плотность. GAN вдобавок склонен схлопывать моды, VAE – размывать. Аналитику, которому нужны среднее и корреляции, это не мешает, а вот для тестировщика – это катастрофа, потому что баги живут именно в хвостах. Ни один известный мне генератор сам не придумает клиента с 412 картами, платёж на одну копейку, ФИО длиной 78 символов и транзакцию ровно в момент перевода часов. А в проде всё это есть, и на каждом из этих случаев кто-то однажды упал. Отсюда гибрид: тело распределения даёт нейросеть, хвосты – отдельный каталог. Каталог патологий – это структурированный список редких случаев: идентификатор, описание, ссылка на инцидент, целевая доля в датасете. Источников четыре: Багтрекер за два-три года: выгрузите все дефекты, где в описании есть слова про данные, формат, пустое значение, длину или кодировку – это золотая жила. Постмортемы инцидентов прода: каждый инцидент, вызванный данными, обязан превратиться в запись каталога; это дисциплина, а не техника. Ограничения схемы: для каждого CHECK, NOT NULL и лимита длины нужны значения на границе и за ней. И наконец, сядьте и подумайте, как бы вы ломали свою систему, если бы вам за это платили. Фрагмент каталога патологий ID Класс Патология Что ловит EC-014 ФИО Фамилия из одной буквы; фамилия 78 символов; двойная через дефис; отчество «оглы»/«кызы»; «ё» и «е» в одной записи; висячий пробел в конце Обрезка полей, сортировки, поиск, ширина в отчётах и печатных формах EC-021 Даты и время 29 февраля; 31-е в 30-дневном месяце; дата рождения 1900 и завтрашняя; переход на летнее время в исторических данных до 2014; Камчатка (+12) и Калининград (+2) в одной таблице Расчёт возраста, дедлайнов, SLA, ночные джобы, оконные функции EC-034 Суммы 0,01; максимально допустимая; отрицательная; четыре знака после запятой; ровно на пороге лимита; банковское округление половин Переполнения, округления, лимиты, сверки на копейку EC-088 Кардинальность Клиент с нулём продуктов; клиент с 412 картами; мерчант с одной транзакцией за три года; мерчант с 30% всего трафика Пагинация, N+1, таймауты, планы запросов, деление на ноль в агрегатах EC-102 Текст и кодировки Пустая строка против NULL; строка из одних пробелов; эмодзи; кавычки-ёлочки; неразрывный пробел; CRLF внутри поля; апостроф в «О’Коннор» Парсинг, экспорт в CSV, интеграции, экранирование, ширина в UI EC-137 Дубли и грязь Полные дубли строк; два клиента с одинаковым ИНН; запись со всеми NULL кроме ключа; «висячая» ссылка на удалённый справочник Дедупликация, идемпотентность, отчёты, целостность витрин Про доли – это важнее, чем кажется Мой ориентир такой: на каталог уходит 0,3–1% строк датасета, но каждый класс патологий должен встретиться минимум 200 раз. Если сделать патологий 5%, они перестанут быть хвостом и испортят нагрузочный профиль. А если каждого класса по три штуки на миллиард строк – тест превращается в лотерею: сегодня запрос их зацепил, завтра нет, и полдня уходит на то, чтобы разобраться, почему сборка мигает. Шаг 7. Что мешает синтетике сломать прод и зачем нужны три независимых проверки? Датасет, не прошедший валидацию, не публикуется. Точка. Ворота стоят в CI, у каждых – жёсткий порог из контракта. Приём, который экономит месяцы Лучший тест пригодности данных – не статистика, а сравнение планов запросов. Возьмите топ-50 запросов из pg_stat_statements или query_log, прогоните EXPLAIN (ANALYZE, BUFFERS) на проде и на синтетике, сравните типы узлов и отношение оценочной кардинальности к фактической. Планы совпали – данные годные, дальше можно не мерить. Не совпали – значит, сломали ровно одно распределение, и по расхождению оценок видно, какое. Я нахожу этим способом за час то, что статистическими метриками искал бы неделю. Ловушка DCR, в которую попадают почти все Расстояние до ближайшей реальной записи часто показывают как доказательство приватности: мол, ни одна синтетическая строка не совпадает с настоящей. Но само по себе это ни о чём не говорит. Сравнивать надо так: отложите часть реальных данных, которую модель вообще не видела, и посчитайте DCR для неё и для синтетики. Если синтетика оказывается ближе к обучающей выборке, чем этот холдаут – модель просто запоминает. Именно за эту ошибку критикуют половину опубликованных работ по синтетическим данным.  Вывод после второй части Эта часть была самой плотной с точки зрения практики. Давайте выдохнем и зафиксируем главное. Контракт на данные – это фундамент и страховка. Без него размножитель превращается в рулетку: сегодня данные одни, завтра другие, воспроизвести не получается, воркеры мешают друг другу. Поэтому сначала контракт, потом всё остальное. Не наоборот. Описанные шаги пропускать нельзя. Решили сэкономить и сразу направить нейросеть на прод – получите гладкое распределение без хвостов, а именно в хвостах живут баги. Решили пропустить валидацию – вот вам и датасет, который внешне похож на реальный, а на деле сломает половину планов запросов. Каждый шаг – это не рекомендация, а контрольная точка. В третьей части уже расскажу как всё это применять на реальных проектах. Поговорим о российской специфике, покажу 3 кейса из практики – где хорошая синтетика спасала прод, а плохая роняла его через 40 минут после релиза. Также вас будет ждать разбор инструментов и ошибок с прицелом на РФ. А ещё расчёт экономики для защиты бюджета и план на 90 дней по неделям.  Если на то, чтобы воплотить всё описанное в статье не хватает своей экспертизы – мы можем зайти и выстроить весь конвейер под ключ: от профилирования и контракта на данные до размножителя, каталога патологий, учёта регуляторных требований, валидации в CI, доставки по кнопке и масштабирования до терабайт. Приходите – разберём ваш контур и прикинем, что и за какой срок реально сделать. Первая консультация бесплатно.  Зачем вообще нужна синтетика, если есть маскирование? Маскирование сохраняет структуру реальных данных, но искажает значения. Проблема в том, что искажение почти всегда ломает распределения. Плюс маскирование юридически не выводит данные из-под 152-ФЗ, пока есть ключ обратимости. Что такое детерминированный размножитель? Это функция от трёх аргументов: слепка распределений]]> https://quality-lab.ru/blog/7-shagov-k-konvejeru-sinteticheskix-dannyx-dlya-testirovaniya/ Wed, 23 Sep 2026 11:49:05 +0300 Меня зовут Владислав Тимашенков, я занимаюсь автоматизацией тестирования в ГК InfoWatch. Мы разрабатываем DLP-систему для защиты контента и предотвращения утечек информации. Специфика продуктов InfoWatch состоит в анализе самых разнообразных данных. Поэтому практически каждый автотест требует подхода с широким набором параметров. Для нашей команды хорошим решением стало вынести генерацию параметров pytest.mark.parametrize в отдельный компонент, который собирает данные из файловой коллекции проекта. Существует множество способов параметризировать тестовые функции. Эта статья — пример изящной параметризации Pytest для сценариев, основанных на файловой коллекции проекта с большим количеством данных. Расскажем про наш опыт решения такой задачи. Параметризация Pytest позволяет сделать из теста каркас, шаблон, который принимает данные для конфигураций, для assert и т.д. ]]> https://www.software-testing.ru/library/testing/testing-automation/4538-parameterization-of-pytest Tue, 22 Sep 2026 23:00:00 +0300 Автор: Джеймс Бах (James Bach) Оригинал статьи Перевод: Ольга Алифанова В противовес моей идее о том, что тестирование программного обеспечения должно быть ролью, а не просто задачей, мне иногда говорят, что «настоящий Agile» этого не допускает. Почему? Потому что в Agile «качество — ответственность каждого». Это утверждение иногда подаётся так, будто это моральная истина, не подлежащая обсуждению, или же как моральное достижение, уникальное для аджайлистов, будто предыдущим поколениям разработчиков программного обеспечения никогда не приходило в голову помогать друг другу создавать хорошие вещи. В любом случае, для меня это не имеет смысла. Первая мысль, которая приходит в голову: «Я говорю о тестировании, а не о качестве. Почему сюда притягивается качество?» Тестировщики не обеспечивают качество. Тестировщики НЕ МОГУТ обеспечить качество. Тестировщики сейчас и никогда не «владели качеством» ни в каком смысле. Но даже если отложить это в сторону, качество не должно считаться «ответственностью каждого». Вот почему меня беспокоит эта формулировка: ]]> https://www.software-testing.ru/library/around-testing/processes/4504-everyone-is-not-responsible-for-quality Sun, 20 Sep 2026 23:00:00 +0300 Что такое синтетические данные? Синтетические данные для тестирования – это данные, которые создают искусственно, чтобы они вели себя как настоящие: повторяли распределения, пропорции, редкие и крайние случаи, но не содержали персональных данных реальных людей. Они нужны для четырех разных задач – нагрузочного тестирования, регресса, обучения моделей и демо. Подход зависит от задачи: где-то хватит пяти тысяч строк на фикстурах, где-то нужен конвейер генерации 4 ТБ с проверкой по статистике, планам запросов и приватности. Юридическая сторона при этом определяет стоимость. Маскирование с обратимым ключом остается персональными данными по 152-ФЗ1. Синтез выводит данные из-под закона, только если доказано, что связь с реальными людьми отсутствует, – с 1 сентября 2026 года это проверяется по национальным стандартам ПНСТ 1064–10662. Наш ведущий эксперт Олег подготовил цикл из трех материалов, в которых пошагово рассказывает, как построить конвейер, который выдает обезличенные данные в промышленных объемах, и как убедиться, что они не врут. Никакой магии – только метрики, пороги и грабли, на которые он уже наступал. Полезно для руководителей разработки и QA, продакт-менеджеров и всех, кто работает с тестовыми данными. Публикуем первую часть, речь в которой пойдет о стратегии и границах. Вы узнаете, какие бывают тестовые данные, насколько реалистичными их можно делать и что по этому поводу говорит закон. Понедельник, планерка. Тестировщик разводит руками: у меня не воспроизводится, на моих данных все зеленое. Аналитик говорит, что у него выгрузка трехмесячной давности и новых статусов заявки там еще нет. Нагрузочник молчит – у него стенд на 40 ГБ против 6 ТБ прода, и он давно перестал верить собственным графикам. А безопасник в этот момент пишет письмо о том, что дамп боевой базы опять оказался на ноутбуке подрядчика. Если у вас такого никогда не бывало – вы либо совсем маленькие, либо уже очень взрослые. В обоих случаях дальше можно не читать. Я лет десять кручусь вокруг тестовых сред, и первые года три делал ровно то, что делают все: выгружал из прода двести тысяч строк, менял фамилии на Иванов1, Иванов2 и так далее, и считал, что обезличил. Пока не заметил, что в выгрузке остались номера договоров. А по номеру договора на нашей же публичной форме проверки статуса доставался город и последние четыре цифры телефона. Это был не взлом – это была форма на сайте, которую мы сами и сделали. Мне повезло, что очень быстро именно я нашел ее первым. С тех пор я отношусь к тестовым данным как к проду: с той же паранойей и тем же уровнем проектирования. Ниже – методология, которой хватает и на регресс из 5 000 строк, и на нагрузочный контур в 4 ТБ. Пара цифр для контекста, чтобы было понятно: проблема не выдуманная. По опросу «Гарды»3 среди российских компаний специализированные средства маскирования применяют около 3% респондентов, почти половина регулярно переносит в тестовые среды копии продуктивных баз без изменений, а 18,8% держат тестовые базы в том же кластере, что и боевую. При этом с 30 мая 2025 года по 420-ФЗ4 утечка данных 1 000–10 000 человек стоит юрлицу от 3 до 5 млн рублей, а повторная – от 1 до 3% годовой выручки, минимум 25 млн. Это уже не риски информационной безопасности, это строчка в P&L. Какие задачи решает создание тестовых данных и чем они отличаются? Самая дорогая ошибка здесь скрывается на старте, и стоить она может около 6 месяцев бесполезной работы. Звучит так: давайте сделаем нормальные тестовые данные, но без уточнения, для чего. Я вам расскажу про четыре основных задачи с несовместимыми требованиями, которые могут прятаться за таким расплывчатым запросом. Данные, отличные для регресса, бесполезны для нагрузочного тестирования, а данные, на которых обучается скоринг, не подойдут для демо партнеру. И наоборот. Обязательно прочитайте, чтобы не пойти по ложному направлению с самого начала, так как переделывать будет очень дорого. Четыре задачи создания тестовых данных Задача Что критично воспроизвести Чем можно пожертвовать Типичный объём Основной метод Функциональное и регресс Покрытие состояний и переходов, ссылочная целостность, валидность форматов, наличие всех справочных значений Реальные пропорции. Хоть 50/50 — лишь бы все ветки были 100 МБ – 20 ГБ Правила + подмножество прода Нагрузочное и производительность Кардинальность, скошенность, корреляции, доля NULL, длина строк, распределение по партициям, физический порядок вставки Осмысленность конкретных значений — планировщику всё равно, «Петров» там или «Ыфвап» 0,5 – 50 ТБ Статистика + масштабирование Обучение и валидация моделей Совместное распределение, редкие классы, временна́я динамика, сезонность, дрейф Точное соответствие форматам систем-источников 1 ГБ – 5 ТБ Нейросетевой синтез Демо, обучение людей, песочницы Правдоподобие «на глаз», связность историй, приличные ФИО и адреса Статистика вообще. Никто её не проверяет 10 МБ – 5 ГБ Правила + LLM Девять из десяти компаний говорят одно и то же: нам нужны тестовые данные. Я на проекте сразу собираю всех и прошу разложить по таблице, кому что нужно. Почти всегда оказывается, что спорили люди о разных вещах.  Мой любимый антипаттерн: команда полгода строит пайплайн на CTGAN, покупает видеокарты, а нужны были пять тысяч строк для регресса, где важно только одно – чтобы у клиента было от нуля до семи карт. Это делается за два дня на фикстурах. Бывает и наоборот, и это дороже: под нагрузочное тестирование берут данные, сделанные для демо. Чем это кончается – обязательно расскажу на примере кейсов в третьей статье цикла. Был случай, когда p99 на стенде отличался от прода в двадцать три раза. Что делать прямо сейчас? Соберите всех, кто работает с тестовыми данными, и попросите каждого назвать одну метрику, по которой он поймет, что данные плохие. Не общие слова про реалистичность, а конкретно: доля отказов по эквайрингу – 2,8% ± 0,3. Если человек не может назвать такую метрику – значит, у него не требования, а ощущения. А ощущения меняются каждый спринт, работать с ними нельзя. Что такое синтетические данные и какие уровни реалистичности бывают? Часто синтетические данные понимают, как что-то одно, а на самом деле это целый спектр от пустых заглушек с правильными типами полей до почти полной копии прода. И кстати, чем ближе к копии, тем больше от них толку – но тем рискованнее с точки зрения утечек. Это не баг технологии, так устроено само явление. Британское статистическое ведомство (ONS)5 предложило шкалу из шести уровней – самую вменяемую из тех, что я видел. Подготовил для вас удобную таблицу и добавил от себя столбец «для чего годится»: в оригинале его нет, но так нагляднее и полезнее. Шкала ONS: шесть уровней синтетических данных № Уровень Что воспроизводится Для чего реально годится Риск раскрытия 1 Структурная Только схема: типы, длины, обязательность. Значения — шум Прогон миграций, проверка сборки, smoke нулевой 2 Валидная Плюс бизнес-правила и ограничения: контрольные суммы, диапазоны, FK Функциональные тесты, интеграции, автотесты API нулевой 3 Одномерная Плюс маргинальные распределения каждого поля по отдельности Первые прикидки по объёму, отчёты «на глаз» низкий 4 Многомерная Плюс совместные распределения и корреляции между полями Нагрузочное тестирование, витрины, BI-регресс умеренный 5 Дополненная правдоподобная Плюс тонкая структура: сезонность, редкие классы, поведенческие цепочки Обучение моделей, антифрод, аналитические гипотезы заметный 6 Реплика Практически замещает реальные данные в анализе Исследования и публикации — и только с формальными гарантиями высокий Уровень выбирается под задачу из первой таблицы, а не под амбиции команды. Для регресса хватает второго, для нагрузочного тестирования нужен четвертый, для машинного обучения – пятый. Шестой в корпоративной практике почти никогда не нужен. Если его продают под тестирование – продают лишний риск. Ошибка из практики Как-то раз мы сделали для нагрузочного стенда пятый уровень – просто потому что могли. Через месяц пришел безопасник и спросил: на каком основании данные пятого уровня лежат в контуре, куда имеют доступ двенадцать подрядчиков? И был прав. Мы потом три недели доказывали, что из этих данных невозможно вытащить реальных людей. А по задаче вполне хватало четвертого уровня и недели работы. Вывод простой: лишнее качество синтетики не всегда оправдано. Ты берешь на себя лишний риск – и потом за него отвечаешь.  Маскирование, псевдонимизация и синтез – чем они отличаются с юридической точки зрения? Этот раздел я проговариваю с юристом и безопасником на первой же встрече – от него зависит стоимость всего проекта. Разница между тремя подходами не техническая, а правовая. И путают их постоянно.  Маскирование с обратимым ключом – это псевдонимизация. Вы заменили фамилию на код, а ключ положили в хранилище. Субъекта вроде не определить – но только пока ключа нет. А он есть. Значит, это по-прежнему персональные данные, тестовый контур остается ИСПДн со всеми требованиями к защите, и штрафы за утечку из него ложатся на вас. Обезличивание регулируется жестко. С 1 сентября 2025 года действует приказ Роскомнадзора № 140 от 19.06.20256 – он заменил прежний № 996 от 2013 года. Методы в целом те же: идентификаторы, изменение состава и семантики, перемешивание, декомпозиция – плюс добавился новый метод преобразования массива. Но важнее методов требования к самому процессу, а их как раз редко кто читает. Что требует приказ № 140 и что из этого ломает привычную практику: Нельзя хранить обезличенные данные вместе с исходными. Схема, когда в одной базе рядом лежат clients и clients_masked, – вне закона. А так делают почти все. Ключ соответствия хранится отдельно и третьим лицам не передается. Подрядчик по нагрузочному тестированию – это третье лицо. Локальные акты о методах обезличивания и о применяемых системах не должны быть доступны третьим лицам. То есть описание вашего пайплайна маскирования само по себе – чувствительный документ. Ведется учет всех действий. Каждая выгрузка сопровождается журналом. Синтез – совсем другое дело. Вы не переделываете записи реальных людей, а создаете новые. Нет записи, которая соответствует конкретному человеку, – нет и персональных данных. Но это нужно доказывать, а не просто заявлять. И тут стало проще. Росстандарт выпустил первые стандарты по синтезу данных – их подготовила Ассоциация больших данных. Три документа: ПНСТ 1064-2026 – основные понятия и термины, ПНСТ 1065-2026 – архитектура и методы синтеза, ПНСТ 1066-2026 – оценка качества результатов. Действуют с 1 сентября 2026 года, то есть уже сейчас. Там наконец-то есть то, чего не хватало: как оценить достоверность, как измерить риск восстановления исходных данных, как валидировать, как маркировать и аудитировать. На практике вывод простой: сама фраза про синтетические данные больше ничего не доказывает. Безопасники не будут спрашивать, уверены ли вы – они захотят увидеть отчет по качеству. И это хорошо: наконец-то можно перестать спорить о вкусах и говорить на языке цифр. А как с этим обстоят дела за рубежом? Если нужно обосновать подход для зарубежной части группы, логика везде одна: смотрят не на название метода, а на остаточный риск повторной идентификации. GDPR7 (соображение 26) и заключение WP29 05/20148 требуют закрыть три риска – выделение записи, связывание и вывод атрибута. Остался хоть один – это уже не анонимизация. Самый практичный документ – NIST SP 800-1889, финальная редакция от сентября 2023. Там же описаны совет по проверке раскрытия и тест мотивированного нарушителя. В HIPAA10 две дорожки: удалить 18 атрибутов из списка или провести экспертную оценку риска. Российская практика по факту дрейфует ко второй. Отдельная работа для всех, кому синтетику продают как серебряную пулю: Stadler, Oprisanu, Troncoso, Synthetic Data – Anonymisation Groundhog Day, USENIX Security 202211. Вывод неудобный: сама по себе синтетика не дает лучшего баланса между приватностью и полезностью, чем классическая анонимизация. Либо теряете полезность, либо защищаете не все записи, а предсказать заранее, где окажетесь, трудно. Отсюда единственный рабочий вывод: не верить, а измерять. Еще две цифры на случай, если кто-то думает, что убрал ФИО и теперь безопасно. Латания Суини12 еще в девяностых показала: около 87% американцев однозначно определяются по связке индекса, даты рождения и пола. Rocher, Hendrickx и de Montjoye в Nature Communications за 2019 год оценили13, что 99,98% американцев можно переопределить по пятнадцати демографическим атрибутам, причем даже на сильно прореженных выборках. Пятнадцать атрибутов есть в любой таблице клиентов. Шесть способов получить тестовые данные Подход Обратимость Статус по 152-ФЗ Ссылочная целостность Годится для нагрузки Трудозатраты на старте Копия прода «как есть» — ПДн в полный рост идеальная да нулевые Маскирование с ключом (FPE / HMAC) есть ПДн (псевдонимизация) сохраняется да низкие Обезличивание по приказу № 140 частичная обезличенные ПДн, ст. 13.1 требует усилий частично средние Синтез без формальных гарантий нет не ПДн — если доказано нужно проектировать да высокие Синтез с дифференциальной приватностью нет не ПДн, с гарантией нужно проектировать хвосты умирают очень высокие Гибрид: правила + синтез + каталог патологий нет не ПДн — если доказано проектируется явно да, лучше всех средние На чем в итоге сходится большинство зрелых команд: нейросеть отвечает за структуру; правила – за форматы и ключи; каталог патологий – за редкие и проблемные случаи. Про дифференциальную приватность скажу отдельно: она нужна, когда данные уходят наружу, и почти никогда – когда остаются внутри вашего контура.  Главный вывод первой части Закон не запрещает работать с тестовыми данными – он запрещает работать с ними небрежно. Граница между псевдонимизацией, обезличиванием и синтезом не техническая, а правовая, и цена ошибки здесь не часы переделки, а оборотные штрафы и репутация. Приказ Роскомнадзора № 140, стандарты Росстандарта по синтезу, требования GDPR и HIPAA – все сходится в одном: документально доказанный остаточный риск повторной идентификации. Не название метода и не уверенность на совещании, а отчет, который можно положить на стол аудитору. Во второй части разберем практику. Семь шагов запускка конвейера данных – от инвентаризации, которую все хотят пропустить, до тройных ворот валидации. Расскажу, как собрать двухконтурную схему для терабайтных объемов, почему нейросеть отвечает за структуру, а правила – за контрольные суммы и хвосты. В третьей части поделюсь тремя историями из практики с разбором ошибок. Расскажу, что делать с российской спецификой и какой стек инструментов актуален для нашей страны: от открытых библиотек до коробочных решений. А еще поговорим о деньгах: покажу, как сделать расчет экономики, который убеждает финансистов, и дам честный порог, ниже которого весь этот конвейер просто не нужен. Мы в «Лаборатории качества» во время аудитов находим в среднем от двух до пяти проблем в тестовых контурах, о которых команды заказчиков даже не подозревали. Иногда это забытая выгрузка с реальными телефонами, иногда – маскирование, которое юридически не обезличивает ничего. Хотите узнать, все ли на вашем проекте в порядке? Запишитесь на бесплатную консультацию. Разберем ваш кейс и ответим на вопросы.  Вопросы и ответы Чем отличаются тестовые данные от боевых? Боевые данные – это реальные записи людей и организаций, используемые в продуктиве. Их утечка влечет штраф по 152-ФЗ до 1–3% выручки (мин. 25 млн руб к повторной утечке спец категорий и биометрии, для общих данных минимум – 20 млн). Тестовые данные нужны для отладки и нагрузочного тестирования. Они не являются персональными данными, так как не позволяют идентифицировать субъекта, и для работы с ними не требуют прохождения процедур ИСПДн, если они получены синтетическим путем. Можно ли тестировать на копии продакшн-базы? Копия базы продакшена содержит персональные данные и подпадает под действие 152-ФЗ. По Приказу Роскомнадзора № 140 хранить исходные и обезличенные данные в одной системе запрещено. Передача копии базы подрядчику или выгрузка в незащищенный тестовый контур незаконны. Чтобы тестировать на копии, необходимо предварительно провести полное обезличивание или псевдонимизацию с выносом ключей в отдельное защищенное хранилище. Что такое синтетические данные и чем они отличаются от маскирования? Маскирование подменяет значения в реальных записях, сохраняя связь с реальным субъектом. Ключ обратимости означает, что данные остаются персональными. Синтез генерирует новые, вымышленные записи на основе статистических паттернов оригинала. Связи с реальным человеком нет, поэтому данные не являются ПДн. Но отсутствие утечки необходимо подтверждать: по стандартам ПНСТ 1064-1066 предоставляется отчет об оценке качества и остаточного риска приватности. Чем маскирование отличается от обезличивания по закону? Маскирование с сохранением обратимого ключа – это псевдонимизация. Данные остаются персональными по 152-ФЗ, а система – ИСПДн. Обезличивание по Приказу Роскомнадзора № 140 – это необратимое преобразование, когда личность нельзя установить ни при каких условиях. Оно требует строгого раздельного хранения исходных и преобразованных данных и ведения учета каждой выгрузки, так как полностью выводит данные из-под ответственности оператора ПДн. ]]> https://quality-lab.ru/blog/sinteticheskie-dannye-dlya-testirovaniya-metodologiya-masshtab-i-kontrol-privatnosti/ Fri, 18 Sep 2026 11:31:00 +0300 Автор: Пономарева Анастасия Недавно знакомый PM попросил рассказать «Что значит отвечать за качество?» в контексте продуктовых команд. Вопрос оказался не из простых, ведь каждый проект имеет свои особенности. Да и понятие качества может отличаться. Ниже — мой взгляд на тему через призму измеримых показателей. Если у вас есть дополнения, другие метрики или иной управленческий опыт — велкам в комментарии. Будет интересно обсудить и расширить картину. Начну немного издалека. Последние лет пять тема продуктовых команд очень популярна. Тестировщиков из «колодцев» и подчинения QA лидам и хэдам забирают в команды. Если сначала было матричное управление с функциональным руководством, то последние годы растет тренд на отказ от QA лидов с передачей функции лидам продуктовых команд. ]]> https://www.software-testing.ru/library/around-testing/management/4536-responsible-for-quality Tue, 15 Sep 2026 23:00:00 +0300 Автор: Филип Рик (Filip Hric) Оригинал статьи Перевод: Ольга Алифанова Никто не любит переключаться между контекстами, и я не исключение. Когда я глубоко погружён в работу, то обычно записываю заметки где-нибудь сбоку и продолжаю работать. Но после завершения сессии концентрации обычно приходится сталкиваться со скучной и длительной задачей — переносить эти заметки в систему тикетов, чтобы команда могла обработать обратную связь по продукту и баг-репорты. И поскольку мне нравится автоматизировать свои проблемы, я решил упростить это с помощью инструментов, которые пробовал в последнее время. Покажу, как использовал Goose, Playwright MCP и их новое расширение Playwright MCP Bridge для Chrome, чтобы автоматизировать скучную задачу создания множества тикетов во внутренней системе отслеживания задач. ]]> https://www.software-testing.ru/library/testing/testing-automation/4507-goose-and-playwright-mcp Sun, 13 Sep 2026 23:00:00 +0300 Когда заказчик просит «посмотреть сайт свежим взглядом» и заказывает анализ юзабилити, он часто ожидает услышать про цвета, шрифты или расположение кнопок. Но важно понимать: внешность сайта — это лишь интерфейс (UI). А настоящий юзабилити-аудит (UX) охватывает намного больше факторов и показателей. И его цель – проверить, соответствует ли интерфейс ментальной модели пользователя и решает ли он бизнес-задачи. К примеру, если предприниматель заходит на B2B-сайт франшизного проекта, он ожидает увидеть цифры, сроки окупаемости и юридическую прозрачность. Если вместо этого он видит развлекательный контент, это не «креатив». Это нарушение базового принципа соответствия системы реальному миру. И именно такие нарушения стоят бизнесу миллионов рублей упущенной прибыли. Решили поделиться интересным кейсом «Лаборатории качества». Мы провели комплексный UX-аудит сайта франшизы федеральной сети салонов для животных и выявили 19 критических ошибок и 29 точек роста. В этой статье мы разберем наш подход пошагово, опираясь на методологию экспертного анализа, чтобы показать, как данные и системный подход помогают находить проблемы, невидимые глазу. Команда и инструменты Аудит выполняли наши специалисты с опытом в B2B и юзабилити-анализе. Был использованы такой стек: Яндекс.Метрика (Вебвизор, карты кликов, воронки), инструменты автоматизированного тестирования, чек-листы по эвристикам Нильсена и методы когнитивного walkthrough. Такой микс компетенций и подбор команды позволил найти не только визуальные недочеты, но и скрытые технические и юридические риски. Шаг 1. Анализ Яндекс.Метрики: от цифр к гипотезам о поведении Прежде чем смотреть на дизайн, мы изучили данные за последние полгода (02.02.2026 — 02.08.2026). Цифры сами по себе не дают ответов, но они позволяют сформулировать точные гипотезы о том, где и почему пользователи теряются. Картина была противоречивой: трафик рос (+20,7%), но конверсия падала (-0,42%). Доход по целям сократился на 6,93%. Это классический сигнал о том, что качество трафика или соответствие интерфейса ожиданиям аудитории ухудшилось. Какие гипотезы мы сформировали на основе данных Гипотеза 1: нерелевантный трафик из платных каналов. Канал Google Ads приносил 3 574 визита (9,4% всего трафика), но конверсия составляла всего 0,03%, а доход — 1 000 рублей. Для сравнения: органический поиск при меньшем объеме в 2,5 раза давал конверсию 9,3% и доход 167 500 рублей. Вывод: либо реклама настроена неверно, либо посадочная страница не соответствует ожиданиям аудитории из этого источника. Сайт «обманывает» ожидания кликнувших по объявлению, что подтверждается высоким показателем отказов (23,7%) и снижением времени на сайте на 10,55%. Примечание: В рамках данного аудита фокус был на основном проблемном канале, но рекомендация по аудиту распространяется на все платные источники. Гипотеза 2: первый экран не удерживает B2B-аудиторию. 44,8% пользователей уходили после просмотра одной страницы. При этом те, кто смотрел 2-3 страницы, имели конверсию 2%, а доскроллившие до отзывов и цифр — 8,9%. Эти пользователи приносили 66,1% всего дохода. Вывод: проблема не в продукте, а в подаче. Пользователи, которые преодолевают первый барьер и погружаются в факты, конвертируются отлично. Значит, нужно убрать барьеры на старте и дать им повод скроллить дальше. Гипотеза 3: основной инструмент лидогенерации работает против пользователя. Квиз был главным инструментом захвата лидов (26 700 просмотров, 4 837 запусков). Однако конверсия внутри него составила всего 3,5% (169 заявок). 80% пользователей открывали квиз, но не нажимали кнопку «Пройти». Еще 48% бросали заполнение формы контактов в самом конце. Вывод: стартовый экран квиза не продает ценность, а финальная форма вызывает недоверие или сложность. Инструмент, который должен генерировать заявки, фактически отсекает 96,5% потенциальных клиентов. Гипотеза 4: аудитория ищет бизнес-информацию, а получает развлечения. Ядро целевой аудитории — женщины 35-54 лет с долгосрочными интересами в финансах, бизнесе, красоте и здоровье. Они приходят за цифрами, сроками и гарантиями, так как должны понимать, во что им предлагают вкладывать инвестиции. Вывод: наблюдается полное несоответствие ментальной модели B2B-инвестора с B2C-развлечениями на сайте. Развлекательный контент создает когнитивный диссонанс и снижает доверие к бренду как к надежному партнеру для бизнеса. Итог этапа: проблема не в отсутствии трафика, а в несоответствии интерфейса потребностям аудитории и технических барьерах. Мы перешли от ощущения «что-то не так» к конкретным, измеримым гипотезам для проверки. Шаг 2. Экспертный анализ по эвристикам Нильсена: поиск ошибок и точек роста На этом этапе мы проверили сайт на соответствие базовым принципам юзабилити. Важно разделять найденное на ошибки (то, что ломает опыт) и точки роста (то, что можно улучшить). Нарушение принципа «Соответствие системы реальному миру» (ошибка) Сайт продавал сложную услугу для бизнеса (B2B), но вел себя как развлекательный портал для конечных потребителей (B2C). Ключевые баги: выдуманные персонажи-животные занимали 30% контента; кнопка с шуточным текстом вместо открытия формы скроллила страницу наверх. Пользователь терял позицию и раздражался; слайдер с примерами работ дублировал контент с сайта салонов и не нес ценности для инвестора. Нарушение принципа «Предотвращение ошибок» (ошибка) Формы захвата работали против пользователя, создавая ложное ощущение корректности. Ключевые баги: валидация полей показывала зеленые галочки при вводе невалидного телефона («+7 (2») и email («test»). Ошибка появлялась только после нажатия «Отправить»; при клике на выбор конкретного формата услуги в форме заявки всегда выбирался базовый вариант. Менеджеры получали некорректные лиды. Нарушение принципа «Видимость состояния системы» (ошибка) Пользователь не понимал, что происходит после его действий. Ключевые баги: после прохождения интерактивного теста ссылка на бонус вела в пустую папку облачного хранилища. Пользователь тратил время, оставлял контакты, но не получал обещанное. Это полностью обесценивало инструмент; все ссылки на «Политику конфиденциальности» вели на страницу 404 с креативной иллюстрацией. Для юридического документа это недопустимо. Точки роста (улучшения) Параллельно с поиском ошибок мы фиксировали возможности для усиления: добавить детальное описание паушального взноса и роялти (сейчас пользователь видит сумму, но не понимает состав); расширить FAQ с 3 до 8-10 вопросов для снятия возражений; оптимизировать блоки с персонажами: сократить количество шагов или изменить действие кнопок; удалить или переработать блок «Тип бизнеса» (абстрактная концепция, AI-изображения). Шаг 3. Когнитивный разбор сценариев: путь предпринимателя vs B2C-подход Мы смоделировали поведение типичного партнера (женщина 40 лет, ищет инвестиции, интересуется финансами) и сравнили его с тем, что предлагает сайт. Здесь мы анализировали когнитивную нагрузку: где возникает перегрузка, путаница или сомнения. Ожидание пользователя (Ментальная модель): «Я хочу увидеть сроки окупаемости, размер взносов, роялти и скачать финансовую модель, чтобы показать партнеру. Я хочу понять риски и шаги». Реальность на сайте (Когнитивный диссонанс) Отсутствует информация о сроках запуска (только общая фраза «от 6 месяцев»). Нагрузка:пользователю приходится гадать или спрашивать менеджера. Нет детализации взносов и роялти. Нагрузка: недоверие («скрывают условия»). Блок «Цели на будущее» с sticky-эффектом зависал при скролле, заставляя ждать смены слайдов. Нагрузка: потеря контроля над просмотром, утомление. Блок «Новости и СМИ» занимал 20% длины страницы, отвлекая от целевых действий. Нагрузка: визуальный шум, сложность поиска сути. Результат когнитивного разбора: сайт создает избыточную когнитивную нагрузку. Пользователь вынужден фильтровать развлекательный шум, чтобы найти бизнес-информацию. Это повышает тревожность и снижает доверие. Шаг 4. Технический аудит и комплаенс: где скрыты юридические риски Юзабилити - это не только удобство, но и безопасность. Мы выявили критические проблемы соответствия законодательству, которые грозили финансовыми и репутационными рисками для бизнеса. Нарушение 152-ФЗ:  Отсутствовал отдельный документ «Согласие на обработку персональных данных». В чекбоксах форм была только ссылка на Политику конфиденциальности. Штраф: 60 000–100 000 ₽; Cookie-баннер имел только кнопку «Принять». Отсутствовала возможность отклонить или настроить категории cookie. Штраф: до 300 000 ₽. Отсутствие механизма отзыва согласия: в футере не было ссылки или формы для отзыва согласия на обработку ПДн. Также мы обнаружили несоответствие юридической информации: на разных страницах экосистемы компании указывались разные названия юрлица, отсутствовали ИНН/ОГРН и юридический адрес. Это подрывает доверие и создает риски при проверках. Шаг 5. Сравнительный анализ с конкурентами Важно было проверить сайт клиента на соответствие рыночным стандартам. Мы сравнили его с сайтами эталонных конкурентов и выявили ключевые пробелы. Функционал У конкурентов У нашего клиента Риск Финансовая модель Можно скачать PDF/Excel Только калькулятор на сайте Потеря 15–25% конверсии, недоверие Договор франшизы Публичная оферта/PDF Отсутствует Снижение доверия, рост вопросов менеджерам Виджет чата WhatsApp/Telegram в углу Только ссылки в футере Конверсия в мессенджеры 0,16% vs 5–10% у лидеров Cookie-баннер Категории + настройка Только «Принять» Юридический риск, негативный UX Согласие на рассылку Отдельный чекбокс Объединено с ПДн Риск штрафов по ФЗ «О рекламе» Форма отзыва согласия Есть в футере/политике Отсутствует Нарушение 152-ФЗ, штраф до 100 тыс. ₽ Вывод: отсутствие базовых элементов доверия (договор, финмодель, прозрачные условия) напрямую влияет на bottom line. Бизнес теряет деньги не потому, что продукт плохой, а потому что интерфейс не дает пользователю чувства безопасности, необходимого для принятия решения о крупной инвестиции. Внедрение этих элементов — это не «украшательство», а прямая работа над увеличением выручки. Шаг 6. Приоритизация и план действий Все найденные проблемы мы разделили по степени влияния на бизнес. Важно не просто «исправить всё», а сфокусироваться на том, что даст максимальный эффект. Топ-4 задачи (Critical): Исправить битые ссылки и унифицировать юридическую информацию (Политика конфиденциальности, презентация после теста, реквизиты во всех разделах). Восстановить доверие и устранить юридические риски. Оптимизировать основной инструмент лидогенерации. Изменить первый экран (показать выгоду), упростить форму контактов, добавить мотивационные триггеры. Цель: рост конверсии с 3,5% до 8-10%. Добавить навигацию. Фиксированное меню с якорями + кнопка «Наверх». Решить проблему 44,8% отказов и потери ориентации на длинном лендинге. Добавить недостающий B2B-контент. Сроки запуска, детализация взносов, скачиваемая финансовая модель, расширенный FAQ. Закрыть потребности аудитории 35-54 лет. Проработанный UX позволяет добиться предсказуемого пользовательского поведения Хорошее юзабилити не делает сайт более красивым или стильным. Оно делает его предсказуемым и более конверсионным. Когда предприниматель заходит на сайт франшизы, он хочет чувствовать себя в безопасности. Он хочет видеть, что компания понимает его задачи, уважает его время и говорит с ним на языке бизнеса. Как только мы убираем красивые картинки с излишним интертейментом с B2B-сайта, и добавляем сухие, но необходимые данные (сроки, документы, финансовые модели), то площадка начинает работать на свою целевую аудиторию и приносить бизнесу достойный результат. Кстати, клиент принял наши рекомендации практически в полном объеме, отметив понятность, пользу и удобство отчёта. В ближайшее время уже приступит к внедрению изменений.  Это лучшее подтверждение того, что качественный UX-аудит — это не просто список правок, а дорожная карта для роста бизнеса. Помните: Пользователю не нужно, чтобы было красиво. Ему нужно, чтобы было понятно, безопасно и полезно. Всё остальное — просто декорации. А чтобы отличить декорации от работающего инструмента, нужны данные, документы и системный подход. А что, если ваш сайт уже теряет заявки из‑за сырого юзабилити? Напишите нам, и мы покажем скрытые проблемы: от когнитивной нагрузки до нарушений 152‑ФЗ. Запишитесь на бесплатную консультацию – разберём 2–3 ключевых сценария и дадим список гипотез для проверки. ]]> https://quality-lab.ru/blog/yuzabiliti-audit-dlya-b2b-sajta-franshizy-ot-krasivyx-knopok-k-sootvetstviyu-ozhidaniyam-polzovatelej/ Thu, 10 Sep 2026 14:12:25 +0300 Представим, что кто-то кому-то рассказывает историю о том, как он пытался нанять себе ментором одного тестировщика из Кишинёва, а тот оказался совершенно неадекватным неадекватом… …и я решил, что я буду изучать Playwright. Почему я буду изучать именно Playwright, а не автоматизацию тестирования ПО вообще — ну так в вакансиях пишут, что надо уметь в этот ваш Плайвригхт. Так-то я хз, как оно правильно читается, ха-ха-ха, но инглиш иззэ кэпитэл оф грэт бритэн, это я досконально знаю ещё со школы. Советское образование всегда было лучшим в мире! А что приличному человеку нужно для успешной учебы?! Ментор нужен, конечно же. Пусть все, как дураки, бегают на общие курсы, а я возьму себе индивидуального ментора, он мне обстоятельно всё объяснит, и это будет моим конкурентным преимуществом. Мы будем с ним раз в неделю созваниваться (два раза, ладно) и он будет советовать мне, что учить, а что нет смысла учить, какие именно страницы в каких именно книгах читать, и будет спрашивать, как у меня идут дела, и я как разовьюсь! Ого! Да-да-да! Ну и вот я вам пишу, драгэ романтикэ товарэшул молдовенескул тестировщик, а давайте вы будете мне ментором по Playwright. И по API. И по REST, чтобы три раза не вставать. Давайте раз (два раза?!) в неделю созваниваться, вы будете мне обстоятельно всё объяснять… это в ваших же интересах! Доведите меня до трудоустройства, и я сразу же вам заплачу за обучение с первой же зарплаты. Я знаю, что у начинающего зарплата будет небольшой, 1500 или 1700… ладно, 1200 долларов, я не жадный (для начала). И я сразу вам заплачу 200 евро, не обижу. Вам там, в Молдавии, много не надо, я смотрел видео либерально-уважаемой Натановны Эйдельман и знаю всё про вас и вашу страну. Он, конечно, попытался накрутить себе цену и сбить меня с пути истинного. Начал спрашивать, а зачем вам вообще эта автоматизация, может быть, вы сперва научитесь (хотя бы!) тестировать. Или программировать, хотя бы, на том же JS. На что только не пойдут эти молдаване ради лишних 200 долларов… Но позвольте милостивый государь, говорю я ему, я же знаю, что тестировать — слишком легко, а программировать — слишком нелегко. А я нашел хитрый способ пройти невредимым посередине — неведомая автоматизация манит меня и ждёт, когда я её открою для себя… Давайте же, ну! А он говорит — то, чего вы хотите, звучит логично, но на деле нелогично. Вы только умеете переустанавливать винду при любой проблеме и мечтаете купить мак, якобы там ничего переустанавливать не надо… Но вы даже в настройки системы никогда не заходили! Как вы будете скрипты в Playwright писать, если вы локатор в html не найдете, даже если вам на него укажут пальцем указательным?! Почему бы вам не изучить html для начала? И на Linux посмотрите, там тоже основы несложные… Каюсь, зря я ему про всё это рассказал, что умею только переустанавливать винду и мечтаю купить в Шымкенте дорогой мак занедорого, и что ничего не знаю про html. Слишком я откровенный, что поделать, страдаю человеколюбием. Мы, хабаровские, всегда от этого страдаем. Вообще я слегка уставший, но изо всех сил стараюсь оставаться вежливым, ведь с молдаванами надо разговаривать как с животными — ласково, без резких движений, а то испугается и шмыгнёт в кусты… Ну я ему и говорю, мол, а зачем мне эти твои глупые html и мануальное тестирование?! Ты такой странный, такие дурацкие предложения предлагаешь… Да ты меня НЕ СЛЫШИШЬ! У мануального тестирования нет будущего, у программирования нет будущего, в будущем будут одни только клауды, я знаю… Мне нужно научиться плайрайт, или как его там! Ментор мне нужен, мееееентоооор! Он уже занервничал, начал говорить про отвлеченное, мол, а вот вы про клауды говорите — какие именно? Вы про Cloud computing или про семейство ой-ай моделей Claude? А я ж не знаю, о чем он лопочет… Всякие будут, веско говорю. Оно сегодня так развивается, что ай-ой, завтра вообще будет ой-вэй. И пока все вы будете ой-ой, я буду спокойно автоматизировать. Месяц-другой. А потом переключусь на что-то поинтереснее… А он всё не угомонится, он меня уже с фланга обходит — а хотите, мы просто поговорим о том, как IT устроено? У меня день свободен, я машине под лобовое стекло полиуретановый герметик загнал, спешить некуда. Могу вам рассказать, с чего всё начинается и где там нужен Плэйрайт, а дальше вы сами решите, с чего вам начать… Мммм, нет, я уже всё понял, не хочет этот полиуретан поработать индивидуальным ментором. Не хотят люди деньги зарабатывать, не хотят… Ну и не надо. Я совсем уже почти договорился с одним бывшим программистом из дома напротив, так он мне устроит краткосрочные курсы по Playwright. Десят тыщ тенге за одно занятие, ну и что? Это недорого. Занятия утром и вечером, а в обед я буду заниматься дома бесплатно, я всегда имею возможность заниматься дома бесплатно и доставать свежие версии Playwright и другие полезные скрипты. В конце концов, если мне покажется недостаточно, так я всегда смогу прикупать нужное в даркнете. Пусть всякие дураки берут учебные курсы задорого. Вот я вижу, вы всегда берете учебные курсы задорого. А я могу брать их же с рутрекера, слитые, бесплатные, у меня там есть аккаунт, и они даже слитые будут лучше, чем ваши онлайн и задорого. Ваши курсы битые, а у меня будут целые, хорошие, проверенные временем курсы! Вы человек ещё молодой, вы ещё не понимаете, что главное в жизни — это устроиться с хорошими образовательными курсами… Ведь мир заполонили дурные, своекорыстные люди! Да господи же боже ж мой, ну нигде же нет от них спасения! Куда ни сунься — везде ведь они! Везде блат, по знакомству можно достать всё, а без знакомства человек ничто — особенно, если он не сумел как следует устроиться по образовательному аспекту… На том и разошлись. Весь последний абзац — мой вольный парафраз из Стругацких, «Рукопись ОЗ», раздел 23-25, спич Матвея Матвеевича утром на кухне. Соррянчики, не удержался, очень уж было похоже. А кто виноват? Я, конечно же. Человек проделал сложную работу и, как говорит тащ. военврач Курпатов, «оказался в конструкции» в которой он нашел изящное решение своей проблемы. Ему не нужно ни тестировать, ни программировать, он уже решил, что ему просто нужно освоить Playwright. Он всё продумал, он ВСЕХ перехитрил, он сумел выехать, он молодец, осталось только найти кого-то, кто ему покажет, что где нажимать и чтобы светлое будущее наконец-то настало. А тут я со своим ненужным мнением, пытаюсь ему объяснить что-то, что превышает его уровень понимания темы (винду переустановить…) на невозможном для него уровне объяснения. Мог бы я поменьше рассказывать про абстрактно-игристое?! Вы же не поэт, к чему вам смотреть, как ветер колотит воду по чреву пепельно-сизых финских волн!? Но я исхожу из того, что нельзя отказывать голодному в еде, а интересующемуся в объяснении. И если я могу что-то объяснить, то давай объясню, тебе потом проще будет понимать, как всё устроено и принимать взвешенные решения. Я, конечно же, сказал, что если вы вообще ничего не знаете о том, как делают ПО, Playwright сам по себе не имеет смысла, что там надо будет смотреть в код html и писать команды, мол, значение этого элемента сохранить в переменную и сравнить с ожидаемым результатом. Например: let totalPrice = document.querySelector('#totalPrice').textContent; let expectedResult = 100; if (Number(totalPrice) === expectedResult) { console.log("Total price: PASS"); } Вам тут всё понятно? В переменную totalPrice cохранить значение из элемента #totalPrice в виде plain text. Перевести этот plain text в число. Сравнить число из переменной totalPrice со значением из переменной expectedResult. Всё понятно человеку, который не имеет понятия, что такое html, переменные и прочие абстрактные абстракции? Оказалось, что нет. И что это всё, очевидно, лишнее. Зачем это всё? Почему же я просто не сказал ему «Нет»? Человек понял только то, что его пытаются разубедить, ему показалось, что над ним издеваются. Человек хочет просто научиться Playwright. Он же не спрашивал, как оно всё устроено. Может быть, надо было просто показать ему Playwright? Это проще показать или объяснить? В основе всего тестирования ПО лежит простой принцип — залезь в настройки, поменяй их и посмотри, что получится. В древние времена тестировщиками становились люди, которые в принципе ВСЕГДА ковырялись в настройках своих компьютеров, потому что вот так в те времена всё было устроено. Сегодня всё иначе, интерфейсы и железо стали стабильно-предсказуемыми, и уже поколения людей никогда не заходили в настройки системы, и не намереваются туда заходить, ведь там всё такое сложно-непонятное, а вдруг я что-то сломаю, ненене, не буду это открывать вообще. И в настройки отдельных программ они тоже не заходят, потому что если программа не делает то, что надо, уже проще установить другую программу. Впервые я увидел это году в 2017-ом, наверное. Коллега установил какой-то софт для записи экрана, и тот софт нарисовал ему на экране квадрат — область, содержимое которой попадет в видеозапись. А коллега хотел записать сразу весь экран, а не квадрат. Он это ПО сразу удалил и пошёл искать аналоги. Я это ПО у себя установил, увидел упомянутый квадрат, ухватил его за край курсором мыши и понял, что область видеозаписи можно спокойно растянуть, передвинуть, и вообще можно нажатием одной клавиши переключиться в режим записи всего экрана — я просто посмотрел в настройки софта… И написал коллеге, мол, it works, this gizmo is adjustable! Переключись в другой режим, нажми такую-то клавишу. Коллега ответил, что нененене, этот софт неадекватный, он скоро найдёт другой. Ну ок. Сам по себе Playwright — это фреймворк для написания кода, через который можно будет вызывать из небытия браузер и в этом браузере эмулировать действия пользователя, тыкать кнопки, пролистывать страницы, кликать по ссылкам и проверять наличие каких-то элементов или содержимое этих элементов. И тут надо бы объяснить, что такое фреймворк… А чтобы взаимодействовать с элементами в коде html надо хотя бы немного разобраться с этим самым html. Начнём с того, что это не язык программирования, это язык логической разметки текста (Hypertext Markup Language). Там дальше есть неэпически запутанные моменты и нюансы, но в основе — нет ничего сложного, смотрите…. Чтобы разобраться с html, надо написать свой код, своими руками, полностью в отдельном файле, и открыть это всё в браузере и посмотреть, что получилось. Сделал три страницы, вывел текст, вывел изображения, соединил эти три страницы через линки — увидел и понял, как оно работает. Заодно посмотришь, по нраву ли тебе айтишная работа — колотить код и смотреть, как он вроде бы складывается в нужное, а вот тут не получается, а вроде бы всё правильно написал, а что-то не так, а что именно не так, а почему оно, бляха, не работает… ааааа, вот почему оно, бляха, не работает, а я сделаю вот так, и оно, бляха, заработало, но не совсем так, как мне хотелось… И вот так целый день.   C’mon, do-something… А потом приходят какие-то дементоры и говорят, что это мы отменяем, требования поменялись, тут будет фича вообще без требований, а тут мы еще не знаем, а вот это надо срочно переделать, а вот это не трогать. И теперь оно всё никак не заработает, потому что тут убрали, там добавили, и в целом вроде всё просто, но… И вот так целый день. А когда понял, как устроены элементы в html — можно смотреть и понимать, как их делают программисты. Что есть параметры. Что есть классы. Что оформление элемента вынесено в общие файлы, потому что так устроен CSS (Cascading Style Sheets), а идею, силу и особенности CSS надо объяснять отдельно. Потом надо объяснить, что ты можешь открывать исходный код любого сайта и смотреть, как он устроен, и понимать, как с этим всем можно работать. Пришло время идентифицировать элементы в коде, и это можно делать разными способами… которые во фреймворке Playwright реализованы так и эдак, и к ним можно обращаться или так, или эдак… Одновременно с изучением html есть возможность хотя бы поверхностно потрогать траву ладонями основные принципы тестирования ПО. Playwright нам нужен не сам по себе, а для выполнения тестирования ПО в браузере руками робота, условно говоря. А чтобы тестировать, надо не тыркать элементы в html по-отдельности, а надо продумывать (распознавать логикой) сценарии, по которым будущие пользователи будут пользоваться нашим приложением. О, самое время рассказать о том, как наши html-страницы становятся частью приложения, которое работает на сервере… И в чем разница между сайтом и сервером. Наверное, в том же 2017-м один из наших джунов, который уже год тестировал проект, спросил, а где именно находится наше приложение? Одни говорят, что оно на сайте, другие — что оно на сервере. Ну, ок. Объяснил. Playwright умеет автоматически запускать и контролировать сервер, на котором находится тестируемое приложение. И оно может быть на удаленном сервере, а может работать на локалхосте. Пришло время объяснить понятие localhost… Если понял за 127.0.0.1 и 192.168…, то вернемся к Playwright. Это фреймворк, который позволяет через код программно управлять браузером. Его придумали программисты, и это не единственный фреймворк подобного рода. И чтобы им управлять, вместе с изучением html и тестирования надо посмотреть в основы JavaScript (стал основным языком работы с элементами в браузере) или Python (многие считают его норм для начинающих и таки почему бы и нет). Кажется, что для этого надо сперва научиться программировать, но это только кажется. Чтобы программировать, надо не код писать, а думать как программист. Можно научиться писать код и не научиться программированию. Кажется нелогичным, но это логично. Я знаю английский язык, но от этого я не стал англичанином. Можно научиться играть на пианино и не быть музыкантом, для этого нужен природно-обострённый слух и надо освоить математическую грамоту музыкального мышления. Вместе с основами html спокойно учим основы программирования на примере JS или Python. Само по себе это знание не сделает нас программистами. Да и вряд ли мы продвинемся дальше основ. Кто-то да, кто-то нет, заранее неизвестно, что и у кого будет получаться. Расчехляем простую рабоче-крестьянскую логику, смотрим на чужой код и разбираемся, как там все устроено. Сперва на простых примерах, затем на всё более сложных. Вгрызаемся дальше. В командной работе надо будет пользоваться тем языком, которым уже пользуются другие однокомандники. Да, в одиночку можно писать скрипты для Playwright на JavaScript или на TypeSсript или на Python или на ассемблере. Но если в рабочей группе все пишут на Go — ты тоже должен писать скрипты на Go, это не обсуждается. Надо понимать основные принципы языков программирования, а не привязываться к синтаксису. Далее оказывается, что для работы с общей кодовой базой надо разобраться в том, где она лежит, как её взять и как в неё добавлять свою работу — разбираемся с git (заодно глянем и на svn, не помешает понимать эту тему в принципе, а не в частностях). А для этого надо разобраться с тем, что такое файлы, где они лежат, как с ними работает твоя операционная система, а это вряд ли будет Windows. Давай объясню, как работает Linux… А как работает обмен данными между серверами? Рассказать про API? Показать, что это само по себе, откуда взялось и как его трогать? Нет, я не буду ограничиваться только «я покажу тебе Postman» — надо понимать, что такое API вообще, а не отдельный софт, через который можно взаимодействовать с API. И чего мы привязались к API? А реляционные базы данных кого уже давно ждут? Объяснить, почему они называются реляционными? C’mon, just do something…   Я понимаю, что эта штука делает в принципе. Я понимаю, как это устроено в принципе. Я понимаю, как найти локатор на странице в принципе. Я понимаю, как обезопаситься от того, что этот локатор в будущем может поменять свое местоположение или переименоваться или стать видимым только после выполнения какого-то действия на странице — в принципе. И вот теперь мы берём Playwright и спокойно его используем, и всё будет работать. C’mon, это уже не так уж и сложно! Заморочено, конечно, и много всякого, но в основе своей не сложно. Просто это «длинное» знание, которое приходит медленно, после изучения, привыкания и понимания простых принципов. Это не то, что можно показать на экране и сказать «Вот эту кнопку нажимай, а эту не надо трогать». А если я скажу вам сразу «Нет»? Ну, вам же легче будет? Привет каждому, кто приходил ко мне с запросом «Научите меня тестировать…», а я в ответ говорил «Ок. Сделайте сайт, три страницы, давайте посмотрим, как получится и зайдёт ли оно вам…» — может быть, вы уже самостоятельно попытались и поняли, что само по себе тестирование не очень сложное занятие, но сперва надо освоить некоторые очень неочевидные основы. Надо будет лезть в настройки системы и отдельных программ, смело что-то перещелкивать и понимать, что после этого поменяется, и отвечать за результат. И в какой-то момент обязательно надо будет понять разницу между сайтом и сервером. Тестирование само по себе — абстрактная тема, которую рукам не пощупать. Всё IT работает на абстракциях. Учиться IT — изучить абстрактные темы, для которых в быту нет и не может быть объяснений или примеров, их надо придумывать. Но можно научиться взаимодействовать с абстракциями, можно наполнять их смыслом, придавать им смыслы, перехватывать изменение смыслов… Можно понимать, что перед тобой условные переменные, и что данные в этих переменных бывают разных типов. Нужно тестировщику это знание или нет? Или оно подразумевается, потому что это база нашей профессии?! Так что да, иногда надо сразу говорить «Нет», а не пытаться объяснить, что три тысячи лет назад один древнегрек возвращался домой с рынка (по-ихнему агора) и посмотрел на звёзды… Our whole universe was in a hot dense state, Then nearly fourteen billion years ago expansion started. Wait… ]]> https://testitquickly.com/2026/09/05/playwright-de-la-zero/ Sat, 05 Sep 2026 05:06:57 +0300 На связи Анастасия Шильникова, менеджер по тестированию компании «Гарда». Мы регулярно сталкиваемся с ситуациями, когда в Jira к задаче вроде есть какое-то описание, стоит статус «готово», но, чтобы понять, в чем была проблема, что было исправлено, как было проверено, приходится «нырять» в мессенджер или звонить коллегам. Все это съедает время, размывает ответственность между командами и мешает выпускать продукт быстро, качественно, в срок. Вот несколько реальных примеров, когда описание к задаче похоже на квест:    ]]> https://www.software-testing.ru/library/around-testing/processes/4537-dor-dod Tue, 01 Sep 2026 23:00:00 +0300 Автор: Джеймс Бах (James Bach) Оригинал статьи Перевод: Ольга Алифанова Существует множество способов «ускорить что-то в 10 раз». Ехать со скоростью 300 миль в час по оживлённой городской улице. Съесть 15 000 калорий за один приём пищи. Завести десять собак. Родить десять детей. Завести сотни друзей. У всех этих вещей есть вполне очевидные последствия и побочные эффекты. Даже простое наличие гораздо большего количества друзей заставит понимать дружбу гораздо поверхностнее, чем можно было бы себе позволить. Так почему же, когда фанаты ИИ говорят о «десятикратном» росте своей продуктивности, они никогда не упоминают о побочных эффектах? Потому что они говорят и действуют безответственно. ]]> https://www.software-testing.ru/library/around-testing/processes/4505-10x Sun, 30 Aug 2026 23:00:00 +0300  Одно из применений ИИ — вникнуть в проект и понять "что тут происходит / что мне делать по задаче". Вот как раз о таком применении я сегодня и расскажу. У нас настроен дашборд в Redash для проведения НТ (нагрузочного тестирования). Его настроили один раз давно и сейчас тестировщик, проводящий НТ, просто открывает ссылочку и смотрит на циферки: Циферки показывают дату запуска, время, и разницу между последними запусками. И даже раскрашивают эту разницу: зеленый цвет — все ок красный — иди проверь, все ли там в порядке Ну а дальше тестировщик уже смотрит, где красное, и идет в интерфейс приложения искать запуск этой задачи и смотреть подробнее.  То есть в редаше настройки не трогаем, просто смотрим дашборд (обычно). Если добавляется задача в регрессионный триггер, она автоматически появится в дашборде, так как он ищет по конкретному паттеру в названии. Но тут мне понадобилось его поменять...  Мы добавили «тяжелые» задачи, но запускать их решили не еженедельно, а ежемесячно. Сделали отдельный триггер, но хотелось бы видеть их тоже на привычном дашборде. На самом деле можно было бы им название подкрутить, чтобы было "как в нашем триггере". Ну или обновить скрипт дашборда. Вот только я с Redash работала только на уровне «тык-тык по ссылочке». И раньше бы пошла искать знающего человека, чтобы он показал «как тут все устроено» А теперь для этого есть ИИ! Так что я решила начать с общения с чатиком. Пошла к ChatGPT (оригинальному, не trychat или что-то такое, но в целом, можно было поговорить с любой ИИ), начала спрашивать: У меня есть дашборд в зеус (ссылка), а как я могу посмотреть данные в его БД? Чат подсказал, что надо искать source запроса: Если скинешь сюда скрин страницы source или сам SQL из query, я прямо покажу, какая там БД, какие таблицы и каким запросом посмотреть их данные Кнопочку «Edit Source» справа вверху я еще раньше виеола, так что зашла в исходный код и показала чату запрос к базе. А он мне рассказал, как он устроен и как можно посмотреть просто данные из базы, до фильтраций. Но где смотреть? Менять source текущего запроса страшно, сломаю еще что-нибудь... Тогда я просто сделала еще раз скриншот экрана и кинула в чат с вопросом: и куда мне тут тыкать, чтобы создать собственный запрос и не сломать имеющийся? Чат мне тут же подсказал: Да — чтобы точно не трогать текущий Regression_Tasks_new, нажми слева в тёмной панели Create (значок +), а не редактируй SQL на этой странице. Дальше выбери создание Query / New Query (название пункта может немного отличаться). В новом запросе выбери источник CH_zeus — тот же, который виден у тебя сейчас сверху слева. Для проверки вставь безопасный read-only запрос: ... Нашла, отлично! Ну, с SQL я уже знакома, так что потыкала разные селектики, чтобы понять. что вообще происходит. Когда начала добавлять условия (вручную), налетела на ошибку: Code: 47. DB::Exception: Unknown expression or table expression identifier node in scope ... (тут мой запрос целиком). Maybe you meant: ['NODE'] Скопировала ошибку, скинула в чат, он мне и объяснил, что в ClickHouse (на основе данных которого и строится дашборд) имена колонок регистрозависимы. Ок, исправила, таблицы изучила. Дальше решила не химичить сама, и снова спросила чат, указав на то место кода, которое собиралась изменить: я бы хотела имеющийся запрос (выше, где and task like ('%_Regression') ) расширить задачками task in ('Task1', 'Task2'), как это сделать? И не зря! Для этого участка чат написал запрос так, как я бы сама хотела сделать, но закончил мысль так: Но есть один важный нюанс именно в твоём исходном запросе: выше у тебя task_name формируется через ... И у тебя не сработает, потому что... Если хочешь, могу сразу показать, что ещё надо поправить в полном исходном запросе, чтобы эти две новые задачи корректно отображались в дашборде. Вот блин! Как удачно, что я решила изменить запрос через него, а не самостоятельно.  Да, давай Применила правки от чатика, проверила результат — все хорошо. Потом спросила чат, как сохранить исходный запрос — у меня не было там кнопки сохранения. Скинула скрин, вот, мол, просто меняю и нажимаю Execute, да? Да, если в Edit Source нет отдельной кнопки Save и изменения применяются через Execute (⚡), то ничего дополнительно сохранять не надо. То есть: Edit Source → внести две правки → Execute → проверить результат. Как вы думаете, я сохранила итоговый запрос в блокнот "на всякий случай"? ???? Конечно же, нет, ИИ ведь сказал, что само применится! Обновила страницу, изменений нет)) Сходила к админу, попросила выдать прав, тогда и заветная кнопочка «Save» появилась... Ну и ладно, в чате с ИИ было же записано "измени тут вот так и тут вот так", снова изменила, сохранила... Фух, готово! Итого  Если бы я гуглила информацию, то долго бы искала ответы на свои вопросы (как не навредить, случайно затронув прод-запрос). Тут проще сходить за консультацией. Только вот вместо того, чтобы отвлекать коллегу, я помучала ChatGPT!  И в такие моменты ИИ очень хорош, погрузиться в новую для себя тему «самостоятельно». И именно такой навык будет цениться работодателями. как ранее навык гугления (имхо) ???? ]]> http://okiseleva.blogspot.com/2026/08/redash.html Thu, 27 Aug 2026 18:56:24 +0300 Оригинальная публикация Это третья статья из серии. В первой я разобрал 5 техник тест-дизайна, во второй - API и Security Testing на собеседованиях. Сегодня тема другая - не техническая. Хочу поговорить про роли в команде. Недавно я попал на концерт симфонического оркестра. Сижу в зале, 80 музыкантов на сцене, всё серьёзно - скрипки, виолончели, духовые. И тут дирижёр поднимает палочку, зал затихает, и у меня в голове: «Подожди... а зачем он вообще нужен? Они же все профессионалы. Ноты перед глазами. Каждый знает свою партию. Ну начните играть, чего ждать-то?» И тут меня накрыло. Я же слышу такое каждый месяц на работе: «Зачем нам QA? Разработчики сами протестируют.» «Зачем менеджер? Мы сами разберёмся, мы же взрослые.» Одна и та же логика. И там, и тут. Давайте разберу, почему она не работает. ]]> https://www.software-testing.ru/library/around-testing/management/4534-roles-in-the-team-qa Tue, 25 Aug 2026 23:00:00 +0300 Автор: Филип Рик (Filip Hric) Оригинал статьи Перевод: Ольга Алифанова Когда вы пишете end-to-end тесты, аутентификация часто становится первым барьером. Невозможно протестировать реальную функциональность приложения, не пройдя сначала экран логина. Но современные методы аутентификации могут усложнять автоматизацию, используя несколько факторов, которые трудно автоматизировать (в этом и заключается смысл 2FA). Обычно с этим справляются, либо отключая такие методы в тестовых окружениях, либо используя различные обходные решения. Кто-то может сказать, что это уже не настоящее e2e-тестирование. Честно говоря, это, скорее, тема для отдельной дискуссии, но критика подхода с обходом логина определённо имеет основания. Так как же правильно работать с аутентификацией? ]]> https://www.software-testing.ru/library/testing/testing-automation/4508-2fa-testing-with-playwright-and-mailosaur Sun, 23 Aug 2026 23:00:00 +0300 Артём Мотовилов Оригинальная публикация Предисловие Эта статья — не критика Agile или Kanban как подходов и не попытка доказать, что в IT «всё делают неправильно». Я делюсь наблюдениями из собственного опыта работы с качеством в промышленности, энергетике, а затем — в IT‑продуктах. Речь пойдёт не о терминах и инструментах, а о том, как часто теряется системное мышление, когда сложные управленческие модели упрощаются до ритуалов. Если у вас уже выстроена работа и всё стабильно — это отлично. Если нет — возможно, некоторые наблюдения покажутся полезными ]]> https://www.software-testing.ru/library/around-testing/processes/4533-industrial-approach-to-quality Tue, 18 Aug 2026 23:00:00 +0300 Дала я, значит, Курсору задачку — автотесты написать. Причем расписала все вводные: Напиши мне автотесты на задачу такую-то Писать надо тут: (полный путь к папке) Как писать таск-тесты, почитай тут — ...\task-test.md Что должно быть в тестах: ... Сидит, пыхтит. А я смотрю в IDE, он Java-класс меняет, и еще новый пишет, но уже Test. А мне это не нужно, я конкретные тесты хочу, не юниты. Я ж ему даже md-файл дала! Причем он написал нужные мне тесты, но потом его понесло... В итоге останавливаю процесс и говорю "куда ты лезешь?". А он мне на голубом глазу такой "ой, и правда...": Сразу вспоминается тот анекдот про «не прокатило» ???? Вот примерно поэтому за ИИ нужно всегда проверять, что он там понаделал) ]]> http://okiseleva.blogspot.com/2026/08/blog-post.html Wed, 12 Aug 2026 16:31:05 +0300   Первый опыт, второй, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,  16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33 Что это за техника Вы собираетесь с друзьями в группу и ставите себе цели на 12 недель (3 месяца). Это могут быть как рабочие, так и личные задачи. Такие, которые вы вроде как хотите сделать, но вечно откладываете, так как «некогда, потом, щас, вот только мелочевку разгребу и тот пожарчик потушу». Настало время заняться тем, чем действительно хочется!  Отталкиваясь от глобальных целей, составляете план на неделю. И раз в неделю встречаетесь с группой и обсуждаете, сколько успели, сколько нет. Какой план на следующую неделю. Я, правда, уже давно не встречаюсь, а просто веду файлик "что сделано", откуда потом и просматриваю всё, что успела за цикл. Результаты кратко Основной план: - ???? книга по тайм-менеджменту — написать 2 главы - ???? сделать 1 урок нового курса - ???? 1 статья на Хабр - ???? 2 видео на ютуб На самом деле очень круто вышло, с учетом того, что в этом цикле было 3 дня рождения в семье + смена нянь (а поиск новой — это время + потом помогать первое время надо) + болезни + ломалась коляска (а с погодками без коляски никак)... А еще я на работу вышла! Из декрета. Достаточно внезапно получилось, я спрашивала о такой возможности3 месяца назад, и тут мне предложили, а я и согласилась, и в середине цикла уже вернулась на работу. Теперь вливаюсь в новый режим, пытаюсь совмещать работу и курсы (пока получается плохо) Тем не менее я написала не просто 2 главы новой книги, а целых 5! И статьи на Хабр сделала, и даже про ютуб не забыла! С курсами пока тяжело идет, да. Но я буду стараться))) Так что пока вливаюсь. Но все таки кое-что успела: Книга 5, ChatGPT: сдала в издательство добили картинки с художницами расставила картинки "диалоговые" во всей книге начали редактуру! Вычитали 14 глав начали верстку, так как она сложная Книга 6, тайм-менеджмент — написала 5 глав ???? Курс по автоматизации в Postman: Закончила перезапись всех 14 уроков Переписала кусок в уроке 14, когда загрузка стала платной Перезаписала почти весь урок 1, так как там много обновилось Статьи на Хабр — 2 статьи ???? Пополнила свой youtube-канал — 3 видео ???? Нашла помощника с монтажом Побывала на TechWriter Days 3 Инструменты 12 недель — продолжаю вести файлик DONE, это все еще очень круто Хожу в спортзал ???? Нашли новую дневную няню деткам. Влад закончил 1 класс!  Отмечали ДР мужа! Отмечали ДР Леши — 2 года уже! Отмечали ДР Кати — 1 годик! Фотосессия! Сходили в театр с мужем! Результаты подробнее Книга 5: ChatGPT В прошлом цикле я уже давно закончила книгу и ждала художниц. Я их 3 месяца, блин, ждала! Поэтому оплатила Нано Банано и в следующей книге будет больше моего творчества... Тем не менее: ????13 мая — сдала рукопись, ура! Вика всё закончила)) ????  9 июня — начали редактуру, Евгения прислала мне первые 5 глав. ???? 22 июля — начали верстку. Людмила прислала мне верстку первых 4 глав. Редактура еще не закончена (мы на 14 главе тогда были), но верстку начали, так как она сложная. У меня всегда сложная верстка, потому что в моих книгах много картинок. А в книге про ChatGPT еще диалоги с роботом есть, их тоже надо как-то оформить. Вот и начали верстку заранее.  Это даже хорошо! Глядишь, книга скоро выйдет))) А с картинками для диалогов тоже забавно вышло. Я сначала сделала сами картинки и художница их нарезала: А потом я уже догадалась спросить у Людмилы, как лучше — чтобы она просто в каждый диалог новую девочку вставляла или мне разметки сделать. Оказалось, что мне =))) Так что я в срочном режиме бегала по каждой главе и расставляла там нумерацию девочек и роботов для диалогов. В общем, много работы над книгой было в этом цикле, много! Книга 6: тайм-менеджмент В этом цикле я подала заявку на новую книгу, над которой уже начала работу ранее. Показала свои наработки редактору, он говорит — присылай проспект! Сказано, сделано. Оформила план-проспект, сдала. Его согласовали и на 5-ой неделе, ну а я продолжила работу над книгой, отвлекаясь только когда по предыдущей что-то приходило на выверку. Пока у меня написано 5 глав, посмотрим, сколько будет в следующий раз!  Я довольна результатом, хотя, конечно, с учетом планов написать ДВЕ книги в этом году, я капитально отстаю. Рассчитывала к лету уже сделать книгу по тайм-менеджменту, но... Это было слишком оптимистично ???? Курсы Автоматизация в Postman Я доделала то, что планировала исходно! Прошлый результат — 11 уроков готовы. Текущий — 14 уроков готовы. Хотелось бы на этом и остановиться, но Постман стал подкидывать приколы, из-за которых я и ставила курс на паузу. Обновилась документация и теперь мне надо еще раз пересмотреть свои лекции и что-то, возможно, перезаписать. Загрузка из файла вдруг стала платной. Я переписала уже записанный и обработанный 14 урок — не весь, вставку сделала. Теперь надо сделать вставку в урок про загрузку из файла. Переписала кусок в первой лекции, где первый запрос, потому что внешний вид постмана тоже чуток обновился. В общем, почти готово, но не успела закрыть все в этот цикл. Конечно, "помешала" работа, так как последний месяц я привыкаю к новым реалиям и теперь сложнее выкроить время на курс. Но ничего, вольюсь и продолжу работать! Новые курсы Пока на паузе, ждут, когда я доделаю постман. Есть пара идей из того, что я могу сделать относительно быстро (там, где я и так все знаю) и пара идей, где мне будет посложнее (продумать структуру и т.д.) Надеюсь, в следующем цикле я как минимум начну новый курс! ???? Улучшалки по старым курсам ПОТ: Переписала лекцию автоматизации в GUI, так как селениум ИДЕ сдох ChatGPT: 1. Добавила раздел "мои истории" 2. Добавила туда ссылку на «ИИ, помоги мне настроить IDE» 3. Добавила туда ссылку на «Настраиваем IDEA с ИИ, часть 2» 4. Добавила туда ссылку на «Как я сделала отчет о дифференциальном тестировании через Cursor» 5. Добавила ссылку на "Анализируем данные в файле с помощью ИИ" Рест: 1. В ДЗ 12 поменяла ссылку с гуглодоки на конфлюенс 2. В конфлюенсе убрала ссылку, которая работала только под впн (на http-статусы) 3. Исправила картинку "как в джире связывать задачи" в ДЗ 6 Хабр Хотела написать одну статью, а вышло 2, отличный результат! ???? 1. Типы границ для классов эквивалентности — https://habr.com/ru/articles/1045436/ 2. Как я сделала отчет о дифференциальном тестировании через Cursor https://habr.com/ru/articles/1058722/ Блог Благодаря выходу на работу оживила свой блог =))) ИИ, помоги мне настроить IDE Настраиваем IDEA с ИИ, часть 2 Настраиваем IDEA с ИИ, уточняем теорию, часть 3 При общении с ИИ не усложняйте вопрос, это сожрет лишние токены Анализируем данные в файле с помощью ИИ Как ИИ нам проверку уязвимостей сломал Как убрать поп-ап с параметром в ТeamСity Youtube / ВК Мой канал — https://www.youtube.com/c/okiseleva (Дубль в ВК). Обновления в этом цикле: 1. Что такое регулярные выражения  2. Заменит ли ИИ тестировщиков?  3. Как написать автотест на HTML в Postman-е Конференции Ездила ко конференцию техписов, мне это все очень близко, ведь я тоже занимаюсь документацией. Рассказа про конференцию здесь: TechWriter Days 3. Как это было Вышла из декрета Я в марте ездила в офис и спрашивала начальницу Катю, не надо ли ей, чтобы я вышла, скажем, до осени. Заранее готовилась к лету, это всегда мертвый сезон на курсах. Но на тот момент мест особо не было, особенно краткосрочных. А в начале июня Катя сама написала и спросила, актуально ли мне вернуться. Но, конечно, уже не до осени, а просто выйти из декрета. И я согласилась! У нас на тот момент «через неделю» должна была быть очередная госпитализация с дочкой, так что договорились, что я выйду через 2 недели.  Воу, вот это неждачик был о_О Главное, сама договорилась, потом сама в шоке была)))) А потом началось веселье, за эти 2 недели: - дети приболели = плохие ночи у нас - у няни заболел ребенок и она день в день написала "сорри, сегодня не приду" - няня сама заболела (аналогично) - няню сбил самокатчик недалеко от нашего дома — жуть вообще, 17-летний пацан сбил и укатил в закат, думал, не найдут (нашли). Еще минус 3 дня, травмпункт + лекарства... После каждого проишествия я думала — ну куда я лезу, как я работать то буду, когда тут такое?? Но ничего, прорвемся! Сейчас вот уже работаю, пока все хорошо, тьфу тьфу тьфу. Но сентябрь пугает, там и старшему в школу, и средний выйдет в ясли на весь день = привет, болезни! Ох, боязно! Ну и работать Н часов подряд непривычно, конечно, вот из моих заметок: Работала 8 часов, мозги сплавились (((  Так-то я на полставки вышла и работаю по 5ч, но пока не получается каждый день укладываться в этот срок, тут продолбаюсь, там не успею, вот и засиживаюсь. Но ничего, это первые месяцы такие, сложные. Уже начинаю потихоньку вливаться в режим. А там, глядишь, и время на курсы появится! Магия утра Я когда-то пробовала жить по магии утра, но у меня не получилось. Мы тогда вставали в 6 утра, чтобы к 7 приезжать на работу. Какая тут магия, в 5 вставать? Так я на нее и забила. А тут у меня дочка вставала, вставала спозаранку, а потом как стала спать! А я аккуратно выходила из спальни — мы лечим гемангиому, даем  лекарство Атенолол, его надо давать строго по часам. Так что в 7 утра я встаю набрать шприц, потом обычно ложусь досыпать до 8, в 8 даю ей лекарство: - Поднесла шприц, та рот во сне приоткрыла, пшик! - И тут же соску дать ???? И тогда, если она еще спит и вставать не хочет, отворачивается на бок и досыпает своё. А я пару раз попробовала лечь, но лежись и пошевелиться лишний раз боишься, Катя ворочается, ты тут еще шумишь... Встанет в 8.20 и кажется, что из-за тебя. Поэтому я стала в 8 выходить и хотя бы 20 минут... Работать! Да, работать, зато у меня каждый день теперь стабильный заход к книге есть. Ну, как каждый... Когда Катя спит))) Вот выдержки из файла результатов: Катя встала в 5.40, весь график сбился... А потом внезапно до 8.30 и это такой кайф! Прочуствовала магию утра прям (9 нед) Рабочий день... Но я встала в 7 утра, раньше Кати! 1. Заход к книге. даже парочка небольших, пока Катя спала И потом такие же заметки: Утром встала раньше Кати 1. Заход к книге! Хорошо идет утром В общем, лет 8 магию утра отвергала, но, когда у тебя трое детей, ТИХОЕ утро — это чистый кайф! Даже если работать))) Что еще Почитала питон-книгу! Хотела прочитать хотя бы 100 страниц, остановилась на 97. Ого, так я даже выполнила свой план, оказывается. И сделала это в первые пару недель цикла. Потом болезни, не до книги было. А потом на работу вышла. И последний месяц+ не читала ее совсем. Это грустно, но пока я только настраиваю режим, хочется хотя бы работать успевать, а читать уже так, дополнительный бонус. Внерабочее Няни У нас ушла дневная няня и мы чуть ли не месяц искали замену. Вроде нашли Владимира, потом он отказался по своим причинам, снова искали... Нам тогда очень повезло, что вечерняя няня работала на полставки и согласилась приезжать после обеда, очень выручила нас. Нас пара нянь прокинула. Сначала договариваемся на пробный день, а утром няня "ой, я не приеду". Но помучались, помучались, и нашли! Сейчас у нас есть Татьяна, ура! Эти поиски выбивали меня из режима: Няня нас прокинула прям с утра. Благо Владимир согласился приехать Снова искала няню, ну и работать не хотелось           ...  Нашли няню, вводили её в курс дела и тд. Почти не работала, только текучка Потом у нас няни болели, в итоге снова я с детьми. И снова все планы нафиг. Увы, у мамы малышей такое постоянно: Всё пошло не так... У Кати снова сопли, я ночью не спала. Легла спать, сдав детей. Потом долго тупила, в итоге не работала, но убралась Плохо себя чувствовала, не работала. Дети и все вокруг Ездили с Катей на госпитализацию, нас опять отпустили сразу. Сделали лазер и отпустили. Хотя в прошлый раз говорили, что положат на пару дней увеличить дозу лекарства, но в этот раз был другой врач, он отпустил. Следующая госпитализация уже в сентябре. И тоже непонятно, положат, не положат... Посмотрим, что тут гадать! Ещё у нас в этот цикл коляска опять сломалась! Просто старший сын привык ездить спереди — пока Катя была совсем маленькой, люлька нужна перед тобой (у нас же длинная двойная коляска, а не широкая, где два места рядом). Да и Леше интересно все вокруг, поэтому ехать спереди тоже хорошо. Но сейчас он уже весит прилично, а большие колеса на коляске сзади. Уже один раз колесо ломалось, но нам повезло, нагуглили ремонт на авито, и в тот же день привезли колесо, к вечеру забрали. А второй раз сломалось в выходные, субботу или воскресенье. Починили только к среде! И вот это были жесткие несколько дней. Дети то привыкли спать на улице, а тут надо было выходить с обычной коляской (в ней Катя), Лешу за ручку...  Потом на сон возвращаться, укладывать дома — Леша то нормально укладывается, а вот Катю еще поди уложи. Один из дней вообще треш был, у Татьяны ребенок свой заболел и она прийти не смогла. Коляска сломана, на улице дождь, красота... Благо другая няня смогла ее подменить, но и я носилась, помогала... Как хорошо, что все эти неприятности были ДО выхода на работу, а! ???? Праздники! В этом цикле были майские праздники — я в них играла, отдыхала, но не работала. Плюс собрали кучу дней рождения. ДР Леши!  Ему уже 2 годика, вау! Мы сходили в местный Джоки Джоя с ним, он был в восторге от ватрушки: Просто по кругу ходили, скатились, идем наверх, снова скатываемся. Сначала только с папой или мамой, потом решился один и тогда ты тащишь ватрушку наверх и потом бегом бежишь вниз встречать сына))) А он уже снова чешет наверх! Но, главное, что ему очень понравилось, прям в восторге был! Мы ходили с няней, она развлекала Катюшу, пока мы катались с Лешей. А потом, когда все вышли, то дети поехали с няней спать младшие, а мы со старшим вернулись домой))) ДР мужа!  В кои-то веки выбрали куда-то ВМЕСТЕ. А то хотя бы один всегда дома, чтобы няне помочь собраться на улицу... А тут поехали в любимый «Изипаб», я там от души наелась, заказав всего самого любимого: бородинские гренки с сырной намазкой — ммммм! И пусть я только однй гренку съела (не влезло просто), но взяла! сырные кусочки с малиновым соусом салатик с авокадо биштекс с картошкой по деревенски сладенький раф-кофе Красота! Правда, я поехала на пару часов, после чего откланялась и все же вернулась помогать няне. Но зато этот день поменял многое. Няня сказала, что может справиться и сама, и вот сейчас мы уже не всегда ей помогаем.  Раньше то — детки собираются? Я навожу молоко, муж одевает Катю, няня Лешу... А теперь можно продолажать заниматься своими делами))) Но это пока лето и сильно одеваться не надо. Осенью, а особенно зимой, лучше помочь, чтобы детки не запарились, конечно. Ну и с прогулки обычно встречаем, и деткам, конечно, тут же надо попу на маме умостить)))) ДР Кати! Красавице нашей уже годик! И вот она вроде только-только вставать начала, а уже чешет по всей квартире на ножках, а не на карачках))) Лишний повод для встречи с друзьями! На Лешино ДР мы особо не звали гостей, а Кате пока рано во всякие развлекательные комнаты, так что мы собрали друзей и отмечали сами))) Зато повидались с друзьями, и принцессу все потискали! Фотосессия! Ну и на фотосессию сходили. Фото на обложке поста как раз оттуда ))) Прикольно было то, что как раз там Катя делала первые шаги, жаль только, что именно эти моменты особо не захватили на фото ((( А я очень надеялась на это. Но зато там у каждого был шарик с возрастом, забавно вышло: И детки были в восторге от шариков, активно игрались с ними))) Ну и в целом удобно, что у нас фотостудия недалеко, в пешей доступности, можно хотя бы раз в год устраивать такой фотосет, смотреть как детки меняются! Уборка Не обошлось и без генеральной уборки: Выгребла всё с антресолей, упаковали всю зиму в один кофр, который я с вб принесла, больше часа это всё разгребали! Вычистила угол кухни с пакетами, вынесла мусор. Разгребла вещи на вешалках в угловом шкафу. Разгребла вещи справа от угла, и антресоль, и вешалки все перебрала. А угловой шкаф, это в который я в полный рост помещаюсь)) В общем, капитально так подрагребла вещи, это радует! Театр Сходили в театр — Элементарно, Хадсон.  До сих пор вспоминаю рыжую банду и как они играли музыку там))) Хотя прошло уже много времени! В театр сходили как раз благодаря няне, когда она отпустила нас вместе на ДР и сказала, что может сама справиться, мы взяли билеты и вот, сходили! Замечательное шоу вышло, я очень довольна) Спорт Занимаюсь в зале. Наш зал закрывался на время и тренировки перенесли в другой. Ходила туда пешком по полчаса, тоже мини-тренировка! В целом летом это удобно, не по дорожке унылой чтобы ходить, а гулять и наслаждаться прогулкой))) А сейчас стала заниматься 1 раз с тренером и пытаюсь 1 раз сама прийти. Получается не всегда, так как пока сложно вписать в расписание ВООБЩЕ ВСЕ. Вот сегодня если пойду в зал, будет некогда делать детям печеньки на завтрак, поработать могу не успеть... Поэтому пока в раздумьях. Но в целом 1-2 раза точно хожу, уже прогресс! Проверка планов, поставленных в прошлый раз Основные цели: ???? Книга по ChatGpt — сдать в редактуру → сдала, и уже половину вычитали! ???? Книга по тайм-менеджменту — написать 3 главы, по одной в месяц норм план! — написала 5 глав ???? ????Курсы — сделать 1 тему нового курса — пока постман даже не закончила ((( ???? Статья на Хабр — ну хоть одну! — даже 2! ???? Найс ту ду: ???? Youtube-канал — 2 шт — уменьшаем цель до реально достижимой)) — и ведь ровно 2 видео и залила! ???? Книга по Python — прочитать 100 страниц — прочитала 97, но ведь прям как и хотела примерно!  ???? Встретиться с друзьями — дни рождения сильно помогли в этом)) ???? Курс по постману — сделать ещё 3 лекции (не верю в полную перезапись с учетом новогодних праздников и начала садика = болезней) — доделала все лекции, осталось обновить то, что вновь неактуально) Планы на следующие 12 недель Основные цели: Книга по ChatGpt — закончить редактуру Книга по тайм-менеджменту — написать 3 главы, по одной в месяц норм план! Курсы — закончить с постманом уже! Курсы — сделать 1 тему нового курса Статья на Хабр — ну хоть одну!  Найс ту ду: Youtube-канал — 2 шт  Книга по Python — прочитать 100 страниц (хочется снова к ней вернуться) Встретиться с друзьями  Резюме Я каждый раз так поражаюсь, перечитывая начало файла с результатами — как?! Это было в этом цикле?!! Офигеть!!! Смена нянь была, кажется, так давно... Как хорошо, что это уже в прошлом! И как круто, что столько всего успела, несмотря на смену нянь, болезни и все прочее. Я думаю, отличный вышел результат, а дальше будет только лучше! ]]> http://okiseleva.blogspot.com/2026/07/12-34-1-2.html Mon, 27 Jul 2026 08:44:07 +0300 Тестирую задачу на поиск дубликатов. Дубликаты определяются по конкретным правилам, и коэффициент соответствия зависит от того, попадает ли фамилия / имя / отчество в соответствующий справочник, или нет. А еще в компонентах ФИО бывают опечатки, и это тоже влияет на коэффициент. А длина компонента на это влиять, наоборот, НЕ должна… В общем, для тестирования мне нужно проанализировать справочник фамилий и набрать себе оттуда тестовых данных под разные сценарии — короткая фамилия, длинная, и так далее. Раньше мне нужно было бы изучать это все на глаз или размышлять, как самой написать код. Но сейчас эту работу можно отдать ИИ! Причем я пошла к обычному текстовому чату с моими вопросами (а не к Курсору), и его вполне хватило. Сначала я решила поискать самое длинное значение в справочнике. Справочник фамилий очень большой (вы себе даже не представляете, насколько они разнообразны!), так что я решила подсветить ИИ его вес, вдруг это важно: У меня есть файл на 17 мб, в нем данные вида (структура справочника изменена для статьи, но смысл отражает): НАЗИН;М; НАЗИНА;Ж; Как табличка в несколько колонок. Как мне найти самое длинное значение в первое колонке? У меня винда, греп не установлен, через winget есть аналоги нынче? или надо поставить цигвин? Ну да, раньше я анализировала файлы с помощью регулярных выражений и Cygwin, ещё до ИИ новомодных! Правда, файлики были поменьше размером, что тоже влияло. В общем, Cygwin чатик высмеял и предложил другие решения (ответ сокращен): Ставить Cygwin в 2026 году точно не нужно — это тяжелое и устаревшее решение. Поскольку у вас 17 МБ (это очень маленький объем для современных ПК) и уже открыта Giga IDE, а на Windows есть встроенный PowerShell, решить эту задачу можно моментально и без установки лишнего софта. Вот 3 простых и быстрых способа на выбор: —————————— Способ 1. Написать 4 строчки кода прямо в IDE (Самый быстрый и удобный) … —————————— Способ 2. Через встроенный Windows PowerShell (Без установки программ) В Windows есть мощная консоль PowerShell, которая справится с этим в одну строчку. 1. Откройте поиск Windows, введите PowerShell и запустите его. 2. Скопируйте и выполните следующую команду (замените путь к файлу): Get-Content "C:\path\to\your\file.txt" | ForEach-Object { $_.Split(';')[0] } | Sort-Object Length -Descending | Select-Object -First 5 Что делает эта команда: Она читает файл, разбивает каждую строчку по ;, берет первый элемент, сортирует всё по длине от большего к меньшему и выводит топ-5 самых длинных значений (на случай, если будет несколько одинаковых по длине). Для файла 17 МБ это займет около 3–5 секунд. —————————— Способ 3. Через Git Bash (Если вы ставили Git) … Меня, конечно, заинтересовал первый способ, создать Scratch File в IDE и запустить его. Вот только он у меня не завелся, ошибку отдала чату, он вроде переписал, и снова не сработало… Я решила не тратить на это время и попробовала вариант с PowerShell. И ведь сработало же! Тогда я пошла искать нижнюю границу: (цитирую способ 2, общалась с телеграм-ботом)  хороший способ! а самую короткую запись как найти? Чатик и такой вариант написал, и разжевал все изменения: Вариант для PowerShell (Топ-5 самых коротких, без пустых) Скопируйте и вставьте эту команду в синее окно PowerShell: Get-Content "C:\path\to\your\file.txt" | ForEach-Object { $_.Split(';')[0].Trim() } | Where-Object { $_ -ne "" } | Sort-Object Length | Select-Object -First 5 Что изменилось: 1. Добавилось .Trim() — убирает случайные пробелы по краям. 2. Добавился блок Where-Object { $_ -ne "" } — он выкидывает пустые значения, чтобы они не мешались в топе. 3. Из Sort-Object убрали -Descending — теперь первыми идут самые короткие слова. Потом мне понадобилось немного усложнить логику: А если я хочу самое длинное первое слово среди тех, у кого в 3 колонке было значение "1"? И снова скрипт на PowerShell отлично сработал. Также для проверки граничных значений мне надо было найти данные ровно на 6 символов, и тут чат помог: Напиши скрипт, который выведет 10 первых строк файла, у которого в 1 ячейке 6 символов. И как его исправить, чтобы было меньше 4 символов? (это я решила сразу другую границу проверить) А потом мне надо было найти путаницу букв, анаграммы. И при этом чтобы оба значения были справочные. Сначала я сходила к Курсору: Можешь открыть файл C:\tmp\test.csv и найти там все строки, в которых в первой ячейке ПОЧТИ одинаковые данные, но буквы перепутаны местами?  Например ШУМИЛИНА и ШУЛИМИНА обе есть в этом файле, расстояние - 1 буква. Я хочу видеть все такие строки и столько у каждой расстояние перепутанных букв (включая расстояние 0) Посмотрела, что он там пишет, а он написал: Думаю, как сделать… Тут нужен скрипт на питоне! Пишу скрипт… Ой, питона нету, хм хм, тогда сделаю через PowerShell… Сделал, но немного не так, как мне бы хотелось. А токенов при этом выжрал ой-ей-ей! Поэтому я попробовала запросить скрипт у обычного чатика и вернулась к телеграм-боту. Но для начала я установила питон, ведь ИИ сказал, что на нем будет лучше всего выполнить задачу. Потом уже пошла к боту: Как мне найти все анаграммы в файле C:\tmp\fname.csv? Структура айла: ГАДАВИЯ;Ж; ГАДАД;М; То есть чтобы значение во второй ячейке (М/Ж) совпадало и слово в первой ячейке тоже совпадало, но у него 2 буквы перепутаны местами. Но чтобы оба слова при этом были из файла! Разбить ответ надо по расстоянию между перепутанными буквами: соседние буквы поменяли местами, через одну, и так далее. Через питон или павершелл И ведь не зря питон поставила! Вот что сказал чат: Для решения этой задачи Python подходит идеально. Написать такой алгоритм на PowerShell можно, но он будет работать значительно медленнее и код получится очень громоздким. На Python мы можем применить хитрую оптимизацию, благодаря которой скрипт найдет все пары за долю секунды. Python-скрипт Создайте на компьютере файл, например find_anagrams.py, и вставьте в него следующий код: … Как запустить этот скрипт на Windows: … Что вы получите на выходе? … Скрипт отработал на ура, столько данных мне собрал, сколько я бы никогда не наскребла вручную! А уж сколько нового я узнала о фамилиях и именах ))) Потом я пошла тестировать дальше. И мне понадобились новые кейсы — когда оба значения справочные, но есть опечатка или пропуск буквы. И снова поиск таких данных вручную занял бы кучу времени, так что я пошла к ИИ, начать решила с пропуска: Напиши скрипт (питон или павершелл), который найдет в файле такие строки, где в первой ячейке одно и то же слово, но в одной из ячеек пропущена 1 буква — то есть одно слово включает в себя другое, но длиннее на 1 символ, но этот пропущенный символ может быть даже в середине строки. И вот уже он выдает мне скрипт на питоне! А потом дошли до опечаток: Напиши скрипт (питон или павершелл), который найдет в файле такие строки, где в первой ячейке одно и то же слово, и ровно 1 символ у них отличается. Результат отсортировать по длине строки. ИИ и тут помог, выдав очередной скрипт на питоне. Вот только этот скрипт работал подозрительно долго, искал и искал данные, я уже чай попила, другие задачки поделала… Так и написала боту: Этот скрипт ищет пары уже полчаса И бот выдал мне оптимизированную версию! Ваш скрипт «завис», потому что даже с группировкой по длине, если в файле много слов одной длины (например, 100 000 имен длиной 7 символов), количество сравнений внутри этой группы всё равно остается огромным (N^2). Чтобы ускорить поиск пар с расстоянием Левенштейна = 1 для 3 миллионов строк, нужно отказаться от «честного» сравнения каждого с каждым. Используйте хеширование (метод «удаления одного символа»): … Идея алгоритма: … Оптимизированный скрипт: … Потом я искала две опечатки и сразу указала в промпте, чтобы оптимизировал свой вариант: Напиши скрипт (питон или павершелл), который найдет в файле такие строки, где в первой ячейке одно и то же слово, и ровно 2 символа у них отличаются. Результат отсортировать по длине строки, но чтобы работал не полчаса. В файле много строк, оптимизируй скрипт под это условие И снова результат готов меньше, чем за минуту! Итого ИИ — просто незаменимый помощник в работе! Я с его то помощью пару дней анализировала данные и составляла тест-кейсы, а сколько бы времени потратила без него? Мне все равно бы понадобилась автоматизация, чтобы найти граничные значения или тестовые данные “надо, чтобы она значения были в файле, но…”. Вот только сама бы я писала бы эти скрипты не пару минут, а пару часов каждый. И это в лучшем случае! По крайней мере те громоздкие питон-скрипты, с павершеллом и гуглом я бы справилась быстрее. Но в языке программирования помощь ИИ была просто спасением! PS — эта статья написана в помощь студентам моего курса «Применение ChatGPT в тестировании» ]]> http://okiseleva.blogspot.com/2026/07/blog-post_24.html Fri, 24 Jul 2026 17:02:37 +0300 Я хочу рассказать, как я сделала отчет о дифференциальном тестировании (сравнение двух функций на одних данных) через ИИ. Знаю, что многие уже применяют ИИ и в хвост и в гриву, но также много тех, кто пока не умеет этого делать. Поэтому я хочу показать на конкретном примере из жизни, где еще несколько лет назад пришлось бы делать красивый отчет в ручную, а теперь его делает робот за пару минут. Возможно, это вдохновит вас тоже попробовать сделать нечто похожее =)) Ссылка на Хабр Мой пример 1. Проведение тестирования Тестировала задачу исследования — изменение коэффициента похожести для поиска дублей. То есть функция определения коэффициента уже есть, работает. Но решили «тут поменять, там поменять», и посмотреть, станет ли лучше.  Поэтому это и называется задачей исследования — мы не сразу заменяем старую функцию новой, а проводим эксперимент: делаем вторую функцию,  готовим тестовые данные,  прогоняем их на старой и новой функции, анализируем результат — если “да, круто вышло!”, то заменяем одну функцию на другую, если “чет не то”, то думаем дальше. Вторую функцию сделали, моя задача была — провести шаги 2-3. И частично 4, нужно красиво-понятно отобразить отчет о тестировании, чтобы аналитик его изучил и потом уже принимал решение. Тестовые данные я подготовила сама. Посмотрела на ТЗ и так, и эдак, и поняла, что я дольше буду расписывать ИИ, что именно тут надо сделать, чем сделаю это сама. Хотя ИИ я все равно погоняла и в хвост, и в гриву для сбора тестовых данных, но об этом я расскажу в следующий раз. Данные собрала, потом написала автотесты. Выглядят они примерно так (для простоты понимания будем сравнивать ФИО): Опечатка в отчестве;99;Назина;Ольга;Евгеньевна;Назина;Ольга;Еквгеньевна Объяснить с Что тут есть: Описание теста Коэффициент похожести ФИО первой пары в трех ячейках ФИО второй пары Обычно в автотестах делают разные файл — что подается на вход, что получаем на выходе. Но у меня выходной параметр всего один (коэффициент), поэтому он записывается сразу внутри теста. Если автотест упадет, выглядеть это будет так (допустим, вместо коэффициента 99 вернулся 0):  Expected:  [2/Similarity]:99      Actual:  [2/Similarity]:0 Input data: 1. Опечатка в отчестве;99;Назина;Ольга;Евгеньевна;Назина;Ольга;Еквгеньевна Etalon data: 1. Опечатка в отчестве;99;Назина;Ольга;Евгеньевна;Назина;Ольга;Еквгеньевна Result data: 1. Опечатка в отчестве;0;Назина;Ольга;Евгеньевна;Назина;Ольга;Еквгеньевна Это стандартный вывод автотестов: Input data — что на входе Etalon data — что я ожидаю Result data — что тест ожидает Да, в моем случае Input и Etalon совпадают, но зато такое решение работает как для разных входных-выходных файлов, так и для одного. Итак, автотесты я сделала. Получилось их довольно много, больше 300, так как много разных сценариев нужно было покрыть + на каждый сценарий надо было сделать 2-6 тестов (тест-дизайн и все такое). Прогнала на новой функции — 100 падений (цифры эти для примера, но чтобы показать масштаб проблемы формирования результата). Сохранила результаты прогона в файл new.txt. Прогнала на старой функции — 200 падений (то есть новая работает лучше).  Сохранила результаты прогона в файл old.txt.  Огонь, осталось оформить! 2. Оформление результата Я подумала — как я хочу видеть результат? Хорошо бы в виде таблички, чтобы сразу видно “эта функция справилась, эта нет”. Взяла из результатов прогона новой функции первое падение (см пример выше) и на его основе накидала в конфлюенсе такую табличку: Описание Коэф ФИО 1 ФИО 2 testOldFunction testNewFunction Комментарий testOldFunction работает, testNewFunction нет 1. Опечатка в отчестве 99 Назина Ольга Евгеньевна Назина Ольга Еквгеньевна Успех FAIL / ожидает 0 По сути я просто вытащила все колонки из теста и добавила в конец 3 новые для анализа результата: testOldFunction — как справилась старая функция testOldFunction — как справилась новая функция Комментарий — чтобы подсвечивать “тут некритично, а тут обратите внимание!” Что писать в колонки прогонов: Успех — если в файле прогона функции НЕТ этого теста, значит, он не упал, а прошел успешно. По крайней мере я сохранила в файл именно падения. «FAIL / ожидает такое-то значение», чтобы было видно, что ждем мы (2 колонка) и что выдал тест. Ну и, конечно, результаты надо бы сгруппировать: Старая функция работает, новая нет Новая функция работает, старая нет Обе не работают И внутри еще сгруппировать (помните ведь, что падений было 200+, да?). Я посмотрела глазками отчеты и выделила некоторые повторяющиеся падения.  Допустим, есть проблема в двойном имени. Тогда все сценарии, в которых оно участвует, упадут. И вот эти падения хотелось бы сгруппировать, чтобы: Сразу увидеть масштаб проблемы — сколько таких сценариев сломалось Понять, что еще сломалось — увидеть все другие падения отдельно, а не так, что через раз будет “снова двойное имя”. Так, работа понятна! Но делать ее вручную — это ж капец сколько времени! Вытащить из результатов падений что-то одно (например, строку Result data), чтобы открыть в экселе, а не блокноте, чтобы это все скопировать и вставить в таблицу в конфлюенсе. Но ведь все группировки придется делать вручную! Да, можно через поиск их находить и копировать пачками, а потом удалять в прогоне и смотреть, что осталось, но все равно это очень унылая работа. А вот робот с рутиной справляется на ура! Главное, четко сформулировать ему, что именно ты хочешь. И показать, в каком виде тебе это нужно сделать. А у меня и это есть, вон табличка с примером. Я выгрузила эту табличку из конфлюенс в ворд-файл test_results_demo.docx, чтобы скормить ИИ. Правда, пришлось внести коррективы уже на этом этапе. Исходно то я и правда вставила в конфлюенс тест «как ]]> http://okiseleva.blogspot.com/2026/07/cursor.html Tue, 21 Jul 2026 17:40:06 +0300