Автор:

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

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

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

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

Продолжаем настраивать компьютер с помощью ИИ (начинала тут). Что ещё я спрашивала у чат-бота?

1. Какой путь указывать для Java?

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

org.gradle.java.home — на винде какой путь надо указывать, до бин или самой папки? C:\Program Files\Eclipse Adoptium\jdk-25.0.3.9-hotspot\bin

Ответ, если вам интересно:

Нужно указывать путь до самой папки (то есть до корневой директории JDK), а не до папки bin.

Как правильно:

• ❌ Неправильно: C:\Program Files\Eclipse Adoptium\jdk-25.0.3.9-hotspot\bin

• ✅ Правильно: C:\Program Files\Eclipse Adoptium\jdk-25.0.3.9-hotspot

Почему так? Gradle (как и сама Java) ожидает, что в указанной папке он сам найдет подкаталог bin и запустит оттуда файлы bin/java или bin/javac. Если указать путь вместе с bin, Gradle будет искать компилятор по несуществующему пути .../bin/bin/java и выдаст ошибку.

+ ИИ дал уточнение по винде, что делать со слешами в пути.

2. Как в IDEA посмотреть свои правки кода в гите?

Помню, что раньше при работе в IDEA у меня слева снизу отображались мои изменения в меркуриал / гите. А тут тыркаюсь, тыркаюсь, историю изменения файла вижу, а мои правки — нет.

До этого мы обсуждали с куратором некоторые настройки идеи, и я сначала начала писать ей вопрос. И снова, как и в прошлый раз, я остановилась на середине вопроса с мыслью «а почему я пишу это ей?». Скопировала вопрос, стерла, и вставила в чат с ИИ (я общаюсь с @gpt3_unlim_chatbot):

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

3. Как привести текст в верхний регистр в GIGA?

Оригинальная публикация

Меня зовут Галина Коньшина, я работаю QA-инженером в Ozon Tech. Если вы думаете, что тестировщики только ищут баги, то вы заблуждаетесь. Мы не просто охотники за дефектами (хотя баги ловить умеем), мы те, кто ежедневно выходит на поле боя против самого изощрённого противника — нашего собственного мозга.

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

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

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

1. Как открыть gradle проект в IDEA

Мой основной проект собирается через Maven, я помню как его открывать в IDEA (у меня сейчас GIGA IDE, но по сути это та же IDEA) — через pom-ник.

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

Сделала скрин проекта в гите и задала вопрос:

- как открыть проект в идее, какой файл выбрать?

ИИ понимает даже убогую "русификацию", так что нет нужды писать ему правильное название — IDEA, он и так все понял и выдал подробную инструкцию.

2. Как настроить кодировку проекта

Следующая проблема — один проект работает с кодировкой UTF-08 по умолчанию, а другой — с windows-1251. Собственно, я смогла открыть в идее проект, но не смогла считать файлы:

Я как-то смутно помню, что это указывается где-то внутри настроек, но где?

Прошлась по документации "для новичков", сходу не нашла инструкцию. И пошла к своему куратору, которая помогает мне освоиться на проекте. Я уже начала писать вопрос:

- А напомни, плс, как поменять кодировку только для этого проекта?

А потом задумалась — а почему я спрашиваю об этом ЕЁ? Стерла сообщение и пошла к ИИ-шке ????

- (кинула скрин, который показан выше) Идея (точнее GIGA IDE CE 2025.1) открывает файлы не в той кодировке, надо вин-1251. Как настроить эту кодировку на весь проект?

И снова в ответ — подробная инструкция! Хотя за ИИ нужен глаз да глаз, а то он мне насоветовал глобальные настройки поменять:

Шаг 1. Настройка Windows-1251 на весь проект (и глобально)

1. Откройте настройки: нажмите Ctrl + Alt + S (или перейдите в меню File $⟶$ Settings).

2. В левой колонке перейдите по пути: Editor $⟶$ File Encodings (Кодировки файлов).

3. В правой части окна настройте три параметра:

* Global Encoding (Глобальная кодировка): выберите windows-1251.

* Project Encoding (Кодировка проекта): выберите windows-1251.

* Default encoding for properties files: если в .properties файлах тоже используется кириллица, выберите windows-1251.

4. Нажмите Apply (Применить), а затем OK.

Теперь все новые файлы будут создаваться и открываться в этой кодировке.

Пришлось уточнять:

 — «Global Encoding (Глобальная кодировка): выберите windows-1251». Что значит этот параметр? он только на этот проект будет действовать? я открываю в ИДЕ и другой проект, где уже кодировка утф-8

И тогда ИИ скорректировал свой ответ:

Отличный вопрос! Вы очень вовремя обратили на это внимание.

Если вы работаете с разными проектами (где один в UTF-8, а другой в Windows-1251), настраивать Global Encoding на Windows-1251 действительно не стоит, иначе это может сломать отображение символов в других проектах.

Вот в чем разница между этими параметрами и как правильно поступить в вашей ситуации:

В чем разница?

1.

Global Encoding (Глобальная кодировка) — влияет на всю среду разработки (IDE).

* Она применяется к файлам, которые вы открываете «просто так» (вне какого-либо проекта), и служит шаблоном по умолчанию для всех новых проектов.

* Если вы выставите здесь windows-1251, то при открытии другого проекта (где нет жестко сохраненных настроек кодировки) IDE может попытаться прочитать его файлы как Windows-1251, из-за чего «поплывет» уже UTF-8.

2.

Project Encoding (Кодировка проекта) — действует только на текущий открытый проект.

* Эта настройка сохраняется в скрытой папке .idea внутри папки вашего проекта (в файле encodings.xml).

* Она никак не влияет на другие проекты. Когда вы откроете другой проект, IDE прочитает его собственные настройки (например, UTF-8).

——————————

Как правильно настроить IDE под вашу ситуацию?

Чтобы один проект открывался в Windows-1251, а второй — в UTF-8, сделайте так:

1. Снова откройте настройки (Ctrl + Alt + S $⟶$ Editor $⟶$ File Encodings).

2. Global Encoding верните в UTF-8 (это современный стандарт, пусть он будет глобальным).

3. Project Encoding для вашего текущего проекта (где кракозябры) установите в windows-1251.

4. Нажмите Apply и OK.

При такой схеме:

• Проект с Windows-1251 будет открываться правильно (так как для него задана индивидуальная кодировка проекта).

• Проект с UTF-8 (и все остальные проекты) будут открываться в стандартной UTF-8, используя глобальную настройку. Никакого конфликта не возникнет!

3. Что значит ошибка?

При сборке проекта ошибка: Dependency requires at least JVM runtime version 25. This build uses a Java 21 JVM.

Но у меня 21 джава:

c:\core>javac -version
javac 21.0.11

c:\core>java -version
openjdk version "21.0.11" 2026-04-21 LTS
OpenJDK Runtime Environment Temurin-21.0.11+10 (build 21.0.11+10-LTS)
OpenJDK 64-Bit Server VM Temurin-21.0.11+10 (build 21.0.11+10-LTS, mixed mode, sharing)

ему нужна 25?

4. Что делает winget?

Ссылка на Хабр

Про типы границ я впервые услышала на тренинге Алексея Баранцева. Зачем они нужны? Да просто чтобы не забыть всё проверить. Написал чек-лист, потом проверяешь себя:

— Все учел? Вот эти классы эквивалентности, какие границы логические? А какие технологические? ...

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

Алексей дал нам тогда про такую типизацию границ:

• Физическая — которую физически нельзя преодолеть.

• Логическая — ограничение, накладываемое логикой, не программой.

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

• Произвольная — ограничение, наложенное аналитиком или заказчиком.

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

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

Так что в моей классификации есть всего три типа границ (сокращенно ЛТП):

1. Логическая — ограничение, накладываемое логикой, не программой.

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

3. Произвольная — ограничение, накладываемое аналитиком или разработчиком.

Рассмотрим каждую из них!

Логическая граница

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

Самые важные и базовые границы:

• Ноль — проверяем всегда и везде!

• Один — а вот это неочевидно бывает, обычно только ноль смотрят, а есть еще разница «один-много».

Эти границы надо смотреть всегда. А какие бывают другие? Посмотрим на примерах:

1. В минуте 60 секунд

Даже если система дает ввести больше, мы все равно проверяем 60.

Допустим, разработчик поставил ограничение на поле ввода секунд — можно ввести максимум 2 числовых символа. У нас получаются интервалы:

• 0 — 60

• 60 — 99

При этом 0 и 60 — логические границы. Логично, что время НЕ может быть отрицательным (в физическом мире ну никак, даже если программа позволяет ввести такое значение). Также логично, что секунд будет максимум 60, иначе это уже следующая минута.

Что делает интервал «60 — 99» очень интересным для проверки: что будет, если я введу 70 секунд? Система пересчитает это как 1 минуту и 10 секунд? В любом случае это уже разные классы эквивалентности: «нормальное количество секунд» и «больше, чем минута». Проверяем оба + границу между ними.

А вот в числе 99 никакой логики нет. Ее просто такой сделал разработчик. Завтра он передумает и сделает границу в 999 — и что, изменится логика? Нет. Логика от прихоти разработчика не меняется. Какое бы ограничение он не поставил, у нас остаются границы 0 и 60. А вот 99 — это сплошной произвол, к логике отношения не имеет.

2. Строки отрицательной длины не бывает

Если у нас есть строковое поле, то самая очевидная граница — ноль. Логично, что символов всегда будет больше нуля, меньше мы ну никак ввести не сможем. Поэтому всегда проверяем:

• Пустое поле (ноль) — логическую границу.

• Один символ (один) — пограничное значение.

• Один пробел — это не то же самое, что один любой символ, поэтому рекомендую проверить.

Даже если разработчик ставит ограничение «имя может быть от 3 до 10 символов», это не отменяет границу в нуле и мы ее все равно проверяем. А потом уже смотрим границы по ТЗ.

3. Количество книг или платьев в заказе — положительное целое число

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

• 0 — мы не можем заказать «минус одно платье»;

• Целое число — мы не можем заказать дробное.

Конечно, с нулем проще: мы знаем границу, знаем пограничные значения (-1 и 1), понимаем классы эквивалентности (до нуля и после).

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

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

4. Возраст — тоже положительное число

Отрицательного возраста быть не может — это логично. Когда человек рождается, то ему уже 0 лет, 0 минут, сколько-то секунд. Когда он ещё в животике, это тоже не «минус 5 месяцев ему» — это «3 месяца беременности мамы».

Дробное значение у возраста бывает — «1.5 годика», например. А вот отрицательное — нет.

Итого!

Запомните правило — логика от прихоти разработчика НЕ меняется.

Если разработчик изменил в программе значение и граница поменялась — значит, она была НЕ логическая. А чтобы найти логическую, включаем мозг и думаем: а каким бывает (или не бывает) наше поле? Абстрагируясь от того, что написано ТЗ. ТЗ у нас пойдет отдельно.

Логика может разделять разные классы (дробное / целое число), а может быть конкретным значением. И если вы нашли число, то всегда проверяйте:

• Ноль — не ноль

• Один — много. 

Технологическая граница

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

Например, при попытке запихать в integer больше, чем 2 147 483 647. И так как перфокарты уже давно в прошлом, то сейчас поиск технологической границы — это попытка вставить МНОГО данных в поле. 

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

• Нажать «9» и держать — чтобы получилось «9999999999999999999999999999...» И так сколько влезет.

• Использовать специальные инструменты, например, Perlclip.

См также:

Как сгенерить большую строку, инструменты + помощь ИИ, разумеется

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

И кстати, если в поле нельзя ВВЕСТИ с клавиатуры что-то, это еще не значит, что «плохое» значение туда нельзя ВКОПИПАСТИТЬ. Обязательно пробуйте.

А если говорить про ограничение на длину поля, так это вообще обычно простейший maxlengh, который легко обходится.

Ладно, хватит теории, посмотрим на примерах.

• Типы полей в БД — максимальное число, которое можно туда сохранить или длина поля (в оракл для строки это 5000 символов). При тестировании самой БД это произвол, а теперь это ограничение технологии.

• Путь к файлу — операционная система указывает допустимость символов или длину пути.

• Автор: Арун Вишванатан (Arun Vishwanathan)
  Оригинал статьи
  Перевод: Ольга Алифанова

  Проблема: отладка билдов в быстро меняющемся мире

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

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

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

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

  ]]> https://software-testing.ru/library/testing/test-analysis/4495-finding-bugs-faster-a-smarter Sun, 21 Jun 2026 23:00:00 +0300 Михаил Ланкин, автор статей команды ТестОпс
  Оригинальная публикация

  Нестабильные (flaky) тесты создают постоянные трудности для тестировщиков. Такие тесты не отражают состояния тестируемой системы и подрывают доверие к тестовому набору.

  Вооружившись лучшими практиками, нестабильность можно свести к минимуму, но полностью избавиться от неё крайне трудно. Чтобы лучше её контролировать, нужны инструменты, позволяющие выявлять нестабильные тесты — например, Allure Report. В этом руководстве мы посмотрим, как Allure работает с нестабильными тестами:

  • Исследуем, как устроена история тестов

  • Разберёмся, как история позволяет определять нестабильные тесты

  • Настроим перезапуск тестов

  Эту функциональность мы рассмотрим на примере PyTest, но все те же принципы работают и с другими фреймворками.

  ]]> https://software-testing.ru/library/testing/testing-automation/4522-allure- Thu, 18 Jun 2026 23:00:00 +0300

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

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

  

  Мы пришли к выводу, что искусственный интеллект не думает за QA‑инженера и не понимает продукт так, как понимает его человек – сколько бы спецификаций, схем и снимков экрана в него ни загрузили. Зато он эффективно берёт на себя рутину и помогает управлять большими объёмами данных. Но без грамотного управления ИИ может привести к нежелательным и даже печальным результатам.

  Проверьте по двум критериям, стоит ли поручать задачу ИИ?

  Прежде чем поручить задачу модели, мы оцениваем её по двум ключевым параметрам – не по «крутости» модели или хайповости подхода, а по реальному эффекту:

  1. Цена пропущенной ошибки. Что будет, если инженер не заметит недочёт? Например, некорректный набор тестовых данных можно перегенерировать за минуту, а вот пропущенный сценарий приёмки в платёжном модуле может привести к финансовым потерям для клиентов и последующим разбирательствам.
  2. Сложность проверки результата. Сколько времени и ресурсов потребуется, чтобы убедиться, что ИИ не выдумала ответ? Если проверка занимает меньше времени и сил, чем самостоятельное выполнение задачи, – решение оправдано. Если же проверять результат так же долго, как делать работу вручную, то игра не стоит свеч.

  Мода на инструменты приходит и уходят, а правильные вопросы остаются: вот что действительно важно.

  

  Четыре слоя контроля, без которых мы не отдаём задачи нейронке

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

  Задача проходит все четыре этапа. Если не проходит любой из слоёв – к клиенту она не идёт.

  Первый слой проверки – юридический, и его часто недооценивают. Согласно 152‑ФЗ, обработкой персональных данных считается любая операция с ними, включая анализ – неважно, выполняет её человек или алгоритм. Получается, загрузка клиентских данных в стороннюю нейросеть уже считается обработкой со всеми вытекающими последствиями. Поэтому ещё до формулировки первого запроса мы определяем, какие данные допустимо передавать модели и в каком контуре их можно использовать. Остальные три слоя – про среду, про обязательную проверку человеком и про измерение эффекта уже после внедрения.

  Подробно разбираем матрицу решений

  Левый нижний угол матрицы

  Ошибиться не страшно, проверить дёшево. Здесь ИИ работает как добросовестный помощник, а инженер лишь сверяет результат.

  Подготовка синтетических тестовых данных
  риск низкий

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

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

  Оформление и приведение в порядок баг‑репортов
  риск низкий

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

  Заготовки кода для автотестов
  риск низкий–средний

  Скелеты объектов страниц (шаблон Page Object), фикстуры, фабрики данных, параметризованные таблицы, заготовки клиента к API – всё это скучно писать, но легко проверить: код либо проходит сборку и статический анализ, либо нет. Важно отделять: структуру можно доверить модели, а смысл оставляем за собой. Просьба «напиши заготовку объекта страницы для этого экрана» безопасна, а вот «напиши тесты на оплату» – уже из другой категории.

  Перекладка форматов и переводы
  риск низкий

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

  Группировка сбоев и разбор журналов
  риск низкий–средний

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

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

  Середина матрицы

  Цена ошибки уже немалая, а на проверку нужно время – вот почему без человека не обойтись. Зато скорость и охват растут так, что отказаться от этого в 2026 году – всё равно что сознательно тормозить развитие.

  Проектирование тест‑кейсов по требованиям
  риск средний

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

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

  Генерация автотестов
  риск средний

  ИИ преобразует ручные кейсы или спецификацию в заготовки для Playwright, Cypress, pytest – со структурой, шагами и черновиками проверок. Дальше автоматизатор дорабатывает: исправляет локаторы, добавляет осмысленные проверки, устраняет нестабильность.

  

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

  Самовосстановление локаторов
  риск средний

  Раньше, если на клиентской части меняли идентификатор кнопки, половина тестов сразу переставала работать. Приходилось в спешке всё исправлять. Сейчас всё иначе: когда тест падает, агент анализирует структуру страницы (DOM). Например, видит: идентификатор другой, но кнопка по‑прежнему в блоке оплаты и подписана «Купить» – и тест продолжает работать. Благодаря этому расходы на поддержку снижаются – в нашей практике примерно на 40 %.

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

  Регрессия по критичности изменений
  риск средний–высокий

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

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

  

  Риск пропустить важный тест всё же есть. Решается это просто: полную регрессию не отменяют – её переносят на ночь или выходные по расписанию. 

  Анализ первопричин и сортировка дефектов
  риск средний

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

  Контроль изменений в API и поддержка документации
  риск средний

  По описанию интерфейса (OpenAPI/Swagger) искусственный интеллект формирует проверки запросов и ответов на соответствие контракту. Сюда же относятся тест‑планы и отчёты – из сырых заметок, чек‑листов, идей для исследовательского тестирования. Идеи безопасны: это всего лишь предложения, а не готовые решения. Исполняет и оценивает их человек.

  Правый верхний угол матрицы

  Либо ошибиться дорого, либо проверить так же тяжело, как сделать самому. В таких случаях ИИ в QA – всего лишь ассистент, а последнее слово всегда за человеком.

  • Финальная приёмка и решение о выпуске. Это ответственность, а ответственность не делегируется роботу. ИИ готовит сводку, но заключение даёт тестировщик.
  • Удобство и продуктовое чутьё. искусственный интеллект не скажет: «Этот путь к корзине раздражает» или «Здесь пользователь растеряется» – он не чувствует неудобств. Опаснее всего даже не молчание, а ложная уверенность: получили вывод, что всё в порядке и расслабились. 
  • Закрытые данные в публичных зарубежных сервисах. Загрузить внутреннюю архитектуру или клиентские данные в публичный иностранный сервис – нарушение 152‑ФЗ. Если данные чувствительные, используйте только корпоративный сервис с хранением в РФ либо локальные модели в своём контуре.
  • Высокорисковые домены. Платёжные операции, медицина, промышленный софт, где цена сбоя – деньги или жизни. Черновик кейсов можно сгенерировать, но доверять нейросети решение нельзя. 
  • Стратегия тестирования и оценка продуктовых рисков. Работа с контекстом, которого у нейронки нет: историей проекта, политикой, реальными болевыми точками бизнеса. Шаблонная стратегия выглядит убедительно лишь до первого столкновения с реальностью. 
  • Глубокая доменная логика на дырявой документации. Чем больше пробелов в описании, тем увереннее ИИ заполнит их правдоподобной ерундой. Здесь она опаснее всего – ошибается очень убедительно. 
  • Безопасность как замена аудиту и проверке на проникновение. Первый проход по типовым уязвимостям – пожалуйста. Заключение «защищено» – нет.

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

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

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

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

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

  Мы создали поверх k6 переиспользуемую обвязку. Сначала несколько месяцев тестировали её на собственных продуктах, а затем – с согласия клиентов и после анализа их систем – стали предлагать им. Предварительно разбирались, какие данные допустимо использовать.

  Логика такая:

  • Профили нагрузки лежат в конфигурации: дымовая, лёгкая, средняя, тяжёлая. Нужна нарастающая, трапециевидная, пиковая или постоянная нагрузка – берётся готовый профиль или дописывается свой.
  • Сценарии задаются отдельно, кодом: какие конечные точки API задействуются и в каком порядке.
  • Пороги – это целевые показатели (SLA). Например, если раздел должен открываться за 4 секунды, выставляется соответствующий порог. Прогон покажет, уложились ли в него – а то бывает, что открывается за 12 секунд.
  • Запуск выполняется одной командой или по событию в конвейере. Прогнали нужным профилем – получили отчёт.
  • Отчёт формируется автоматически: включает окружение, дату прогона, инструмент, конфигурацию, число запросов и долю успешных, графики пропускной способности и нарастания пользователей, перечень задействованных конечных точек.
  • Выводы генерирует нейросеть: она анализирует метрики и выдаёт понятные формулировки – где произошла деградация, где достигнут порог, где возникли ошибки сервера. Важный момент для бюджета: для такого анализа не нужна самая дорогая модель – с задачей справится и более простая, с достаточным контекстом.

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

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

  Честная граница применимости
  
  Для среднего и средне‑крупного веба, мобильных приложений и серверных частей обвязка работает отлично: например, портал с требованием «каталог грузится за N секунд» тестируется быстро и эффективно.
  
  А вот сложную систему из десятка подпроектов, тесно связанных с разными платформами и с нетривиальной авторизацией, так просто не протестировать — здесь нужна ручная работа для каждого компонента.
  
  Поэтому перед запуском мы всегда анализируем стек: на чём построена система, как устроена авторизация и какие элементы действительно стоит нагружать. Цифры в отчёте достоверные (это данные от k6), но пороги задаёт QA-инженер, а выводы ИИ – лишь первый этап анализа, который обязательно подтверждает человек.

  Объясняем на цифрах: какой эффект даёт ИИ в QA?

  Бизнес словам не верит. Вот формула окупаемости (возврата инвестиций), которую можно применить к вашему проекту:

  Окупаемость (%) = (Годовая экономия − Годовые затраты на ИИ) / Годовые затраты × 100%
  
  Годовая экономия = (Часы «до» − Часы «после») × Ставка часа × Раз в год
  
  Годовые затраты = Подписка/токены за год
                  + Разовая настройка × Ставка (распределённая по числу прогонов)
                  + Часы на проверку результата × Ставка × Раз в год
                  + Обучение команды

  Главное, что упускают в красивых презентациях, – скрытые затраты. Их три, и они съедают выгоду:

  1. Время на проверку. Это самая большая статья расходов: ИИ сгенерировала за минуту, а инженер проверял два часа – и эти два часа идут в расчёт.
  2. Настройка и отладка формулировок. Разовая затрата, которая распределяется на все будущие прогоны.
  3. Контроль за нейросетью и стоимость инцидента. Это премия за риск: что будет, если БАГ пропустят? На высокорисковых задачах эта статья перевешивает всё остальное – поэтому такое не делегируют.

  Расчёты по российским ставкам (полная стоимость часа): QA Middle – около 1 200 ₽/ч, AQA – от 1 500 ₽/ч (для senior – 2 500 ₽/ч). Цифры округлены – можете подставить свои данные.

  ---

  1. Проектирование тест‑кейсов нового модуля: 40 пользовательских историй, всего около 250 кейсов.

  Было: 250 × 15 мин = 62,5 ч × 1 200 ₽ = 75 000 ₽ за модуль.
  Стало: генерация – около 1 ч, проверка и правки – 250 × 5 мин ≈ 21 ч, плюс час на формулировки, итого ≈ 22 ч × 1 200 ₽ = 26 400 ₽. Затраты на токены – 300–800 ₽.

  Экономия: ≈ 48 000 ₽ за модуль, сокращение времени на 65%. При восьми модулях в год – около 384 000 ₽. Учитываем, что 13% кейсов невалидны – именно на них уходит дополнительное время проверки.

  2. Цикл нагрузочного тестирования при подготовленной инфраструктуре.

  Было: около 2 рабочих дней (16 ч) на постановку, прогон и анализ × 2 500 ₽ = 40 000 ₽ за цикл (каждый раз с нуля).
  Стало: около 2 ч на прогон с отчётом × 2 500 ₽ = 5 000 ₽. Анализ от простой модели обходится почти бесплатно.

  Экономия: ≈ 35 000 ₽ за цикл. При тестировании раз в спринт (24 раза в год) – около 840 000 ₽. Минус разовая адаптация под проект – примерно день работы (20 000 ₽). Окупаемость – в первом квартале.

  3. Поддержка автотестов (самовосстановление локаторов), набор – около 800 тестов.

  Было: примерно 15 ч/спринт на починку локаторов и устранение нестабильности × 24 спринта = 360 ч/год × 1 500 ₽ = 540 000 ₽.
  Стало: самовосстановление сокращает ручную починку на ~40%.

  Экономия: около 216 000 ₽/год. Затраты – инфраструктура агента и проверка предложенных правок.

  ---

  

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

  Сводная таблица по передаче QA-задач нейросетям

  Задача	Режим	Типовой эффект	Риск	Слои контроля
  Синтетические данные	Передать	Часы в минуты, без риска утечки	низкий	1, 3
  Оформление баг‑репортов	Передать	Единообразие, минус рутина	низкий	3
  Заготовки автотестов	Передать	Минус ручная рутина	низкий/средний	2, 3
  Группировка сбоев и журналов	Передать	Минус часы анализа	низкий/средний	3
  Проектирование тест‑кейсов	Ускорить	−50–60% фазы подготовки	средний	3, 4
  Генерация автотестов	Ускорить	Меньше ручного написания	средний	3, 4
  Самовосстановление локаторов	Ускорить	−40% поддержки	средний	3
  Регрессия по критичности изменений	Ускорить	Заключение за минуты	средний/высокий	3, 4
  Анализ первопричин	Ускорить	Время локализации меньше в 2–3 раза	средний	3
  Нагрузочное (k6 + анализ модели)	Ускорить	2 дня → 2 часа за цикл	средний	1, 3, 4
  Приёмка или решение о выпуске	Избегать	—	высокий	только человек
  Удобство, продуктовое чутьё	Избегать	—	высокий	только человек
  Закрытые данные в публичный сервис	Избегать	—	высокий	барьер на слое 1
  Платежи/медицина/ промышленность	https://quality-lab.ru/blog/kakie-zadachi-v-testirovanii-pora-otdat-ii-chtoby-poluchit-rezultat-a-ne-novye-problemy/ Thu, 18 Jun 2026 18:09:03 +0300 Автор: Ужвал Кумар Сингх (Ujjwal Kumar Singh) Оригинал статьи Перевод: Ольга Алифанова Сигнал к пробуждению Я занимаюсь тестированием программного обеспечения уже три года. Тестировал разные типы приложений, следовал всем профессиональным практикам, выполнял тест-кейсы и отмечал все пункты. Но иногда я не думал о том, что делаю. Я просто механически проходил шаги, выполняя тесты как машина. И именно так пропустил критический баг, который заблокировал доступ к платформе как новым, так и существующим пользователям. Этот баг попал в продакшен, и по мере развития ситуации стало понятно, что процессом тестирования и выбранными стратегиями недовольны. Через пару дней почта каждого члена команды взорвалась жалобами клиентов, и менеджер посмотрел тем самым взглядом. Все знают этот взгляд. Он не злой. Просто… разочарованный. Следующие несколько дней я прокручивал всё это в голове, пытаясь понять, где ошибся. Все сценарии были протестированы правильно, все шаги выполнены. И всё же я полностью упустил, как реальный пользователь мог бы взаимодействовать с системой. Тогда ко мне пришло осознание: тестирование велось мной механически. Но программное обеспечение создаётся для людей. ]]> https://software-testing.ru/library/around-testing/processes/4496-breaking-the-autopilot Tue, 16 Jun 2026 23:00:00 +0300 Автор: Павлович Евгений Эта статья основана на моем опыте и, надеюсь, поможет быстрее стартовать коллегам в ручном тестировании внутренних покупок в Android-приложениях. Это не исчерпывающее руководство, просто хочется дать стартовые инструкции, чтобы можно было увереннее начать. IAP - важный элемент монетизации мобильных приложений. К примеру, частый сценарий, предложение подписки через paywall. Корректная работа этого механизма критична как для бизнеса, так и для пользовательского опыта. ]]> https://software-testing.ru/library/testing/mobile-testing/4520-in-app-purchases Sun, 14 Jun 2026 23:00:00 +0300 Мы много работаем с финтехом, ритейлом и компаниями из смежных сфер – то есть как раз с теми, кого цифровой рубль затрагивает сильнее всего. Поэтому подготовку начали ещё в начале 2026 года, понимая, что июль и август будут авральными. Дедлайн внедрения – 1 сентября 2026 года, а подключение к платформе цифрового рубля – это не просто «прикрутить ещё одну кнопку оплаты». И вот тут важная штука про то, как устроена «Лаборатория Качества». Казалось бы, мы просто тестировщики: дайте требования – проверим по требованиям. Но это не наш подход. Чтобы клиенты получили действительно топовое тестирование, а появление цифрового рубля не зааффектило их бизнес (а в идеале – помогло), мы за это полугодие вынесли мозг всем знакомым финтех-коллегам, сходили даже на вебинары для бухгалтеров, перечитали законы и стандарты Банка России и собрали внушительную методологическую базу. Всю методологию мы, конечно, не раскроем. Но в этой статье – практическая выжимка, которая будет особенно полезна CEO, руководителям продуктов и разработки. Она поможет понять, что и как нужно протестировать перед запуском в прод. Поехали! Почему стандартного набора проверок для цифрового рубля недостаточно? Цифровой рубль – третья форма национальной валюты (помимо наличной и безналичной). Его эмитент и оператор платформы – Банк России. На первый взгляд может показаться, что это просто добавление ещё одного способа оплаты, но для команды разработки ситуация выглядит иначе – и вот почему. Деньги клиента не на вашем балансе. Цифровые рубли учитываются в реестре ЦБ, а банк выступает лишь интерфейсом – через ДБО или мобильное приложение пользователи авторизуются и инициируют операции. Появляется внешний источник данных, с которым ваш контур должен полностью совпадать – без малейших расхождений. Это сразу выдвигает на первый план сверку данных, идемпотентность и обработку незавершённых операций. Деньги программируемые. С помощью смарт‑контрактов можно заключать самоисполняемые сделки и ограничивать использование средств определёнными целями. Это принципиально новые сценарии, где нужно тестировать не только то, что должно сработать, но и то, что работать не должно. Плотный регуляторный контур. 115‑ФЗ, идентификация через ЕСИА, электронная подпись, банковская тайна, лимиты и обязательное право выбора способа оплаты. Из‑за этого к обычному функциональному тестированию добавляется обязательный этап – комплаенс‑тестирование. Тест‑базис постоянно меняется. платформа развивается, стандарты регулярно обновляются. Ключевые изменения вступают в силу 1 июля 2026 года – буквально накануне дедлайна. То есть вы стабилизируете релиз против движущейся мишени. Если коротко: цифровой рубль превращает простую проверку функций в управление расчётными и регуляторными рисками. А это совсем другие объём и глубина тестирования. Какие требования ЦБ нужно проверить до запуска цифрового рубля? Прежде чем составлять тест‑кейсы, зафиксируйте тест‑базис. В случае с цифровым рублём это не только ваше внутреннее ТЗ, но и пакет стандартов платформы от Банка России – именно по этим документам вы проверяете соответствие. Они особенно важны для тех, кто запускается в первой волне. Документ Зачем он тестировщику «Требования операционно-технологического взаимодействия на платформе цифрового рубля» (актуальная редакция применяется с 01.07.2026) Главный технический контракт интеграции: как ваш контур общается с платформой. Базис интеграционных и сверочных тестов. «Альбомы распоряжений и сообщений» Форматы и структура сообщений/распоряжений. Из них растут позитивные, негативные и граничные кейсы для каждого типа операции. «Спецификация на программный модуль» Требования к программному модулю участника. Важно для проверки совместимости и корректной обработки операций. «Порядок подключения участника платформы» Регламент подключения. Влияет на сценарии онбординга, выдачи доступа, приостановки и возобновления. «Требования и рекомендации к пользовательским интерфейсам…» (актуальная версия – с 01.07.2026) Как должны выглядеть и вести себя клиентские экраны операций. Базис для юзабилити- и комплаенс-проверок (включая право выбора способа оплаты). «Порядок оценки влияния клиентского приложения на криптографические средства» (опубликован в мае 2026) Прямо касается ИБ-тестирования: клиентское приложение не должно нарушать требования к встроенным СКЗИ. Тарифы оператора платформы Нужны для проверки корректности расчёта и удержания комиссий (см. раздел про комплаенс). Главный подводный камень – версионирование стандартов. Зафиксируйте в стратегии тестирования, по каким именно редакциям (с какими датами вступления в силу) вы проверяетесь, и предусмотрите перепрогон при их обновлении. Иначе вы пройдёте сертификацию по старой версии, а в прод выйдете уже с новой. 9 аспектов тестирования при подготовке к внедрению цифрового рубля А теперь разберём по слоям, что тестировать, как мы это делаем методологически, и на какие специфические грабли наступают компании чаще всего. 1. Функциональное тестирование операций Самый понятный слой – и потому его часто недооценивают. Проверять, открывается ли кошелёк и проходит ли перевод, – это не покрытие, а разминка. Полный жизненный цикл операции с цифровым рублём охватывает открытие и закрытие кошелька, пополнение с безналичного счёта, переводы между физлицами (C2C), оплату в пользу бизнеса (C2B), расчёты между юрлицами (B2B), оплату по универсальному QR‑коду, а также возвраты, частичные возвраты и отмены операций. Методология Построить матрицу состояний операции: от инициирования до завершения, включая варианты «отклонена», «зависла» и «возвращена». Сосредоточьтесь на тестировании переходов между состояниями, а не отдельных элементов интерфейса. Для каждого типа операций – будь то C2C, C2B, B2B или возвраты – прописать позитивные, негативные и граничные сценарии. Опираться на альбомы сообщений ЦБ. Важно не просто проверять, что отображается на экране, а убедиться в согласованности трёх элементов: данных, доступных клиенту, информации в вашей системе и подтверждения от платформы. Отдельно протестировать ситуации, когда операция прерывается на полпути – например, если связь оборвалась между подтверждением и исполнением. В таких случаях нужно чётко понимать, как система обрабатывает «зависшие» деньги. Подводные камни и рекомендации Возвраты – это не просто обратный перевод. Нужно отдельно проработать разные сценарии: частичный возврат, возврат после смены статуса или возврат по операции с истёкшим контекстом. Не стоит рассчитывать, что они будут работать по той же логике – пропишите каждый случай явно. Округление и копейки. Любые расчёты – будь то комиссия, частичный возврат или дробление суммы – могут привести к расхождениям. Тестируйте граничные значения и сверяйте итоговые суммы с данными реестра. Идемпотентность с точки зрения пользователя. Если человек случайно дважды нажмёт на кнопку, обновит страницу или отправит запрос повторно из‑за таймаута, это не должно приводить к созданию второй операции. Такой сценарий нужно проверять как обычную функциональность, а не только с технической стороны. 2. Тестирование смарт-контрактов и «окрашенных» средств Смарт‑контракт на платформе цифрового рубля – это встроенный алгоритм, который автоматически выполняет условия сделки, когда наступают заданные условия. Ещё есть механизм «окрашивания» средств: он позволяет ограничить использование бюджетных и контрактных денег – тратить их можно только на определённые цели. Для бизнеса это открывает возможности автоматизировать сложные сделки: например, работу с эскроу‑счетами, поэтапную оплату или расчёты по госконтрактам. А вот для тестировщика такая функциональность – серьёзный вызов. Методология Разложить смарт-контракт на условия и события. Для каждого условия проверьте два момента: срабатывает ли контракт, когда условие выполнено, не выполняется ли он, если условие не соблюдено. Покрыть весь жизненный цикл: создание, активация, частичное исполнение, полное исполнение, истечение срока, отмена или возврат. Проверить, как система работает в нестандартных ситуациях. Например, если событие‑триггер поступает дважды, одновременно от нескольких источников или с опозданием. Для «окрашенных» средств. Смоделировать попытки использовать их не по назначению. Система должна блокировать любые нецелевые расходы. Подводные камни и рекомендации Самый дорогой баг в этой системе – ложное исполнение: когда деньги уходят, хотя условие не выполнено. Это не просто мелкий недочёт – это серьёзный финансовый инцидент. Поэтому негативные сценарии стоит проверять даже тщательнее, чем позитивные. Учитывайте фактор времени. В сделках с дедлайнами, отсрочками и разными периодами нужно специально управлять временем на тестовом стенде – например, подменять время или ускорять таймеры. Иначе просто не получится полноценно проверить, как работает истечение срока. Окрашивание средств – это не обычный перевод. Важно убедиться, что ограничения по целевому использованию сохраняются на всех этапах цепочки операций и не сбрасываются после первой транзакции. 3. Интеграционное тестирование Здесь обычно и возникают основные сложности. У вас как минимум четыре ключевых шва: ваш контур и платформа ЦБ, ваш контур и НСПК/СБП с универсальным платёжным QR‑кодом, клиентское приложение и ваш бэкенд, а также касса или терминал и эквайринг. Каждый такой стык – это отдельная интеграция, у которой свои версии, таймауты и форматы сообщений. Из‑за этого легко появляются расхождения и ошибки: то формат не совпадает, то время ожидания истекает раньше нужного, то версии систем не согласуются между собой. Важно тщательно проверять взаимодействие на каждом этапе. Методология Зафиксировать контракты: версии стандарта операционно-технологического взаимодействия и альбомов сообщений, действующие на дату релиза. Поднять стенд с управляемой эмуляцией смежных систем (моки/стабы по контракту), чтобы воспроизводить редкие ответы платформы: ошибки, отказы, нестандартные коды, задержки. Применять контрактное тестирование на стыке версий – чтобы обновление стандарта не ломало интеграцию молча. Прогонять сценарии «по шву» и сквозные (е2е), отдельно проверяя асинхронные статусы, таймауты, ретраи и идемпотентность. Для ритейла нужен отдельный блок проверок: взаимодействие кассы, эквайринга, универсального QR‑кода и фискализации чека (ККТ). При оплате цифровым рублём продавец обязан использовать ККТ как обычно, поэтому важно проверять чек и расчёт вместе – как единую цепочку операций. Подводные камни и рекомендации Недоступность платформы – это штатный сценарий. Тестируйте поведение при таймаутах и отказах смежной системы: что видит клиент, что попадает в очередь, как потом досверяется. Универсальный QR обязан давать выбор. После сканирования пользователь должен получить варианты: СБП, сервис банка или цифровой рубль. Проверьте, что выбор действительно работает и ни один из способов не выбирается автоматически в обход правил. Зависимость от готовности банка. Торговая компания не сможет принимать цифровой рубль, пока её банк‑эквайер не обеспечит техническую поддержку этой функции. Имейте это в виду при планировании интеграционного тестирования: возможно, тестовый контур банка будет готов позже вашего. Не тестируйте только успешный сценарий по сети. Самые дорогие дефекты живут в обрывах, частичных ответах и рассинхронах. 4. Тестирование сверки и расчётов (реконсиляция) Этот слой для обычного продукта почти не важен, а для цифрового рубля – критически необходим. Поскольку деньги учитываются в реестре ЦБ, а ваш контур лишь обрабатывает распоряжения, он должен полностью совпадать с реестром оператора. Любое расхождение может привести к тому, что деньги реального клиента окажутся не там, где нужно. Методология Определить контрольные точки сверки: по каждой операции и по итоговым реестрам за период. Тестировать идемпотентность по сквозному идентификатору операции: убедиться, что повтор запроса не создаёт второй платёж и не задваивает запись. Моделируйте незавершённые и «зависшие» операции – и проверяйте, что система корректно их завершает: исполняет или откатывает, – без появления дублирующих записей. Проверять расхождения намеренно: внести рассинхрон на стенде и убедиться, что он детектируется и поднимает алерт, а не растворяется. Подводные камни и рекомендации «У нас же всё прошло» – самообман. Операция может пройти у вас и не дойти до платформы (или наоборот). Без сверки вы узнаете об этом от клиента, а это худший канал обратной связи. Главный кошмар – двойное списание. Сценарии ретраев и параллельных запросов проверяйте до прода, а не после первой жалобы. Возвраты и частичные операции усложняют сверку. Убедитесь, что система корректно учитывает и такие случаи, а не только полноценные платежи. 5. Нагрузочное и стресс-тестирование Этот вопрос особенно актуален для ритейла и электронной коммерции. Когда вы добавляете оплату через универсальный QR‑код и цифровой рубль, приходится вносить изменения в код – причём именно в той части системы, где и так максимальная нагрузка. А если площадка упадёт во время распродажи, это приведёт к прямой потере выручки и удару по репутации. Методология Строить нагрузочный профиль исходя из пиковых дней, а не обычных. Учитывайте всплески оплат, длительные задержки и одновременные подтверждения – всё, что типично для напряжённых периодов. Проверять, как система ведёт себя при резком росте нагрузки – например, если трафик увеличится вдвое. Выясните, какой компонент откажет первым, и оцените реакцию системы: ограничится ли она снижением производительности или приведёт к каскадному отказу. Совместно с DevOps искать узкие места: БД, очереди, внешние интеграции, фискализация – и проверять их под нагрузкой по отдельности. Использовать реалистичную гео-распределённую нагрузку. Мы, например, генерируем нагрузку из 40 регионов России без симуляции присутствия – так профиль ближе к реальному наплыву покупателей. Подводные камни и рекомендации «Прошлый год пережили» – ещё не гарантия, что справимся в новом. Новый платёжный путь и рост трафика меняют картину. Нужен свежий замер запаса прочности, а не воздушный замок на воспоминаниях. Простая арифметика для финдиректора. Один час простоя в пик почти всегда стоит дороже годового бюджета на нагрузочное тестирование. Это не запугивание, это сравнение двух чисел. Интеграции под нагрузкой ведут себя иначе. Система может отлично работать с единичным запросом – и дать сбой при тысяче одновременных. Поэтому тестируйте швы компонентов именно в пиковых условиях. 6. Тестирование информационной безопасности Расчёты цифровым рублём опираются на электронную подпись и сертифицированные криптосредства. При этом контроль за операциями становится строже: меры против отмывания денег распространяются и на цифровой рубль, а Росфинмониторинг получает прямой доступ к данным об операциях. Поэтому тестирование информационной безопасности здесь нельзя оставлять на последний этап – оно должно быть в приоритете. Методология Проверить работу с ЭП и управление ключами/сертификатами: их выпуск, использование, отзыв, истечение срока действия, а также поведение системы при невалидной подписи.  Оценить влияние клиентского приложения на встроенные криптосредства – по соответствующему стандарту платформы: приложение не должно нарушать требования к СКЗИ. Проверять целостность смарт-контрактов и права доступа к их запуску – ЦБ прямо называет это приоритетом ИБ. Протестируйте систему на устойчивость к мошенническим социально‑инженерным атакам: например, к подмене реквизитов, навязыванию перевода или попыткам выполнить операцию без должной авторизации. Подводные камни и рекомендации Соц.инженерия мигрирует на новый инструмент. Как только появляется новый способ перевести деньги, мошенники придумывают способ их забрать. Сценарии «жертва сама подтверждает операцию» нужно отрабатывать заранее. Криптомодуль – это не «чёрный ящик, а часть системы. Важно проверять, как именно ваше приложение взаимодействует с ним, а не просто отмечать факт подключения СКЗИ. ИБ и комплаенс пересекаются. Ряд проверок (идентификация, управление доступом и аудит операций) – находится на их стыке. Не стоит распределять эти задачи между разными командами так, чтобы зона взаимодействия осталась без ответственного. 7. Комплаенс-тестирование Это тот самый слой, который традиционно «не входит в QA», пока не клюнет жареный петух. Мы недавно подробно писали про комплаенс-тестирование и про заблуждение о том, что это не вопрос QA-инженеров. Цифровой рубль – прекрасный пример: регуляции усложняются, и рядом с функциональным тестированием обязательным становится именно комплаенс. Методология Идентификация и доступ: открытие кошелька возможно только после идентификации по 115-ФЗ, при наличии учётной записи в ЕСИА и ключа электронной подписи. Тестируем позитивные и негативные ветки (нет идентификации, нет ЕСИА, невалидная подпись). Лимиты: на период пилота действует лимит пополнения кошелька физлица – 300 000 ₽ в месяц. Заводим граничные кейсы: 0, ровно лимит, лимит + копейка, исчерпание лимита частями из разных источников. Право выбора способа оплаты при сканировании универсального QR: проверяем, что выбор реально доступен, ничто не «предпрожато», нет тёмных паттернов, скрывающих опции. Тарифы: корректность расчёта и удержания комиссий – приём оплаты бизнесом (C2B) по утверждённому тарифу 0,3% от суммы, но не более 1 500 ₽; переводы между юрлицами (B2B) – фиксированно 15 ₽. Проверяем округление, лимит комиссии, кто и сколько платит. Персональные данные и банковская тайна: режим конфиденциальности операций, корректный отзыв согласия (а не заглушка, которая ставит флаг «удалено», оставляя данные на месте), минимизация собираемых данных – это 152-ФЗ. Фискализация: при оплате цифровым рублём продавец обязан применять ККТ в обычном порядке – проверяем выдачу корректного чека. Подводные камни и рекомендации Цена комплаенс-бага другая. Функциональный дефект стоит репутации и нервов. Комплаенс-ошибка в расчётах цифровым рублём – это предписания, штрафы и вопросы к самой возможности участвовать в платформе. Это блокер, рядом с которым меркнет большинство багов в логике. Функция «Удалить аккаунт» должна действительно удалять. Классическая ловушка: кнопка есть, а данные остаются. Проверяйте поведение системы, а не наличие текста про политику конфиденциальности. Тёмные паттерны прилетают на ровном месте. Например, автоматически выбранный способ оплаты или скрытая опция способны привести к претензиям со стороны потребителей из‑за нарушения их прав. Заранее проверяйте, чтобы интерфейс не вводил пользователей в заблуждение. 8. Тестирование офлайн-режима Одно из обещанных преимуществ цифрового рубля – возможность оплачивать покупки без интернета, что особенно важно для отдалённых районов. Технология пока развивается, поэтому к ней предъявляют повышенные требования по безопасности. Офлайн‑платёж по сути означает отложенную синхронизацию данных, а она, в свою очередь, может привести к конфликтам, дублированию операций и спорным ситуациям. Методология Главный класс сценариев – защита от двойного списания: одни и те же средства не должны быть потрачены дважды в офлайне до синхронизации. Тестировать синхронизацию постфактум: восстановление связи, разрешение конфликтов, порядок применения операций. Проверять граничные состояния устройства: разряд, потеря данных, рассинхрон часов, частичная синхронизация. Подводные камни и рекомендации Конфликт синхронизации – норма, а не исключение. Если произошли две офлайн‑операции, а потом обе дошли до системы, результат должен быть предсказуемым. Иначе на кассе возникнет спор с клиентом.  Не стоит запускать офлайн‑режим только потому, что такая возможность прописана в стандарте. Если фича сырая, лучше явный отказ, чем тихий дубль списания. 9. Регрессионное тестирование и автоматизация Расчётный контур меняется часто, а ломаться ему нельзя. Без стабильного автоматизированного регресса каждый релиз превращается в лотерею «что отвалилось в этот раз». А перед дедлайном такие проблемы обходятся особенно дорого. Методология Выделить критический путь расчётов (открытие кошелька, основные типы операций, оплата по QR, возвраты, сверка) и закрыть его автотестами в первую очередь. Прогонять регресс автоматически на каждом релизе расчётного контура, а не от случая к случаю. Следите за стабильностью набора тестов: «мигающие» тесты обесценивают весь регресс, потому что им перестают верить. Привязывать автотесты к версиям стандартов, чтобы при обновлении контракта быстро видеть, что именно поехало. Подводные камни и рекомендации Нестабильный регресс хуже его отсутствия. Если тесты постоянно дают разные результаты, команда начинает игнорировать их сбои – и может пропустить реальные ошибки. Автоматизация – это не «нанять джуна на месяц». Для тестирования расчётов под нагрузкой и интеграций нужны проверенные фреймворки и специалисты с опытом их внедрения. Итоговая карта рисков перед запуском цифрового рубля Чтобы систематизировать всё, что мы рассказали, используйте итоговую таблицу. Её удобно показать на синке с разработчиками и DevOps – и честно отметить, какие участки системы надёжно покрыты тестированием, а какие требуют доработки. Слой тестирования Чем грозит пропуск Кому особенно важно Функциональное Сорванные операции у клиентов, ручной разбор инцидентов Всем Смарт-контракты Ложное исполнение сделки — это финансовый инцидент Финтеху, B2B, госконтрактам Интеграционное Хрупкие стыки «сыплются» в пик, каскадные отказы Банкам, ритейлу Сверка, реконсиляция Расхождения с реестром ЦБ, двойные списания Банкам Нагрузочное Падение площадки в распродажу — это потеря выручки Ритейлу, e-commerce Информационная безопасность Мошенничество, компрометация ключей и подписей Банкам, финтеху Комплаенс Предписания, штрафы, риск отключения от платформы Всем в первой волне Офлайн-режим Двойная трата, споры с клиентом на кассе Ритейлу в удалённых районах Регресс, автоматизация «Воскресшие» баги, релизы тормозят Всем с частыми релизами Как всё успеть, если команда уже работает на пределе? Когда мы приходим на аудит QA-системы, картина почти всегда одна: команда сильная, но перегруженная. Регресс нестабилен, автоматизаторов не хватает, а узкие компетенции – нагрузка и информационная безопасность – есть в единственном экземпляре, который вот-вот выгорит. И всё это накладывается на дефицит и дороговизну инженеров: сильный QA в Москве – это порядка 190 000 ₽ в месяц, и таких нужно несколько, причём прямо сейчас, под разовый пик перед 1 сентября, а не в штат на годы. <]]>https://quality-lab.ru/blog/gotova-li-vasha-qa-sistema-k-vnedreniyu-cifrovogo-rublya/Wed, 10 Jun 2026 16:50:12 +0300 Автор: Штефан Дирнштофер (Stefan Dirnstorfer) Оригинал статьи Перевод: Ольга Алифанова Моделирование реалистичных сценариев, в которых система может продемонстрировать свою устойчивость, — задача непростая. Но всё становится проще при правильном планировании и чётком понимании доступных вариантов, их стоимости и ограничений. В этой статье описывается создание тестовых сценариев, которые могут поставить систему под угрозу в продакшене. Приходилось ли вам сталкиваться с дефектом, который сложно воспроизвести в тестовой среде? Если да, то, возможно, в этой статье вы найдёте идеи, которые помогут вам в этом. Простые тестовые сценарии можно создать, выбрав конкретные входные значения. Однако сложные сценарии требуют тщательной оркестрации множества компонентов. Это может включать использование реалистичных данных, а также управление некорректно работающими компонентами, задержками и замедлениями. Когда все эти приёмы правильно комбинируются, вы можете воспроизвести условия, в которых ваше программное обеспечение показывает свою истинную силу. ]]> https://software-testing.ru/library/testing/testing-tools/4492-a-software-tester-s-guide-to-the-art-of-mocking Tue, 09 Jun 2026 23:00:00 +0300 Михаил Ланкин, автор статей команды ТестОпс Оригинальная публикация Меня зовут Михаил, я технический автор, работаю с инструментами тестирования в команде ТестОпс. В какой-то момент мне стало интересно — а как получила распространение мысль о том, что разработчикам тоже надо писать тесты? У меня было смутное представление о некотором тёмном «раньше», и условно-ограниченно-просвещённом «сейчас», когда мысль о том, что тестирование не должно жить отдельно от разработки, кажется, стала нормальной. Мостик между этими двумя мирами — автотесты, они нужны и тестированию, и разработке. Фреймворк JUnit сознательно писали как можно более простым — в первую очередь для того, чтобы сделать его повседневным инструментом для разработчиков. Люди, работавшие с первыми фреймворками автотестирования, стали также авторами подходов экстремального программирования (XP) и разработки через тестирование (TDD) — т. е. подходов, настаивающих на том, что тестирование — это не «обязаловка», а интегральная часть разработки. ]]> https://software-testing.ru/library/testing/testing-automation/4521-sunit Sun, 07 Jun 2026 23:00:00 +0300   "Лучше поздно, чем как тогда" В конце 2024 и в конце 2025 я проводила небольшое исследование на предмет удовлетворенностью работой. И все руки не доходили оформить результат. Но наконец-то таки дошли. Вот тут  по ссылке можно посмотреть/скачать небольшую инфографику. Исследование состоит из вопросов: - Я знаю и понимаю цели моей компании. - У меня есть все необходимые ресурсы для достижения рабочих целей. - Я чувствую поддержку от коллег и руководителя. - Я удовлетворен(-а) своей работой ("я счастлив") Это упрощенный вариант, конечно же на нашу удовлетворенность работой влияет гораздо больше факторов. Но задача была дать быстрый инструмент рефлексии. Если коротко - основное влияние на удовлетворенность дает знание целей компании, которое поддерживается ресурсами и поддержкой.  Давайте углубим эти четыре вопроса, каким образом можно на них опереться для определения ближайших шагов для себя. Цели компании Может быть такое, что  мое внимание меня подвело и я просто "пропустил мимо ушей". Определенно может. Вне зависимости от занимаемой позиции. На работе мы все взрослые люди, это не детский сад и не школа. Никто не обязан все разжовывать, класть нам в рот, да и еще помогать проглотить.  Если вы руководитель, то с вас спрос вдвойне. Помним волшебную  фразу "никто не живет в моей голове". То, что кажется очевидным и понятным вам, может быть совсем не очевидным для сотрудников. Каскадирование целей и донесение их до команды - одна из основных ваших задач.  Итого:  - как сотрудник: задать вопрос руководителю. - как руководитель: определять цели команды и как они соотносятся с целями компании. Вне зависимости от выполняемой роли - понимать свои профессиональные цели, и если это никак не бьется с целями команды и компании - делать выводы, и никого не винить. Так бывает. А если соотносится - выжимать из этого синергетический максимум, делать win-win масштабным и кайфовать. Ресурсы Задача руководителя - организовывать работу и в частности обеспечить необходимыми ресурсами сотрудников, банально убеждаться, что для поставленных задач у сотрудников есть все необходимое. Задача профессионала - решать поставленные задачи. Если чего-то не хватает, о "чудо" - сказать об этом, а не ждать пока тебя спросят, что с задачей.  Поддержка Для меня это больше про "blameless culture": если что-то пошло не так, что-то не получилось, то идет проработка как так получилось и что нужно изменить в процессах, в работе, чтобы больше не повторять ошибок, а не поиск конкретного человека, которого во всем обвинят.  Что если в работе встретилась какая-то преграда, человека не оставят один на один. Опять же не забываем просить о помощи, если она нужна.  А руководителю важно контролировать исполнение задач так, чтобы все шло к успеху. Удовлетворенность работой Как ни крути, работа занимает существенное время в нашей жизни. Да, у нас у всех разные потребности в части работы, разные желания того, как должна выглядеть наша работа. Вне зависимости от того, чего именно каждому из нас хочется от работы (или чего точно не хочется) - эмоционально чувствовать, что работа "в кайф", ну или хотя бы "не бесит" очень помогает по жизни идти более уверенным шагом.   В заключении: если что-то раздражает нас в других - скорее всего это бесит нас в нас же самих. Важно понимать, чего мы хотим, и видеть все возможности вокруг. Злиться и быть недовольным - нормально, раствориться в этом - нет.  Отвечаем за себя во всех аспектах своей жизни и не забываем коммуницировать, а не надеяться на "это и так понятно", и не ждем, что нас должны понять здесь и сейчас, просто потому что мы что-то сказали. Донесение информации так, чтобы нас поняли - один из критериев профессиональности. Интересной работы! С удовольствием в пятницу вечером отправляться в выходных, и с удовольствием в понедельник идти работать так как нравится вам! ]]> http://sqalife.blogspot.com/2026/06/software-engineering-happiness-index.html Sun, 07 Jun 2026 06:32:17 +0300 Автор: Фернандо Тексейра (Fernando Teixeira) Оригинал статьи Перевод: Ольга Алифанова Облачные приложения: текущая ситуация В наши дни многие корпоративные приложения работают в облаке и используют множество сервисов, доступных через облачных провайдеров. По состоянию на 2024 год 94 процента компаний по всему миру в той или иной степени внедрили облачные вычисления. Эти облачные сервисы включают виртуальные машины, файловые хранилища, очереди сообщений, базы данных, мониторинг, логирование, инструменты безопасности и многое другое. Сегодня вы можете построить приложение, на 100 процентов работающее в облаке. Наиболее популярны сейчас облачные провайдеры AWS, Google Cloud и Azure. Именно эти трое во многом обеспечивают работу большинства облачных приложений. В 2023 году компании потратили примерно 270 миллиардов долларов США на облачную инфраструктуру — на 45 миллиардов больше, чем годом ранее. Большинство облачных провайдеров взимают плату в зависимости от объёма использования сервисов. Чем больше вы используете сервисы провайдера, тем серьезнее будет счёт в конце месяца. Как правило, провайдеры всё ещё предлагают бесплатный тариф, но при превышении определённого лимита вам всё равно придётся платить. Проблема в том, что многие компании сильно зависят от этих сервисов и активно их используют, из-за чего сложно оставаться в рамках лимитов. 49 процентов компаний испытывают трудности с контролем затрат на облако, а 33 процента превышают бюджет на облако на 40 процентов. ]]> https://software-testing.ru/library/testing/testing-automation/4494-testcontainers-and-localstack Wed, 03 Jun 2026 23:00:00 +0300 Если вы руководите EdTech‑продуктом, статья даст вам понимание, что и как обязательно нужно тестировать, на каких этапах и какие вопросы задавать своему QA (внутреннему или внешнему). 90% материала посвящено российскому рынку и реалиям, 10% – интересным кейсам от Coursera, Duolingo и других международных компаний. В среднестатистической российской онлайн‑школе «всё хорошо с QA» выглядит так: регресс зелёный, баги в Jira закрыты, тестировщик подтвердил готовность релиза. Накатывается новая фича – скажем, новый формат вебинара или групповой проверки домашек. И вот в 19:55 в чате поддержки появляется первое сообщение: «У меня не открывается урок». Через минуту – уже 12 таких сообщений, через пять минут – 200. К 20:15 вебинар так и не запустился: на платформе по‑прежнему белый экран. Начинается суматоха: методист тегает продакта, продакт – CTO, CTO – разработчика, разработчик – тестировщика. Все в панике, но финансовые и репутационные потери уже не исправить. Мы много лет помогаем компаниям из мира цифровых образовательных технологий выстраивать QA и не раз сталкивались с историями разного уровня фатальности. Почти всегда проблема не в конкретных тестировщиках, а в самой системе. Дело в том, что EdTech тестируют как обычное веб‑приложение, не учитывая сложность продукта, специфическую нагрузку, особое поведение пользователей и серьезность последствий ошибок. Если бы об этом писали в учебниках для джунов, мы бы не разгребали ситуации, где школа на 10 тысяч активных учеников живёт без автотестов, а единственный QA – методист, который тестирует как может в свободное от основной работы время (невыдуманные истории из практики коллег, увы). Чем EdTech отличается от «просто веба» с точки зрения тестирования? Когда говоришь собственникам: «У вас не просто сайт с курсами, видео и оплатой», – они всегда смотрят с легким недоумением, искренне не понимая, зачем выделять отдельный QA‑подход для EdTech. Но на это есть 5 веских причин. Нагрузка в EdTech неравномерная. У обычного интернет‑магазина пиковые часы – это, условно, вечер и выходные, с предсказуемым ростом в дни акций. У EdTech пик приходится на конкретные даты и время. К примеру, 19:00 МСК, понедельник, старт вебинара – на платформе одновременно оказываются 8 000 пользователей. К 19:01 их уже 11 000, к 19:03 – 14 000, и треть из них видит сообщение «Ой, что‑то пошло не так». Это не просто высокая нагрузка, а резкий удар. Если вы не тестируете систему именно так – с пиковыми всплесками и стремительным нарастанием числа пользователей, – вы не проверяете нагрузку по‑настоящему. Особенная аудитория c нестандартным поведением, к тому же, довольно часто далёкая от IT. В большинстве школ это: родители школьников (нервничают); сами школьники (легко отвлекаются); взрослые, проходящие переквалификацию (стесняются обращаться в поддержку и просто уходят). Любая ошибка здесь – не просто запись в системе отслеживания багов, а фраза «Всё тупит, я не буду здесь заниматься». Конверсия в обучение – критически важная метрика, и страдает она не из‑за громких сбоев, а из‑за банальных проблем с юзабилити. Поэтому тестировать пользовательский интерфейс в современных образовательных технологиях нужно обязательно. EdTech‑продукт – это целая экосистема: лендинг, личные кабинеты ученика и родителя, кабинеты методиста и преподавателя, админ‑панель, CRM, биллинг, интеграции с эквайрингом, мессенджерами и видеоплатформой, мобильное приложение, иногда desktop‑плеер для скачанных уроков или даже отдельный класс с интерактивной доской. Всё это должно работать без сбоев. Стандартное функциональное тестирование веб‑приложения здесь не поможет, так как у вас не одно приложение, а сложная взаимосвязанная система. Контент – это часть продукта. В обычном SaaS пользователь сам вводит данные, и QA их не затрагивает. В EdTech контент – это база: видео, тексты, тесты, интерактивные задания и тренажёры. Каждый новый курс – это новый набор данных, который должен корректно отображаться, воспроизводиться и оцениваться. Когда методисты сообщают: «Мы загрузили 12 модулей нового курса», – для QA это сигнал к регрессионному тестированию. Например, в одном из модулей может оказаться видео с нестандартной кодировкой, которое не загрузится на старом Android‑планшете. Цена ошибки в EdTech измеряется не деньгами. В финтехе ошибка грозит потерей средств клиента и комплаенс‑рисками, а в EdTech – пропущенным уроком перед ЕГЭ. Деньги можно вернуть, но упущенное занятие за две недели до экзамена (и доверие к вам) – нет. Поэтому критичность дефектов нужно оценивать в категориях обучения, а не просто в функциональности. Раз уж заговорили о критичности – забудьте про разделение «бизнес-критичный, не критичный, минорный». В тестировании EdTech-решений мы обычно настаиваем на трёх осях: критичность для обучения (срывает ли это занятие?), массовость (один пользователь или 30%?), обратимость (можем ли мы откатить эффект?). На пересечении этих осей легко договариваться с разработкой о приоритетах. «У нас P1, всё критично» – это разговор ни о чём. «Это срывает занятие у 30% активной аудитории и при этом необратимо» – уже конкретная проблема. 7 контуров качества EdTech платформ Когда речь идет о тестировании образовательных сервисов, многие представляют себе регресс, проверку форм и пару нагрузочных тестов перед запуском. На практике этого недостаточно. Пользователям всё равно, где произошел сбой – если они решат, что продукт сырой, то уйдут к конкурентам. Чтобы этого не случилось, нужно внедрить зрелую стратегия тестирования, которая покроет 7 контуров качества. Контур №1. Видео и стриминг: главный источник критических сбоев в EdTech  Видео – это сердце большинства EdTech проектов. Записанные уроки, живые вебинары, гибридные форматы. И если видеоматериалы недоступны, то бизнес стоит. Вот распространённые ошибки. Тестируют видео не на тех файлах. Команда QA проверяет плеер на стенде – с «эталонным» видеофайлом, который, разумеется, воспроизводится без проблем. Но в прод курсы загружают методисты и тренеры: файлы отличаются кодеками, частотой кадров и структурой. Эту вариативность часто не учитывают. Решение простое, хоть и трудоемкое: создать тестовую библиотеку из 30–50 реальных файлов из продакшена  – из разных эпох и от всех подрядчиков. Каждый релиз плеера или транскодера нужно прогонять через всю библиотеку. Игнорируют реалии российского рынка. С 2022 года стриминг в РФ работает в особых условиях: часть международных контент‑провайдеров недоступна или функционирует нестабильно. Многие пользователи в регионах пользуются 3G – например, у условного «Б‑оператора» скорость в лучшем случае достигает 2 Мбит/с. Если тестировать только на офисном гигабитном соединении, картина будет нереалистичной. Обязательно проводите throttling‑тесты – искусственно ограничивайте полосу пропускания. Проверьте три сценария: «плохой 3G», «средний 4G» и «хороший Wi‑Fi». Так вы поймёте, как работает адаптивный битрейт, что показывает плеер при падении скорости и корректно ли возобновляется воспроизведение. Не проверяют длительные сценарии. Урок может длиться 45 минут, вебинар – 90 минут или даже два часа. Часто тестировщик убеждается, что видео запускается, и считает задачу выполненной. Но важно оставлять стрим на длительное время. Например, у одного из клиентов мы обнаружили проблему: через 57 минут просмотра в Safari звук рассинхронизировался с картинкой на 2–3 секунды – из‑за этого пользователь не понимал, что говорит лектор. Совет для CTO: попросите QA-команду показать вам матрицу «устройство × браузер × сеть × длительность» для видео. Если у них нет такой матрицы или она содержит меньше 15 комбинаций – у вас нет тестирования видео. У вас есть надежда (или вера?), что оно работает. Контур №2. Тестирование производительности: выдержит ли платформа реальный учебный процесс Большинство EdTech компаний к которым мы приходим, уже имеют какой‑никакой опыт нагрузочного тестирования – обычно это разовый прогон в JMeter перед крупным запуском. Но такой подход редко отражает реальную картину работы продукта. Почему? Профиль нагрузки EdTech‑платформы специфичен, и его нужно тщательно проектировать. Мы выделяем четыре типа всплесков – каждый требует отдельного тестирования. Что мы слышим? Как действительно обстоят дела? «У нас своя сильная команда» Мы её не заменяем, а подключаемся в нужный период. Закрываем пики и редкие компетенции – нагрузку, ИБ, автоматизацию. Прозрачная смета и SLA вместо непредсказуемого найма. «Внешние не разберутся в нашей архитектуре» Быстро погружаемся через обратный инжиниринг, есть опыт фреймворков под highload, в штате – один из ведущих в РФ специалистов по Selenium. «Боюсь потерять контроль над качеством» Работаем на ваших процессах и под вашим управлением в рамках аутстаффа. Подробная отчётность, быстрый онбординг, при желании – рост зрелости через консалтинг и обучение. «Нужна предсказуемость бюджета» Распределённая команда обходится дешевле московского найма, а смета и сроки фиксируются заранее. Вы платите за закрытый риск, а не за раздувание штата. Тип всплеска Что происходит Что особенно нагружается Старт вебинара За 2–3 минуты заходит вся аудитория курса Авторизация, коннекты, видеопоток Дедлайн домашки За час до 23:59 – массовая отправка работ, загрузка файлов Хранилище, обработка заданий, очереди проверки Запуск курса, распродажа Пик регистраций и оплат за 1–2 часа Биллинг, эквайринг, очереди писем, активация доступа Массовая рассылка Письмо «урок через 15 минут» – за минуту входят 10–20 тысяч Балансировщики, кеш, базы данных Сценарий должен повторять реальное поведение пользователей. Например: «4 000 пользователей заходят в личный кабинет, нажимают кнопку „Войти в вебинар“, переходят на страницу плеера, плеер устанавливает WebSocket‑коннект, открывается чат, начинается видеопоток, а через 12 минут 800 человек одновременно открывают вкладку с заданием». Создать такой тест непросто – это кропотливая, методичная работа. Отдельно стоит упомянуть chaos‑тестирование. В классическом варианте оно подразумевает намеренный вывод из строя отдельных частей инфраструктуры, чтобы проверить устойчивость системы. В EdTech я предпочитаю более мягкий подход – так называемые деградационные тесты. Что будет, если контент‑провайдер отключится в ключевой момент? Или если эквайринг начнёт тормозить и задерживать платежи – скажем, обработка вместо привычных 2 секунд займет целых 8? А если сервис рассылок выйдет из строя и не отправит пользователям уведомления о начале вебинара? У зрелых продуктов должны быть заранее проработанные и протестированные сценарии реагирования на такие ситуации. Это гораздо лучше, чем в момент сбоя метаться по чатам, в панике успокаивать пользователей и создавать колоссальную нагрузку на отдел продаж и техподдержку. Контур №3. Платежи, доступы и возвраты: самая чувствительная зона EdTech Разберём одну из самых проблемных областей – биллинг в EdTech. Он должен синхронно выполнять три задачи: принять оплату, выдать доступ, уведомить пользователя. Сбой на любом этапе ведёт к финансовым потерям или некорректным списаниям. Вот ключевые сценарии для регрессионного тестирования: Двойная оплата. Пользователь случайно нажимает «Оплатить» дважды и получает два списания. Хотя кейс кажется надуманным, по статистике на такие операции приходится 0,3–1,5% всех оплат в любой школе. Важно проверить, возвращает ли система деньги автоматически и отображается ли эта операция в интерфейсе администратора. Оплата с задержкой. Эквайринг работает медленно, пользователь решает, что платёж не прошёл, и повторяет попытку – в итоге средства списываются  несколько раз. Промокод плюс рассрочка. Любимая комбинация, которую все забывают тестировать. Особенно если рассрочка через банк-партнёра. В нашей практике был случай,  когда промокод 50% применялся к каждому платежу рассрочки отдельно, и человек платил половину суммы дважды по графику. Это вызвало серьезные проблемы в бухгалтерии. Возврат за частично оплаченный курс. Если ученик прошёл 3 из 10 модулей и запросил возврат, нужно убедиться, что сумма соответствует оферте, а запись о возврате есть в CRM и 1С. Подписочная модель и отмены. Если у вас подписка на доступ к контенту – что происходит при отмене? Доступ блокируется сразу или после завершения оплаченного периода? Что происходит с контентом, скачанным через мобильное приложение?  Разные способы оплаты (СБП, карты, остатки Apple Pay в РФ и др.) имеют свои нюансы – коды ошибок, поведение при таймауте, комиссии. Для каждого канала нужен отдельный набор тестов. Если биллинг покрыт автотестами меньше чем на 90%, то вы серьезно рискуете. В EdTech автоматизация не опция, а необходимость: ручной прогон занимает около 16 часов, требует тестовых карт и согласования с эквайрингом. Проводить его перед каждым релизом практически нереально. Контур №4. Мобильные приложения: большая часть аудитории учится со смартфонов Доля мобильного трафика в российских EdTech-продуктах варьируется от 50 до 80% в зависимости от ниши. Школьные платформы — мобилки 65–75%. Платформы для взрослых (профессиональное обучение) — 50–60%. Подготовка к ЕГЭ — почти 80% мобилки в вечерние часы. И при этом регулярно видим команды, где приложение тестируется «по остаточному принципу» — после того как закончили с вебом. Что специфично для EdTech приложений в России? Разнообразие устройств заметно шире, чем в Европе. Там достаточно протестировать приложение на паре флагманских iPhone и трёх моделях Android, а у нас приходится учитывать старые Honor и Xiaomi, бюджетные Realme, а также российские планшеты на нестандартных сборках Android (например, поставленные в школы по госконтракту). Многие из этих устройств работают на прошлогодних версиях ОС без последних обновлений сервисов Google – и это тоже влияет на работу приложения. Если не тестировать на матрице хотя бы из 12–15 реальных устройств (от премиальных до бюджетных), часть пользователей будет сталкиваться с ошибками. Они вряд ли обратятся в поддержку – скорее просто уйдут или оставят негативный отзыв, что в перспективе снизит приток клиентов.  RuStore и альтернативные сторы. Некоторая часть аудитории не может скачать приложение из Google Play и использует RuStore, AppGallery или устанавливает APK‑файл напрямую. Версия для RuStore порой отличается от Play‑версии – например, может не поддерживать Firebase push‑уведомления и использовать собственные аналоги. Поэтому важно тестировать каждую сборку отдельно, включая сценарий прямой установки APK: там могут быть особенности с разрешениями и поведением приложения. Офлайн-режим. Если платформа позволяет скачивать уроки для офлайн‑просмотра, то нужен отдельный блок тестирования. Сценарий «скачал — сеть пропала — продолжаю смотреть — сеть вернулась — прогресс синхронизировался» имеет множество вариантов развития – и любой из них может дать сбой без систематической проверки. Например, бывает так: пользователь скачал урок, школа отозвала доступ из‑за неуплаты, но видео продолжает воспроизводиться с устройства. Мы сталкивались с таким багом в трёх школах – в одной он оставался нерешенным два года. Push-уведомления. В EdTech это конверсионный инструмент: «Ваш урок через 15 минут», «Не забудьте сдать домашку», «Преподаватель проверил работу». Если уведомления не доходят, то снижается удержание аудитории. Тестировать их непросто: нужны реальные устройства и сертификаты APNS/FCM, а также проверка на сотнях уведомлений за раз. Особенно важно тестировать на разных брендах – Huawei, Xiaomi и Samsung по‑разному управляют фоновыми процессами, из‑за чего уведомления могут не приходить, если система принудительно выгрузила приложение. Контур №5. ПДн, права доступа и безопасность: базовый минимум для EdTech  EdTech‑школы работают с персональными данными несовершеннолетних, а значит, подпадают под особо строгий регуляторный режим. Вот что советует проверять наш ведущий тестировщик с 13‑летним опытом и бывший практикующий юрист. Корректность работы согласий на обработку персональных данных (ПДн). Важно убедиться, что чек‑боксы при регистрации настроены правильно (обязательные или необязательные), а информация корректно записывается в базу данных и передается родителю ученика. Реализацию права на удаление данных. Может ли пользователь или родитель запросить удаление информации? Что именно удаляется, а что сохраняется по закону – например, данные в логах биллинга должны оставаться. Следует подтвердить локализацию серверов. Хотя это инфраструктурный вопрос, QA‑команда должна в рамках регрессионного тестирования убедиться, что все чувствительные данные обрабатываются на серверах в РФ. Контроль доступов внутри платформы. Например, может ли преподаватель курса А получить доступ к данным ученика из курса B, к которому не имеет отношения? Тест на «горизонтальную эскалацию прав» обязателен: он выявляет риски несанкционированного доступа. Важно проверить безопасность для неавторизованных пользователей. Может ли гость по прямой ссылке открыть чужой урок, профиль или переписку в чате? Такие уязвимости нередко встречаются – хотя их редко ищут целенаправленно. Всё это не полноценный пентест, а базовый набор проверок, который нужно выполнять при каждой регрессии. При этом полноценный пентест тоже необходим – для зрелой платформы его стоит проводить хотя бы раз в год. Вопросы безопасности и соответствия требованиям законодательства настолько объемны, что заслуживают отдельного разговора. В конце статьи мы дадим ссылку на подробный материал о комплаенс-тестировании. Контур №6. Интерфейс глазами ученика, а не разработчика В EdTech почти не тестируют одну очень важную вещь – «обучаемость» интерфейса, то есть его способность помочь ученику получить нужные знания. Это зона на стыке QA, UX‑исследований и педдизайна. Вот сценарии, которые мы обычно просим команду протестировать вживую, на реальных представителях ЦА. Первая сессия нового ученика. Зарегистрировался, оплатил, зашёл – может ли он за 5 минут найти своё первое занятие и начать учиться? Сколько раз перешёл по интерфейсу впустую? Где запнулся? Возврат после паузы. Если ученик не заходил на платформу две недели, система должна помочь ему сориентироваться – подсказать, на чём он остановился.  Сдача домашки. Сколько шагов требуется, видно ли, что работа отправлена, приходит ли подтверждение?  Запрос помощи. Ученик не понял тему – как он может задать вопрос преподавателю, методисту, поддержке? Сколько кликов до результата? Сценарий «родитель проверяет ребёнка». Может ли родитель за две минуты увидеть прогресс, посещения, оценки? Маленькая ремарка. Юзабилити-тестирование на сотрудниках школы – это самообман. Они знают продукт, помнят, куда нажимать, и не споткнутся там, где реальный человек. Найдите 5–7 представителей целевой аудитории, попросите их выполнить ваши сценарии вслух и запишите. Это даст вам данных больше, чем три месяца внутренних обсуждений. О том, как проводить юзабилити-тестирование, находить реальные барьеры и превращать пользовательский опыт в конкурентное преимущество, мы подробно рассказали в отдельном материале. Ссылку на статью оставим в конце.  Контур №7. Контент как часть продукта: почему его тоже нужно тестировать  Контент в EdTech – часть продукта, а его публикация равнозначна релизу. С точки зрения управления качеством каждый новый курс должен проходить приемочное регрессионное тестирование перед запуском. Что оно должно включать: Все видео проигрываются на всех целевых платформах. Все тестовые задания корректно оцениваются – правильные ответы засчитываются, неправильные нет. Все интерактивные элементы (тренажёры, опросы, симуляции) работают на устройствах из вашей матрицы. Все ссылки в курсе ведут куда положено. Прогресс корректно отображается после прохождения каждого блока. Сертификаты, дипломы или отметки о прохождении выдаются по нужным условиям. В половине школ, с которыми мы начинали работать, такого тестирования не было. Методисты сами собирали курс, сами его проверяли – и сразу запускали в прод. В результате первая когорта учеников обнаруживала 20–30 проблем, которые приходилось устранять уже «на живых людях». Это не самый профессиональный подход. При этом исправить ситуацию несложно: достаточно разработать чёткий чек‑лист и выделить ответственного, который будет прогонять его перед публикацией каждого курса. Что должно быть в зрелой QA-стратегии EdTech-платформы? Соберем теперь все вышесказанное в чек-лист для CTO или CEO. Если вы можете уверенно поставить галочку напротив каждого пункта – поздравляем, у вас есть система. Если нет – вы нашли точки роста. На уровне процессов Описана матрица критичности дефектов с осями «обучение/массовость/обратимость». Есть документированная стратегия тестирования с прописанными контурами (видео, нагрузка, биллинг, мобилка, безопасность, юзабилити, контент). Каждый релиз проходит регрессию по чек-листу всех 7 контуров. Перед публикацией каждого нового курса проходит приемочный регресс контента. Команда QA участвует в продуктовых обсуждениях ещё до того, как начинают писать технические спецификации. На уровне инструментов Автотесты для биллинга – обязательны, особенно для критических сценариев.  Автотесты на основные пользовательские пути (вход, начало урока, сдача домашки). Нагрузочные тесты должны учитывать реальный профиль нагрузки – а не просто «1000 пользователей на главной».  Для мобильного тестирования нужна матрица из минимум 12–15 моделей устройств.  Регулярные throttling-прогоны на медленных сетях. Тестовая библиотека видео из реального продакшена. На уровне команды В команде есть специалист или группа, отвечающая за автоматизацию тестирования.  В команде есть человек, отвечающий за нагрузочное тестирование (либо это умеет основной QA). QA-команда умеет тестировать мобильные приложения, а не только веб и отдает приоритет тестированию той платформы, которая популярна среди вашей аудитории. Есть процесс юзабилити-исследований с реальными учениками – минимум раз в квартал. Собственная команда или аутсорс: что выбрать EdTech-компании? Мы бы соврали, если бы сказали, что аутсорс – всегда лучший вариант. Это не так. У in‑house‑команды есть весомые преимущества: глубокое понимание контекста, постоянная связь с разработчиками, накопленные знания о продукте и единая корпоративная культура. Если в разработке задействовано более 200 человек, а продукт уже стабилен, то собственная QA‑команда – логичный выбор. Мы не затрагиваем экономический аспект: в 2026 году он заметно изменился, и мы сами часть административных процессов ради экономии отдали на аутсорс профессионалам. Но это тема для отдельной статьи. При этом, в EdTech есть ряд ситуаций, где аутсорс работает реально лучше. Ситуация 1. Быстрый рост школы при нехватке QA‑специалистов. Типичная картина: 30 разработчиков и всего 2 тестировщика, которые не справляются с нагрузкой. Нанять ещё 5 человек – это 2–3 месяца на поиск и адаптацию плюс риск, что не все приживутся. Аутсорс решает проблему за 1–2 недели – не как постоянное решение, а как временная мера, пока формируется своя команда. Ситуация 2. Нужны редкие компетенции. Нагрузочное тестирование. Безопасность. Автоматизация мобилки. Каждая из этих компетенций требует одного-двух узкоспециализированных спецов. Содержать в штате трёх инженеров под три направления, если они нужны не на 100% времени – дорого. Аутсорс под конкретное направление обходится в разы дешевле. Ситуация 3. Пиковая нагрузка на тестирование. Перед началом учебного года, запуском нового курса или редизайном объем тестирования возрастает в 3–5 раз на 1–2 месяца. In‑house‑команда в такие периоды перегружена, а потом простаивает. Аутсорс позволяет гибко масштабировать ресурсы под текущие задачи.  Ситуация 4. Нужен взгляд со стороны. Когда команда долго работает с продуктом, она может не замечать очевидных проблем. Внешний QA‑специалист подходит к тестированию непредвзято и выявляет то, что для внутренних сотрудников стало «нормой». Это особенно важно при аудите процессов и подготовке к масштабированию. Ситуация 5. Юзабилити-исследования. Тестировать продукт на своих сотрудниках – мы уже договорились – самообман. Аутсорсер, у которого собран реальный пул респондентов из ЦА, делает это в разы быстрее и качественнее, чем внутренняя команда, которая каждый раз заново ищет учеников. Идеальная конфигурация для крупной EdTech-школы – это, как правило, гибрид. 1–2 инхаус-QA в каждой продуктовой команде, которые знают свой контекст, плюс внешний партнер на нагрузку, мобильную автоматизацию, юзабилити и пиковые работы. Какие вопросы задать потенциальному QA-подрядчику? Если вы решили рассматривать аутсорс тестирования – вот вопросы, по ответам на которые сразу станет понятно: перед вами серьёзная компания и надёжный партнёр или вам продают джунов в красивой обертке. Покажите 2–3 реальных кейса с EdTech-продуктами или платформами с похожим профилем нагрузки. Без названий, под NDA – нормально, но цифры и подходы должны быть. Какой у вас типовой подход к нагрузочному тестированию EdTech? Какие инструменты используете? Какие профили проектируете? На скольких реальных устройствах вы можете тестировать мобильное приложение прямо сейчас, без закупки? <]]> https://quality-lab.ru/blog/ot-vebinarov-do-billinga-chto-nuzhno-testirovat-v-edtech-na-samom-dele/ Tue, 02 Jun 2026 18:15:55 +0300 Меня зовут Анатолий Бобунов, и в EXANTE я SDET — Software Development Engineer in Test. В последние несколько лет я развивал тестовую архитектуру для бэкенд‑сервисов компании. Наш тестовый фреймворк изначально создавался как единая платформа для тестирования нескольких backend‑сервисов. По мере роста системы увеличивалось и количество сервисов, каждый из которых приносил свою специфичную логику, требования к клиентам, данным и подготовке окружения. Эти требования не всегда укладывались в существующую архитектуру. В результате появлялись локальные обходные решения, которые решали конкретную задачу, но обходили архитектурные ограничения. Со временем такие решения начали накапливаться. Разные сервисы использовали разные паттерны для HTTP‑клиентов, ретраев, подготовки данных и валидации ответов. Общие абстракции постепенно размывались, а направление зависимостей становилось менее очевидным. Дополнительно ситуацию усиливали срочные задачи, которые требовали быстрых изменений без полноценного архитектурного пересмотра. Это приводило к появлению временных решений, которые затем становились постоянными. Фреймворк продолжал работать и покрывал сценарии тестирования, но его развитие замедлялось. Добавление нового сервиса требовало всё больше исключений, интеграция новых инструментов становилась сложнее, а изменения в базовых компонентах затрагивали несвязанные части системы. В какой‑то момент стало очевидно, что текущая архитектура перестала масштабироваться вместе с количеством сервисов. В этой статье я расскажу, почему мы решили создать новую архитектурную модель, какие принципы легли в её основу и как мы подготовили фреймворк к работе с SDK и AI‑инструментами. ]]> https://software-testing.ru/library/testing/testing-automation/4519-test-framework Sun, 31 May 2026 23:00:00 +0300 Опубликован выпуск рассылки за декабрь-январь. В выпуске собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов. Содержание рассылки доступно по ссылке. Подписаться на рассылку ]]> https://software-testing.ru/news/4525-mail-may Thu, 28 May 2026 15:14:35 +0300 Это не рекламный текст. Здесь чистая математика. Передо мной не стоит задачи уговорить вас выбрать аутсорс и подписать с нами договор до конца квартала. Мне важно, чтобы вы оценили свою внутреннюю экономику с открытыми глазами, а не «потому что все так делают» или «в интернете написано». В конце статьи я прикрепил калькулятор, где можно посчитать реальные затраты на QA, – и это очень отрезвляет. 2026 – это рынок нанимателя. Впервые за много лет. Мидл‑ручник в Москве сегодня закрывается на 110 000 ₽ в месяц, и это уже не региональная, а реальная столичная вилка из вакансий, которые мы видим каждый день в HH и у себя в почте. Параллельно крупные продуктовые компании сокращают QA‑команды и режут косты на всём, до чего дотягиваются руки финансовых директоров (CFO). Все ищут, где сэкономить, не потеряв в качестве. Мы – не исключение: в этом году, всё оценив и взвесив, отдали свою «административку» на аутсорс (да, мы тоже осознали, что долго считали против себя). А ещё недавно нас пустили в бизнес‑экономику нескольких клиентов – посмотреть, как формируется реальная стоимость их QA‑команд. И я собрал всё, что мы увидели, чтобы прямо сейчас разложить по полочкам. Почему так трудно посчитать затраты правильно? Большая часть статей в интернете на тему «аутсорс vs инхаус» страдает одним и тем же: они сравнивают зарплату штатного сотрудника со ставкой аутсорс‑команды. Это всё равно что сравнивать стоимость литра бензина со стоимостью поездки на такси. Цифры разные, выводы – бесполезные. Чтобы сравнение было честным, нужно сравнивать: Полную стоимость владения штатным тестировщиком (TCO – total cost of ownership) – со всеми накладными расходами; Полную стоимость услуги аутсорс-команды – со всеми скрытыми и неочевидными компонентами. Обе цифры важно приводить к одной единице измерения. Считать буду в «рублях за час продуктивной работы». Потому что час спящего на встрече тестировщика и час реально пишущего тест-кейсы – это разные часы, хоть вы и платите по факту за оба.   Дисклеймер для CFO, читающего через плечо менеджера: цифры в этой статье – медианные по рынку Москвы на январь – апрель 2026. По вашему конкретному проекту они могут отличаться. Не верьте никому на слово, включая меня. Посчитайте свои. Зарплата – это всего лишь треть стоимости сотрудника Самая частая ошибка, которую я вижу: руководитель в Excel пишет «мидл = 110 000 ₽» и сравнивает это с любой другой цифрой. Это неправильная отправная точка. Реальная стоимость сотрудника складывается из четырёх слоёв, и зарплата – только первый из них. Слой 1. Прямые выплаты «в лоб» Это то, что видно сразу. Оклад на руки: 110 000 ₽ – типичная вилка мидла-ручника в Москве на начало 2026 года;  НДФЛ (13–15%): 16 400 ₽ – да, формально платит сотрудник, но из «грязной» суммы, которую начисляет работодатель;  Страховые взносы (≈30% от грязной зарплаты): 37 920 ₽ – пенсионный фонд, ОМС, соцстрах. Это уже из кармана компании. Итого: 164 320 ₽/месяц. Уже не 110 000, правда? Слой 2. Рабочее место и инфраструктура Даже если у вас полностью удалённая команда, инфраструктура всё равно стоит денег. Если у вас офис – затрат ещё больше. Ноутбук и периферия (амортизация): ~3 500 ₽/месяц (хороший ноут на 180 тыс. + монитор + мышь, амортизация на 3 года). Лицензии на софт (TestRail/Allure TestOps, Jira, Confluence, Postman Pro, BrowserStack, антивирус, корп. офис): ~6 000–10 000 ₽/месяц на человека. Офис (если есть): аренда + клининг + чай-кофе-печенье в Москве ~15 000–25 000 ₽/месяц на одно рабочее место. Корпоративная связь, сервера для тестовых сред, внутренние сервисы: ~2 000 ₽/месяц на человека.  Берём осторожно для удалённого формата: +12 000 ₽/месяц. Для офисного – смело +30 000 ₽/месяц. Маленькая ремарка про софт: те же TestRail/Jira/Confluence/Allure нужны и аутсорс-команде. Но у нормального вендора либо есть возможность купить дешевле, либо уже подобранные и обкатанные бесплатные альтернативы (Qase Free, TestLink, YouTrack Free, Allure Report), которые он может развернуть клиенту, если тот не хочет тащить ещё одну подписку. В штате каждую лицензию вы покупаете самостоятельно и за свои. Слой 3. HR‑цикл с помесячной разбивкой Это самый скрытый слой. Его невозможно увидеть в зарплатной ведомости, но он точно есть в P&L. Стоимость найма одного мидл-тестировщика в 2026 году: услуги рекрутингового агентства – 15–20% годового дохода (≈ 240 000 ₽), внутренний рекрутер – около 80 000–120 000 ₽ с учётом времени менеджеров на собеседования. Берём среднее: 150 000 ₽ за найм;  Срок закрытия вакансии в Москве на начало 2026 – 1–2 месяца от старта поиска до выхода человека на работу. И это при удачном раскладе;  Адаптация (2-3 месяца до выхода на полную мощность): сотрудник получает зарплату, но реально приносит ~50% пользы. Это потерянные ~165 000 ₽ за первые три месяца. В пересчёте на год – ~14 000 ₽/месяц;  Текучка: средний срок жизни QA-мидла в одной компании в 2025–2026 гг. – 1,8–2,2 года. То есть каждые два года вы повторяете цикл «нашёл – адаптировал – обучил – потерял». Разбиваем затраты на наём (150 000 ₽) по 24 месяцам: +6 250 ₽/месяц. Плюс адаптация: +14 000 ₽/месяц. Итого: ~20 000 ₽/месяц. Слой 4. Управление, обучение, простои А вот это вообще никто не считает. Менеджмент. Тимлид/QA-лид тратит на одного мидла примерно 15–20% своего времени: 1:1, ревью, планирование, разбор инцидентов. Если ЗП тимлида на руки 200 000 ₽ (это TCO ~300 000 ₽), то 18% – это ~54 000 ₽/месяц на каждого подчинённого мидла;  Обучение, конференции, корпкультура: 5 000–10 000 ₽/месяц на человека в среднем по компаниям. Берём 7 000 ₽;  Оплачиваемые непродуктивные дни: 28 дней отпуска + примерно 10 дней больничных + государственные праздники + отгулы = ~58 дней в году, или ~22% оплаченного, но нерабочего времени. Это не «расход сверху», это уже учтено в зарплате, но критично для пересчёта в продуктивные часы (см. ниже);  Простои между задачами. По нашим замерам на десятках проектов клиентов, штатный QA-инженер реально выполняет тестовые задачи 5–6 часов из 8-часового дня. Остальное – встречи, ожидание сборок, ожидание ответов от разработчика, скроллинг новостей. Это 30–35% непродуктивного времени внутри рабочего дня. Менеджмент и обучение: +61 000 ₽/месяц. Сводная стоимость одного мидл-ручника Статья расходов Сумма, ₽/мес Оклад на руки 110 000 НДФЛ 16 400 Страховые взносы (~30%) 37 920 Рабочее место, лицензии, инфраструктура 12 000 Размазанная стоимость найма 6 250 Период адаптации (амортизировано) 14 000 Менеджмент (доля времени тимлида) 54 000 Обучение, конференции 7 000 ИТОГО полная стоимость владения (TCO) 257 570 257,5 тысяч из объявленных 110 тысяч на руки. Я не зря писал, что зарплата – это треть стоимости.  Если у вас офисный формат, прибавьте сверху ещё 18 000–25 000 ₽/месяц за рабочее место. Получите ~280 000 ₽/месяц на одного мидла-ручника.  А что с продуктивными часами? Теперь пересчитаем эти 257 тысяч в «час реальной работы», за который вы фактически платите.  В месяце ~21 рабочий день × 8 часов = 168 часов оплаченного времени. Но:  Отпуск + больничные + праздники съедают + отгулы ~22% от года. Остаётся ~131 час оплаченного присутствия в месяц;  Внутри рабочего дня – встречи, ожидание сборок, переключения. Реально на задачах – 5–6 часов из 8, то есть ~70% времени; Итого: 131 × 0,7 = ~92 продуктивных часа в месяц.  Стоимость одного продуктивного часа штатного мидла-ручника:  257 570 / 92 ≈ 2 800 ₽/час Не 110 000/168 = 654 ₽/час, как любят считать в Excel. А две тысячи восемьсот рублей! За один час, в течение которого тестировщик реально что-то делает руками с вашим продуктом. Считаем тем же способом затраты на аутсорсинг  Сразу важная и честная оговорка, чтобы не выглядеть мошенником с калькулятором. Да, аутсорс-инженер – такой же живой человек, как и штатный. У него тоже бывают встречи, синки с менеджером, ожидание сборок, переключение контекста между задачами. Если он тратит на ваш проект 8 часов в день – из них реально продуктивных тоже будет ~70%. Это надо признать. Но вот что компания-аутсорсер действительно снимает с вас: Оплачиваемый отпуск (28 дней); больничные; государственные праздники и переносы выходных, отгулы; декреты, долгие простои между задачами компании, корпоративы, обучение и т.д. Когда человек ушёл в отпуск или заболел – вам предоставляют замену, и вы платите за конкретные часы. Когда у инженера в отчётном месяце меньше задач от вас – вы тоже рассчитываетесь только за отработанное время. Когда на календаре очередные праздники – вы ничего не должны. Рыночные ставки аутсорс-тестирования в Москве на начало 2026 года для мидл-ручника: Малые компании без своей школы и экспертизы, без контроля качества: 900–1 100 ₽/час; Средние и крупные провайдеры с гарантиями и собственной учебной базой: 1 200–1 450 ₽/час; Топ-вендоры с очень узкой специализацией (банки, телеком, embedded): 1 900–2 800 ₽/час. Беру для сравнения медианную ставку 1 300 ₽/час. Чтобы получить от аутсорса те же 92 продуктивных часа в месяц, что и от штатного сотрудника, я должен закупить у вендора примерно 131 час «присутствия инженера на проекте» (те же 70% будут продуктивны). Итого:  131 час × 1 300 ₽ = ~170 300 ₽/месяц. Параметр Инхаус-мидл Аутсорс-мидл Стоимость в месяц 257 570 ₽ ~170 300 ₽ Продуктивных часов в месяц ~92 ~92 Цена одного продуктивного часа ~2 800 ₽ ~1 850 ₽ Время до старта работ 1–2 мес. поиска + 3 мес. адаптации 3–10 дней Оплата отпуска/больничного Да, 22% времени Нет Простой между проектами Оплачиваете полностью Не оплачиваете Замена при увольнении/болезни Снова 1–2 мес. найма + адаптация 3–14 дней, равноценный специалист Разница на одном мидле: ~87 000 ₽/месяц, или ~1,04 млн ₽/год. На команде из пяти ручников – ~5,2 млн ₽/год. Это не маркетинг, а математика, которую мы применили и к себе, отдав бухгалтерию и административные процессы на аутсорс в 2026 году. Получилось сэкономить около 40% и при этом усилить экспертизу – потому что отдельная бухгалтерская компания знает про налоги больше, чем штатный главбух, который варится только в одной компании. Та же логика работает с тестированием. Скорость замены QA-инженера Отдельно подсвечу пункт, который обычно недооценивают, но вот в реальной жизни (не в excel) он решает очень многое. Сценарий А (инхаус). У вас уходит мидл-ручник. Сегодня он подал заявление, через 14 дней его нет. Вы запускаете поиск:  1–1.5 недели – описать вакансию, согласовать с HR, разместить, дождаться первых откликов;  2–4 недели – отсмотр, собеседования, тестовые задания;  2 недели – оффер, отработка на старом месте, выход;  2–3 месяца – онбординг и адаптация. Итого от заявления до полноценной замены: ~3–4 месяца. Всё это время – оголённое направление, перегруз команды, риск регрессов. Сценарий Б (аутсорс). Инженер вендора уходит (болеет, меняет проект). Вендор предлагает замену из внутреннего пула. У хорошего провайдера это 3–14 дней, причём новый человек уже на старте подготовлен: прошёл онбординг-процесс (чек-лист погружения в продукт, готовые шаблоны тест-документации); получил контекст от предыдущего инженера (обновлённую тест-модель, актуальные кейсы, известные особенности продукта); имеет доступ к внутренней базе знаний по уже разобранным аналогичным проектам. Гибкость, которую Excel не покажет Деньги посчитать легко, а вот возможности, которые даёт аутсорс, – в сухой таблице так просто не отразить. Перечислю то, что в реальной жизни часто оказывается важнее ставки.  1. Масштабирование под релизы Ситуация. Релиз через две недели, обычно команда из 3 ручников справляется, но сейчас фича на полпродукта и регрессию надо за выходные. Что вы делаете? Инхаус: просите команду остаться на овертайм, люди выгорают, а вы получаете заявления на увольнение через месяц. Или нанимаете ещё двух мидлов «впрок» – и платите им зарплату весь год, хотя пиковая нагрузка случается раз в квартал. Аутсорс: пишете в чат менеджеру, на следующий день подключаются ещё 2 человека, после релиза они уходят на другой проект. Платите только за релизные дни. В годовой перспективе это значит, что вы не содержите «армию мирного времени», которая нужна вам только в патовые моменты. 2. Широкая экспертиза – суперсила, которую недооценивают  Ситуация. Джун-тестировщик упёрся в задачу по нагрузке. Он не знает JMeter, не понимает, как читать графики, не умеет анализировать GC-логи. Что происходит? Инхаус: джун идёт к тимлиду (который и сам не нагрузочник). Они идут гуглить, проходят курсы, а вы теряете 2–3 недели, получая в итоге посредственный результат. Есть ещё вариант: заплатить консультанту за разовый аудит 200–400 тысяч, когда всё уже окончательно пошло не так. Аутсорс: джун пишет в чат внутреннего «совета экспертов» – и через час разговаривает с человеком, который последние 10 лет тестирует банковские системы под нагрузкой. Этот человек подключается на 4 часа, размечает, что и как делать, передаёт обратно джуну. Никаких отдельных контрактов и согласований. Всё уже включено. Самое смешное, что такая экспертиза очень часто нужна на проектах час-два в месяц. Содержать в штате senior нагрузочника, senior security-тестировщика, senior мобильщика, senior автоматизатора и senior API-эксперта – это бюджет, на который у вас не наберётся столько работы. А в аутсорс-структуре узкоспециализированные тестировщики постоянно практикуются на 10–15 проектах сразу, при этом они доступны для каждого клиента «по запросу». 3. Обучение и прокачка скиллов  Этот пункт для нашей компании принципиальный, потому что у нас есть свой учебный центр, из которого за 16 лет выпустились более 7 000 QA‑инженеров (многие из них сейчас в штате наших же конкурентов – мы этим тихо гордимся). И вот что это нам даёт на практике: Если на проекте нужен новый навык – Selenide, K6, Playwright, тестирование смарт‑контрактов – мы не идём искать человека на рынке. Мы прокачиваем своего за 2–4 недели по внутренней программе, бесплатно для клиента. В инхаусе любая новая экспертиза — это либо найм за 1–2 месяца с трёхмесячной адаптацией, либо отправка человека на платное обучение (30–70 тысяч рублей), либо отказ от задачи. 4. Минимизация человеческого фактора  В штате процессы зависят от Даши, уходящей в декрет, от Пети, который выгорел и нервно пишет заявление, от Серёжи, который болеет три недели подряд. Это нормально для любого работодателя. Но вы имеете право минимизировать такие риски. В аутсорсе головная боль по замене лежит на вендоре. Если человек заболел (уволился, просто плохо работает) – вам подберут альтернативу без оплаты «накладных расходов». «Инхаус лучше, потому что…» – разбираем главные аргументы Переходим к интересной части. Я регулярно слышу от руководителей одни и те же контраргументы против аутсорсинга тестирования. Хочу их разобрать честно – где они правы, а где поддерживают мифы из 2010-х. Аргумент 1: «Экспертиза должна оставаться внутри»  Что слышу: «Если мы отдадим тестирование на аутсорс, через год у нас не останется никого, кто понимает продукт. А подрядчик уйдёт — и мы голые». Реальность: адекватный правильный аутсорс работает наоборот. Нормальный вендор изначально упаковывает всю работу так, чтобы можно было отвязать и вернуть проект заказчику в любой момент без потерь, поэтому система построена так: тест-документация (стратегия, чек-листы, тест-кейсы) ведётся в вашей системе – TestRail, Allure TestOps, Qase, что у вас стоит. Не в его внутренних инструментах; все артефакты по проекту – отчёты, метрики, баг-репорты, тест-планы – хранятся у вас. Уйдёт вендор – это всё остаётся; регулярная передача знаний на встречах с вашим QA-лидом или менеджером (если с вашей стороны есть хоть один человек, контролирующий процесс); документирование и хранение «скрытых знаний» – тех самых нюансов продукта, которые обычно живут в голове одного сотрудника и теряются при его уходе. У вендоров это обязательный процесс. Парадокс: экспертиза чаще теряется в инхаусе, а не в аутсорсе. Потому что в штате никто не заставляет ведущего инженера документировать каждый шаг. Аргумент 2: «В штате люди душой за продукт, аутсорсерам всё равно»  Что слышу: «Полноценный член команды переживает за качество, а человек от агентства – отбыл часы и ушёл». Реальность: зависит не от формы трудоустройства, а от культуры — и вашей, и подрядчика. Если у вас в штате текучка 2 года и зарплаты ниже рынка, никакой «душевности» там тоже нет. И наоборот: у нас на проектах люди сидят по 3–5 лет, знают продукт клиента глубже, чем кто-либо в самой компании клиента, и переживают за релизы лично. Потому что: аутсорсер живёт репутацией. Один прокатанный продакшен – и заказчик уходит к конкурентной QA team; в нормальной аутсорс-компании привязка инженера к проекту длинная – 1–3 года минимум, не «месяц поработал и ушёл»; KPI инженера часто завязаны на качество найденных дефектов и удовлетворённость клиента, а не на потраченные часы. Аргумент 3: «Аутсорс не разбирается в нашем сложном домене»  Что слышу: «У нас уникальный продукт (тяжёлый банковский домен, специфический рынок). Внешним подрядчикам туда не зайти». Реальность: в первые 2–4 недели при привлечении внешней QA компании действительно могут быть трудности; ну ладно, бывают исключения – как‑то у нас был кейс тестирования, где только ТЗ состояло из 15 тысяч страниц (это не опечатка!), поэтому мы 2 месяца выходили на полную мощь. Здесь всё зависит от вашей готовности дать вендору погрузиться в процессы и от его опыта в смежных областях. Например, из 530+ проектов у нас 20% – банки и страховые, 15% – веб‑студии, 14% – телеком, 12% – соцсети, 11% – e‑commerce. В нашей команде точно найдутся люди, которые уже работали на двух‑трёх проектах из вашей сферы. Более того – вот неудобная для штата правда: аутсорсер, который видел 15 банков, понимает «как принято в индустрии» лучше, чем штатный QA, который всю карьеру провёл в одном банке. Просто потому, что у него выборка шире, так как внешнее тестирование программного обеспечения даёт больше опыта. Аргумент 4: «Штатный сотрудник полностью под контролем» Что слышу: «Я могу подойти и сказать «сделай вот это срочно»». Реальность: в нормальном аутсорс-договоре прописан SLA по времени реакции, и для срочных задач это часы, а не дни. Плюс есть менеджер, который снимает с вас часть управленческой рутины – а это та самая нагрузка на тимлида в 18% его времени, которую мы посчитали выше (54 000 ₽/мес на каждого мидла). При независимом тестировании программного обеспечения эту работу делает аккаунт-менеджер вендора. Бесплатно для вас. Аргумент 5: «Будут проблемы с конфиденциальностью» Что слышу: «Наши данные нельзя отдавать на аутсорсинг, у нас секретный продукт». Реальность: NDA, договор с юридическим лицом, работа на ваших стендах через ваш же доступ (когда вендор не выгружает к себе ничего) закрывают более 90 % кейсов. Действительно режимные истории – гостайна, банки уровня ТОП‑3 с особым контуром – это да, скорее инхаус (хотя мы и с ними работаем – чётко и ответственно, проходя все проверки ИБ). В остальных случаях это не аргумент против аутсорсинга, это вопрос грамотно оформленного NDA и контроля доступов. Когда инхаус объективно лучше? Раз уж разобрали мифы, отдельно перечислю случаи, где штат реально и без оговорок выигрывает. Не упомянуть их – значит не быть до конца честным. Когда инхаус действительно лучше Почему Очень секретный или режимный продукт Гостайна, банки уровня ТОП-3 с особым контуром, оборонка – здесь даже идеальный NDA не закроет требований регулятора Продукт-флагман, на котором держится 80%+ выручки и где есть «коммерческая тайна» Стратегическая компетенция должна быть в штате. Это не про экономию, это про снижение бизнес-рисков Очень длинный, сложный домен Биллинг телекома, банковский core – погружение 1–2 года. Дешевле растить и удерживать своих Абсолютно стабильная, прогнозируемая нагрузка без пиков Если вам всегда нужны ровно 4 ручника и не больше – экономия от гибкости аутсорса меньше, чем накладные на коммуникацию с вендором. Сильная инженерная культура, которую вы целенаправленно строите Внутренние ритуалы, code review, общая ответственность за продукт – это плохо переносится через подрядчика Взрослые компании всё чаще выбирают гибрид На наших проектах в 2025–2026 годах я вижу устойчивый тренд: директора перестают мыслить категорией «всё в штат» или «всё на аутсорс». Они строят гибридные QA-команды для обеспечения качества. Типовая работающая модель выглядит так: В штате остаются: QA‑лид (или 1–2 лида на продукт), 1–2 senior‑инженера – «хранители знаний» по основному домену, тест‑аналитики, отвечающие за тест‑стратегию. На аутсорс уходят: массовая регрессия, написание и поддержка большого объёма тест‑кейсов, нагрузочные и security‑проверки, кросс‑браузерное и мобильное тестирование под пиковые релизы, экспертиза «по запросу». В такой модели вы держите «стратегическую» экспертизу внутри (тех людей, ради которых не жалко платить TCO более 350 тысяч рублей), а «дополнительные руки» арендуете в рамках внештатного QA-проекта – в зависимости от нужного в моменте объёма. Экономия на таких командах из 8 человек у наших клиентов – 25–40% годового бюджета на QA. Скрытые риски аутсорсинга тестирования Я обещал дать объективную картину, поэтому расскажу и про подводные камни. Потому что аутсорс услуг по тестированию программного обеспечения – это не только солнечные единороги и сэкономленные миллионы. Выбор подрядчика без должной проверки — это лотерея. Рынок аутсорса QA-услуг в РФ очень неоднородный. Есть компании, которые посадят на ваш проект студентов после двухнедельных курсов за 900 ₽/час с соответствующим качеством. Защита: запрашивать резюме всехпредлагаемых на проект людей, проводить с ними техсобеседования, прописывать в договоре уровень и опыт; коммуникационный оверхед на старте. В первые 2–3 недели работы аутсорс-команда не понимает ваш продукт так же глубоко, как ваш штат. Это нормально. Защита: закладывайте период погружения и ресурсы на коммуникацию и не ждите магии с первого дня; зависимость от вендора при плохой документации. Если вы передали 100% тестирования и подрядчик ленится оформлять артефакты – через год вы будете зависеть от него. Защита: с первого дня требовать ведение всей документации в вашей системе и регулярную передачу артефактов. Сводная таблица инхауса и аутсорса тестирования  Плюсы и минусы без розовых очков, да и без чёрных тоже. Автор: Эди Стоукс (Ady Stokes) Оригинал статьи Перевод: Ольга Алифанова Почему я это пишу Если вы какое-то время работаете тестировщиком ПО или в разработке, вы, скорее всего, сталкивались с термином «ручное тестирование». Это выражение может вызывать бурные споры. И дело не только в разных мнениях. Сам термин часто искажает суть тестирования. В худшем случае «ручное тестирование» создает вредный водораздел, обесценивая вклад человека и чрезмерно возвышая автоматизацию. В лучшем — умаляет значимость вдумчивых усилий тестирования. В этой статье хочу обсудить, почему этот термин может быть вреден для ремесла тестирования, и предложить, как сместить фокус к более инклюзивному и точному пониманию того, что на самом деле делают тестировщики. Кто знает, исчезнет ли когда-нибудь термин «ручное тестирование», но попытаться мы можем и должны. ]]> https://software-testing.ru/library/around-testing/job/4493-the-skills-of-software-testers Mon, 25 May 2026 23:00:00 +0300 О нагрузочном тестировании для менеджеров, продактов, маркетологов и основателей стартапов. В статье собрали всё, что нужно знать, чтобы задавать инженерам правильные вопросы и принимать решения на основе данных, а не интуиции. Почему мы это написали или история про маркетолога За последний месяц к нам три три клиента с запросом на нагрузочное тестирование. С двумя из них – техническими руководителями – разговор шёл в привычном режиме: обсуждали профили нагрузки, перцентили, узкие места в базе данных, сценарии деградации. Всё понятно и по делу. Третий клиент оказался другим. Сотрудник отдела маркетинга давнего партнёра – человек, который отвечает за планирование рекламных кампаний и хочет понимать, что произойдёт с продуктом во время запуска крупной акции. Для него технический разговор превратился в информационный шум. И дело не в недостатке опыта – просто у человека совсем другой контекст: иные задачи, риски и даже профессиональная терминология. Мы провели для него краткий ликбез: рассказали о видах нагрузочного тестирования, объяснили, как интерпретировать результаты и как это связано с его работой. Произошло неожиданное: вместо одной услуги были заказаны две и теперь затраты на тестирование включены в маркетинговый бюджет клиента на постоянке – его проводят перед каждой крупной рекламной кампанией или акцией. А всё потому, что человек понял какие его профильные задачи решает тестирование производительности. Для нас это тоже стало ценным опытом: мы смогли наладить взаимодействие между инженерами и маркетологами, добавить специальные имитации трафика с учётом особенностей их целевой аудитории и выработать совместный рабочий процесс. Статья создана для тех, кому важно не просто почитать о том, что такое нагрузочное тестирование, а понять тему достаточно для того, чтобы на встрече с техническими специалистами задавать точные и осмысленные вопросы, направленные на достижение результата. Что на самом деле происходит под нагрузкой? Ваша система – это не просто «сервер». Это цепочка компонентов, каждый из которых имеет свой предел: серверная часть приложения, база данных, очередь задач, файловое хранилище, внешние интеграции. Когда к вам одновременно приходит много пользователей, то узкое место обнаруживается там, где вы меньше всего этого ожидали. До определённого порога система ведёт себя предсказуемо: трафик усиливается – время отклика растёт незначительно. Затем наступает точка насыщения – и начинается то, что инженеры называют «хоккейной клюшкой»: время отклика резко взлетает, пропускная способность перестаёт расти и начинает падать. Автор: Парвин Хан (Parveen Khan) Оригинал статьи Перевод: Ольга Алифанова Что такое bug bash? Вам когда-нибудь хотелось превратить тестирование в вечеринку? Bug bash как раз позволяет это сделать! Ну, не всё там сводится к веселью и играм: обычно самый крепкий напиток — это чёрный кофе, и вряд ли вам захочется нанимать диджея – но при этом можно неплохо провести время и заодно узнать важные вещи о продукте и качестве. Bug bash укрепляет сотрудничество, даёт возможность выслушать разные точки зрения и помогает формировать и укреплять культуру качества. Обычно bug bash выглядит примерно так: Вы приглашаете кросс-функциональную команду: тестировщиков, разработчиков, продакт-оунеров, дизайнеров, стейкхолдеров. Иногда это просто продуктовая команда, а иногда — люди, которые обычно не ходят на ваши встречи – например, юристы или маркетологи. Важно пригласить и тех, кто ещё не пользовался продуктом (или не пробовал новые фичи). Вы задаёте общие правила тестирования продукта. Как и на обычной вечеринке, хороший хозяин должен обозначить ожидания и рамки. Веселитесь! Геймифицируйте тестирование (несколько идей ниже). В течение нескольких часов или даже нескольких сессий по паре часов команда сосредоточенно тестирует продукт, следуя заданным правилам. Обязательно заложите время на перерывы. Закуски и напитки тоже всегда приветствуются.]]> https://software-testing.ru/library/testing/other-testing/4482-how-to-throw-a-bug-bash-a-tester-s-guide Mon, 18 May 2026 23:00:00 +0300 Автор: Анатолий Бобунов Меня зовут Анатолий Бобунов, я работаю SDET в компании EXANTE. Однажды я пришел на проект, на котором выполнение некоторых тест-сьютов занимало больше часа, настолько медленно, что запускать их на каждый merge request (MR) было просто нереально. Мы хотели запускать автотесты на каждый коммит в MR, но с такой скоростью это было невозможно. В результате мне удалось, за счёт серии небольших, но точных изменений добиться 8,5-кратного ускорения - без переписывания тестов с нуля. В статье расскажу, какие проблемы у нас возникли и как мы их решали. ]]> https://software-testing.ru/library/testing/testing-automation/4517-python-pytest Wed, 13 May 2026 23:00:00 +0300 Автор: Кастури Раджаманиккам (Kasturi Rajamanikkam) Оригинал статьи Перевод: Ольга Алифанова Знаете ли вы, что Chrome DevTools предназначены не только для разработчиков, но и для тестировщиков? Для QA-специалиста важно не просто находить баги — понимание первопричин их появления и умение предложить возможные решения выводит тестирование на новый уровень. Если вы не пользуетесь Chrome, аналог Chrome DevTools с похожим функционалом можно найти в любом современном браузере, так что вы можете выполнять эти проверки в браузере по своему выбору. Чтобы максимально эффективно использовать Chrome DevTools, тестировщикам стоит иметь базовые знания HTML, CSS, DOM, JavaScript и уметь читать сетевые ответы. ]]> https://software-testing.ru/library/testing/testing-tools/4484-10-powerful-tests-with-chrome-devtools Mon, 11 May 2026 23:00:00 +0300 Специалист по тестированию Харитон Дунько поделился, как нашёл с коллегами то, что ломало конверсию онлайн-магазина и приводило к потере клиентов. В прошлой статье я писал о важности проведения юзабилити‑тестирования с привлечением реальных пользователей. Теперь пишу в продолжение темы, но под другим углом – и тоже о реальном кейсе, всё, как вы любите. Расскажу, как получили задачу протестировать интернет-магазин автозапчастей и что из этого вышло. Скажу честно, случай нестандартный, так как обратился к нам с запросом на тестирование директор по маркетингу, а не техлид, как это обычно бывает. В последние месяцы отчётливо видна тенденция, когда маркетологи, уставшие от разборок с разработчиками, привлекают независимых тестировщиков для оценки продукта. Можно сколько угодно говорить о продвинутом функционале и отсутствии багов в интернет-магазине, но показатель конверсии и отток пользователей никогда не обманывают. Когда сайт интернет‑магазина запускают или он активно растёт, основные усилия обычно направляют на каталог, интеграции с поставщиками и рекламу. Но что, если покупок мало не из‑за цены или ассортимента, а потому что поиск не ищет, фильтр не фильтрует и прочих незаметных, но важных факторов? Вот именно такие неточности нужно было найти в рамках проведения исследовательского тестирования и UX‑аудита сайта розничной торговли автозапчастями. Задача была в том, чтобы посмотреть на сайт глазами обычного покупателя: сможет ли он найти нужный товар, поймёт ли, как оформить заказ, не уйдёт ли к конкурентам?. Особенности UX‑аудита интернет-магазина Без плясок с бубнами не обошлось, поскольку документации по функционалу маркетплейса не было. Пришёлся кстати подход исследовательского тестирования «тест‑туры», по методологии Джеймса Уиттакера (James A. Whittaker). При этом фокус был на Турах по деловому центру (Tours of the Business District), т. е. упор делался на те функциональности, ради которых пользователи приходят на сайт и делают заказы. В частности, я использовал следующие туры: The Money Tour (поиск товара, добавление в корзину, оформление заказа, т. е. всё то, что оказывает прямое влияние на конверсию и выручку); The Guidebook Tour (навигация, хлебные крошки, структура каталога, т. е. то, что помогает пользователю не потеряться и дойти до покупки); The Landmark Tour (поиск по VIN или FRAME, фильтры, карточки товаров, т. е. те уникальные фичи, которые помогают пользователю); The FedEx Tour (доставка, пункты выдачи, интеграция с ПВЗ, т. е. логистика); The Garbage Collector Tour (опечатки, битые ссылки, некорректные названия, т. е. то, что сразу не видно, но при обнаружении оставляет негативный осадок и подрывает доверие). Такой подход позволил быстро выявить не только технические баги, но и системные проблемы UX, которые не видны при формальном тестировании. Проверив сайт нашего заказчика, а затем сравнив его с конкурентами, я выделил несколько проблем, которые отпугивают клиентов в следующих ключевых модулях. Поиск онлайн-магазина Этот модуль – главная точка входа. Если он не работает, то пользователь уходит. И вот что здесь было не так: Поиск по артикулу выдавал несколько полностью идентичных товаров с разной ценой. При поиске по бренду (например, Bosch) список не фильтровался, а выбранный бренд не визуализировался вверху списка. При вводе длинного названия товара текст «уезжал» под иконку лупы. Поиск по VIN/FRAME не работал для новых и относительно новых автомобилей. Например, VIN автомобилей 2024 года выпуска сайт не видел. В целом в модуле поиска товаров было найдено 14 ошибок на десктоп‑версии и 5 в мобильной. Фактически базовый сценарий «найти и купить» ломался на первых шагах. Как эти проблемы влияют на бизнес? Всё просто: пользователь теряет доверие к системе, а значит, и к товарам сайта. Это прямо отражается на конверсии и индексе качества сайта в глазах поисковых систем (низкие поведенческие факторы). Тестирование корзины и оформления заказа Это ключевой рубеж. Здесь ошибки стоят дороже всего. Например, многие пользователи, увидев пустую корзину после первого клика, решат, что функция не работает, и откажутся от повторной покупки. А это прямая потеря повторных продаж. И вот какие проблемы мы обнаружили: Счётчик в корзине показывал количество наименований, а не штук (добавил 3 штуки, а в корзине было написано «1»). Товары не добавлялись с первого раза при повторе заказа из истории. Поля «Имя» и «Фамилия» принимали спецсимволы (ввёл «!!!», и заказ оформился). Кнопка «Оформить» была активна при невалидных данных. Фильтры и каталог интернет-магазина Это как навигатор в большом океане данных. Если они сломаны, пользователь блуждает, но не тонет, а просто отчаливает на сайт конкурентов. Согласно исследованиям Baymard Institute1, 60% пользователей покидают сайт, если не могут эффективно отфильтровать товары. Каждая такая потеря – минус потенциальный заказ. И даже мелкие неудобства в корзине увеличивают процент брошенных чекаутов на 5–8%. И вот какие досадные ошибки были найдены тут: Ползунок цены не двигался, а ручной ввод сбрасывался. Выбранный бренд не подсвечивался. Категории без подкатегорий отображались по‑разному на десктопе и мобайле. В целом по модулям «Корзина» и «Профиль» было зафиксировано 6 ошибок в вебе и 1 в мобильной версии плюс 7 проблем валидации в профиле, напрямую влияющих на завершение покупки. Мобильная версия в e-commerce Около 40–60% трафика в e‑commerce происходит с использованием мобильных устройств2. Если мобильная версия неудобна, то вы теряете половину клиентов. Это новая реальность. Вот что в этом модуле было найдено интересного: Виджет чата перекрывал кнопку «Войти», и не было возможности авторизоваться. Футер перекрывал кнопки в каталоге по VIN, в т. ч. невозможно было получить данные о детали. При смене ориентации экрана баннер региона появлялся вновь и вновь, даже если выбор был сделан (очень раздражающее поведение). Пагинация «наезжала» на кнопки при длинных номерах страниц. Всего в мобильной версии было найдено 7 критических проблем, не считая минорных. Это тот случай, когда адаптивный дизайн есть, но пользоваться им невозможно. Доверие покупателей и контент Мелочи убивают лояльность. Орфографические ошибки, дубли, несоответствия – всё это работает против вас. И здесь тоже не обошлось без неприятных сюрпризов: Названия товаров в истории заказов менялись. Заказываете «Тормозная жидкость», а в истории отображается «Жидкость (L 05 005)». Полное дублирование категорий товаров. Логотип в хедере был на английском, а в футере – на русском. Контактные телефоны в хедере и футере не совпадали. Итоговый результат тестирования интернет-магазина Всего было обнаружено 67 ошибок и сформулировано 55 рекомендаций по улучшению. Причём из 67 ошибок было 9 Critical уровня, которые блокировали ключевые сценарии, 28 Major уровня, которые существенно ухудшали UX, 23 Minor уровня – это в основном визуальные и логические недочёты, а также 7 Trivial уровня, т. е. какие‑то косметические неточности. В итоге заказчик увидел свой сайт глазами клиента и был неприятно удивлён, но выразил нам благодарность, был удовлетворён и обещал исправить найденные баги и применить рекомендации. И что важно – мы сотрудничаем по сей день. Нам было особенно приятно получить такой результат на фоне того, что разработчики скептически отнеслись к нам в начале и твердили: «Пользователи сами не знают, чего хотят». А мы им детально показали, что пользователи просто не могут купить то, что хотят. Вывод Многие компании откладывают поиск и исправление «некрасивых» доработок, фокусируясь на новых фичах. Владельцы интернет-магазинов часто считают, что если сайт как‑то работает, то всё в порядке. Но инвестиции в качество в связке с маркетингом окупаются быстрее, чем продвижение «дырявого» продукта. Исследовательский аудит вскрывает десятки проблем, которые не ловятся стандартными тестами, но при этом режут конверсию на 10–30% и выше. Наш кейс – живое доказательство. Ведь он про то, как пользователи на самом деле взаимодействуют с продуктом и где спотыкаются. На проекте мы не просто составили список ошибок. Мы показали, как каждая из них влияет на путь клиента к покупке. И предложили конкретные шаги, которые можно внедрить уже сейчас. Хотите узнать, какие скрытые проблемы тормозят рост вашего интернет‑магазина? Мы проводим исследовательское тестирование e‑commerce проектов любой сложности с фокусом на конверсию и пользовательский опыт. Напишите нам, чтобы обсудить, как помочь вашему онлайн-магазину продавать лучше. ]]> https://quality-lab.ru/blog/issledovatelskoe-testirovanie-i-uxaudit-dlya-internet-magazina/ Thu, 07 May 2026 10:59:41 +0300 Оригинальная публикация Мой путь в ИБ начался с нуля - у меня не было опыта работы и образования в айти в целом, будь это системное администрирование или программирование. Я просто планомерно учился и сдавал сертификации. За три года у меня собрался определенный стек: OSCP, HTB CWES, CRTP, PNPT, PJPT, PJOR, CompTIA A+, Network+ и Security+. Когда пришло время искать работу пентестером, я столкнулся с реальностью: вакансий в моем регионе почти нет, а те, что находил, не приносили даже приглашений на собеседование. Профиль без практического опыта не вызывал интереса у работодателей. Чтобы начать нарабатывать реальный стаж, я решил попробовать себя в багхантинге. Основная цель была простой получить опыт и проверить свои знания в бою, а не в лабораторной среде. Ну и, конечно, был интерес заработать репутацию практика и получить первые выплаты. ]]> https://software-testing.ru/library/testing/testing-tools/4516-bug-bounty Wed, 06 May 2026 23:00:00 +0300 Автор: Эмили О’Коннор (Emily O’Connor) Оригинал статьи Перевод: Ольга Алифанова Меня зовут Эмили, я ведущий инженер по тестированию, и я считаю, что пришло время попрощаться с написанием трудоёмких актов сдачи дел и поприветствовать тестирование, которое эффективно, даже когда вы в отпуске или отсутствуете на работе. По роду своей деятельности я работаю с разными командами и вовлечена в множество проектов, которые ведутся в компании. ]]> https://software-testing.ru/library/testing/general-testing/4481-when-the-tester-s-away-the-team-can-test-anyway Sun, 03 May 2026 23:00:00 +0300 Знакомая история: команда полгода пилила фичу, тестировщики нашли все баги, релиз вышел чистый, как слеза младенца. А пользователи… не оценили. Воронка ломается на третьем шаге, поддержка задыхается от тикетов «не могу найти эту вашу кнопку», CFO смотрит на расходы и тихо плачет. Что произошло? Да, вполне привычная история. Продукт прошёл функциональное тестирование, но не прошёл главный тест – встречу с реальным человеком. Классический QA не лечит кривой UX. Он вообще не про это. Можно покрыть продукт автотестами на 100%, прогнать регрессию, получить зелёненький отчёт и всё равно слить релиз – потому что пользователь не понял, куда жать. И вот тут на сцену выходит юзабилити‑тестирование. Не «ещё один вид тестирования», не «опционально, если останется бюджет», а инструмент управления риском провала продукта. Мы подготовили информационный концентрат: что, как и в каком порядке делать. Главное недоразумение: юзабилити – это не про «удобство» Если в вашей команде юзабилити‑тестирование воспринимают как «ну, чтобы пользователю было удобненько», то у вас проблема на уровне базовых установок. Юзабилити – не про красоту и не про комфорт. Это побочные эффекты. Истинная цель – прибыль. В удобном интерфейсе пользователь легко и с удовольствием доходит до целевого действия. Растут конверсии, а за ними и выручка. Каждая лишняя кнопка, каждый невнятный лейбл – это деньги, утекающие мимо кассы. Когда вы это поймёте, юзабилити перестанет быть для вас «второстепенным видом тестирования где‑то после нагрузочного» и станет центром работы по выживанию и росту продукта. И ещё. UX‑проектирование – это весь процесс создания интерфейса от ресёрча до макетов. Юзабилити‑тестирование – этап обратной связи внутри этого процесса. Без него UX превращается в ритуальные пляски с бубном по канонам Material Design: вроде красиво, а летит ли – непонятно. Шесть вопросов, на которые отвечает юзабилити‑тест Полезный? Продукт вообще решает задачу пользователя – или мы его нарисовали, потому что нам показалось красиво? Эффективный? Сколько кликов и минут уходит на цель? Сколько из них лишние? Каждое лишнее действие – упущенная конверсия. Понятный? Нужна ли инструкция, чтобы пользоваться? Если да – у нас плохие новости. Без ошибок пользователя? Не функциональные баги, а – может ли человек сам ошибиться и насколько легко это исправить? Контролируемый? Понимает ли пользователь, что будет на следующем шаге? Может ли вернуться, остановиться, проверить? Приносит удовлетворённость? Хочется ли возвращаться? Не можете уверенно ответить «да» на каждый из шести по своему продукту – садитесь, читаем дальше. Подготовка: пять шагов, без которых юзабилити‑тест превратится в шапито Ставим цели Самый главный шаг и самый игнорируемый, к сожалению. Без чёткой цели тест превращается в «давайте посмотрим, что не так». Цель всегда привязана к стейкхолдеру: маркетинг хочет конверсии, поддержка – снижения тикетов «как это сделать?», продакт – отстройки от конкурента, юристы – соответствия WCAG. Сначала вопрос – потом инструмент. Выбираем методики под задачи В юзабилити‑тестировании больше десятка методик, и каждая – под свою задачу. Использовать одну для всего – это забивать гвозди микроскопом. Методика Когда применять Think-aloud Прототипы, ранние этапы. Когда нужны ментальные модели, а не метрики. Session Recording Прод с массовой аудиторией. Где люди отваливаются, тепловые карты. Time to Done Сравнение версий интерфейса. Эффект редизайна в секундах. Card Sorting Проектирование меню, навигации, структуры каталога. GOMS, KLM Профессиональное ПО, где каждая секунда на счету (call-центры, трейдинг). SUS, UMUX Регулярные количественные замеры юзабилити (индекс 0–100). Cognitive walkthrough Этап проектирования, живых пользователей ещё нет. Хронометраж сессий B2B-системы, где «длинные» шаги (возвраты, согласования, выгрузки). Эвристики Нильсена Быстрая ревизия силами эксперта. Когда нет ресурсов на пользовательский тест. Коридорные тесты 5–10 минут с первым встречным. Проверить, не стало ли хуже после правок. WCAG Госуслуги, образование, международные рынки, аудиты. Определяемся с целевой аудиторией Тестировать продукт на «случайных людях» – путь в никуда. Бабушка, зашедшая в приложение для зумеров, не даст вам полезных данных про продукт. Готовим сценарии Самая частая ошибка – давать пользователю инструкцию вместо сценария. Плохой сценарий: «Найдите раздел „Книги“, выберите жанр „Фантастика“, добавьте книгу в корзину». Хороший сценарий: «Представьте, что хотите купить подарочную книгу для друга, которому нравится фантастика. Покажите, как бы вы это сделали». Плохой тестирует, насколько хорошо человек умеет читать инструкции. Хороший – ваш интерфейс. Правило железное: в сценарии не должно быть слов, которые пользователь увидит в интерфейсе. Эту ошибку допускают все – от джунов до продактов с десятилетним стажем. Перечитайте каждый сценарий и отфильтруйте. Собираем инструменты Zoom/Google Meet – для модерируемых сессий. Hotjar/Метрика – для записи и тепловых карт. Maze, UXtweak, PlaybookUX, Useberry – специализированные платформы. Если первые четыре шага сделаны нормально – выбор инструмента уже мелочь. Если напортачили – ни Maze, ни Fullstory не спасут. Хотите научиться быстро и эффективно выбирать подходы для юзабилити‑тестирования? Мы собрали в одном файле 20 методик юзабилити‑тестирования. Это удобная шпаргалка для QA‑лида, продакт‑менеджера или UX‑исследователя. По каждой из методик: суть, когда и для чего применять, что для этого нужно, какого результата ожидать. Заполните форму, и мы отправим документ вам на электронную почту. Проведение: от подготовки до сбора данных Перед запуском обязательно проведите пилотный прогон. Прогоните первый тест на близком к ЦА пользователе (не на дизайнерах или маркетологах, которые знают продукт). Ведите себя как с настоящим участником: никаких «ой, это просто тест», не делайте подсказок. Запишите пилот на аудио или видео. Пересмотрев, вы внезапно можете обнаружить, что половину времени перебивали или формулировали задачи невнятно. Сделайте работу над ошибками. Приступайте к работе в реальных условиях Перед каждой сессией говорите пользователю волшебную фразу: «Тест проходит интерфейс, а не вы». Это переключает участника из режима «как бы не опозориться» в режим «помогаю проекту». Попросите думать вслух, предупредите, что будете молчать. Во время сессии: Запись (с разрешения) – всегда. Заметки по ходу – Google Doc, Excel, что угодно. Не подсказывайте. Совсем. Если совсем тупик – открытый вопрос: «Что вы ожидаете увидеть здесь?». Фиксируйте моменты, где человек спотыкается, бесится, возвращается. Эмоции – это данные. Укладывайтесь в 30–45 минут. Длиннее – пользователь устаёт и начинает врать. В «Лаборатории Качества» мы видели десятки случаев, когда модератор не выдерживал, начинал «помогать» участнику – и весь тест летел в мусорку. Молчать тяжело, но необходимо. Не допускайте эту критическую ошибку. Анализируйте с умом Ловите паттерны, а не единичные случаи. Один человек – ещё не показатель, так как есть факторы в виде личностных особенностей, плохого настроения и т. д. А вот если 3+ пользователей запнулись на одном месте – это сигнал. По канонам Якоба Нильсена 5 пользователей выявляют около 85% юзабилити‑проблем – поэтому необязательно собирать огромные выборки. Главное – чтобы эти пять человек были из вашей реальной ЦА. После всех сессий группируйте проблемы по категориям: навигация, тексты, визуал, функционал, мобилка. Простейшая таблица закрывает 80% задач: участник, сценарий, что получилось, где сложности, цитаты, время, severity (1–3). Цитаты пользователей в отчёте – отдельная магия: одна фраза «А где вводить промокод?» убеждает продакта сильнее, чем десять страниц сухих данных. Чек‑лист «бери и делай» Если хотя бы половина пунктов отсутствует в вашем процессе – у вас не юзабилити‑тестирование, а имитация бурной деятельности. Перед тестом Цель сформулирована и привязана к стейкхолдеру. Методика выбрана под цель (см. таблицу выше). ЦА описана конкретно, с критериями отбора. Сценарии – как истории, без слов из интерфейса. Прототип работает, кликабелен, без багов. Проведён пилот с записью и пересмотром. Во время сессии Сказали «тест проходит интерфейс, а не вы». Попросили думать вслух. Включили запись. Молчите, не подсказываете. Уложились в 30–45 минут. После сессии Считаете паттерны (3+), не единичные случаи. Группируете по категориям, расставляете severity. Делаете отчёт с цитатами и фрагментами видео. Команда формирует план действий, вносит правки, при необходимости отдаёт продукт для повторного теста. Когда мы в «Лаборатории Качества» заходим на проекты по запросу «у нас всё ок, просто помогите ускорить регрессию», часто оказывается, что регрессия – последняя из проблем. На первом месте – пользователь, который не может за три клика сделать то, ради чего вообще пришёл. И вопрос меняется с «как нам быстрее тестировать?» на «как нам перестать делать продукт, который никому не понятен?». Вот ради этого вопроса и существует юзабилити‑тестирование. А у вас как? На каком этапе тестируете юзабилити – на прототипе, на бете или (а вы любите рисковать) после релиза? Какие методики реально зашли, а какие оказались неоправданными? Делитесь в комментариях. Если у вас сейчас появилось много вопросов и мыслей – напишите нам, обсудим без галстуков. Реальный опыт – лучшая валюта в нашей отрасли, и мы готовы делиться. ]]> https://quality-lab.ru/blog/yuzabiliti-testirovanie-bez-rozovykh-ochkov/ Wed, 29 Apr 2026 13:55:19 +0300 Автор: Леонид Сухин Я фанат тестов. Очень люблю, когда основные части моего кода покрыты полностью, от и до. Первая очевидная причина, для чего это нужно: если я закрываю задачу, то должен более-менее точно знать, что действительно ее выполнил. Тесты помогают получить такую уверенность. Вторая причина: хочется иметь возможность безболезненно вносить изменения и проводить рефакторинг. Наличие тестов позволяет делать это, пусть и с опаской. Если тестов нет, то рефакторинг либо невозможен, либо может стать серьезным испытанием для команды, ведь придется проводить регрессионное тестирование большого количества функционала. Подход, который я долгое время использовал массово - написание юнит-тестов с использованием Mockito. В заглушки превращается любой сторонний сервис, используемый тестируемым классом. Тесты супер-быстрые, все зеленое, все супер! Со временем я заметил, что этот подход начал изрядно напрягать. Часто на две строчки кода приходилось писать не менее 10-20 строк теста. Огромное количество переопределений поведения заглушек. Проверки, что тот или иной метод сторонних сервисов более не вызывался или вызывался не более определенного количества раз. Без преувеличения, огромное количество бойлер-плейт кода в тестах. Дальше - больше. Множество зеленых галочек, появляющееся на экране при запуске тестов, не могло не радовать. Но вот ты решаешь сделать минимальный рефакторинг, оптимизировать какой-то метод. В этот момент все разваливается на куски. Куча красных тестов! Как, почему? Да просто во внутренней реализации ты перешел на использование другого метода, добавил в метод еще один параметр или что-то подобное. В результате куча тестов перестала работать. И теперь, поменяв одну строчку в процессе рефакторинга, надо поменять еще 30 строк в тестах. В какой-то момент начинаешь ловить себя на мысли - “Ни в коем случае, никаких рефакторингов больше!” ]]> https://software-testing.ru/library/testing/testing-automation/4515-testcontainers- Tue, 28 Apr 2026 23:00:00 +0300 Автор: Борис Добрецов (Boris Dobretsov) Оригинал статьи Перевод: Ольга Алифанова В этой статье я расскажу о жизненном цикле и состояниях приложений для iPhone и iPad. Но подождите — зачем вам вообще это знать? Сейчас объясню. Понимание того, как приложение переходит между состояниями, помогает находить коварные баги, воспроизводить реальные сценарии использования и убеждаться, что всё работает гладко — даже когда приложение чем-то занято в фоне. ]]> https://software-testing.ru/library/testing/mobile-testing/4480-10-ways-to-test-ios-apps-across-different-states-and-lifecycle-stages Sun, 26 Apr 2026 23:00:00 +0300 Автор: Дюжев Михаил Вдохновлено Михаилом Ивановым, коллегой и товарищем, который напомнил про "Мир искусства" В разговорах с коллегами иногда всплывает тема образования. Клинический психолог, говорю. Собеседник вежливо кивает и переходит к следующей теме. Понятно: какое отношение психология имеет к тестированию? Прямое. Но не потому, что я умею "понимать людей" или "находить подход к разработчикам". Дело в другом предмете из учебного плана. На третьем курсе нам читали философию науки: Декарт, Поппер, Лакатос, Кун, принцип фальсифицируемости, бритва Оккама. Три семестра о том, как человечество училось отличать знание от заблуждения. Тогда это казалось красивой, но бесполезной абстракцией. Ну зачем практикующему психологу знать, как Карл Поппер спорил с венскими позитивистами, а Имре Лакатос уточнял его идеи? Прошло пятнадцать лет. Я давно не психолог, я руковожу тестированием. И в какой-то момент вдруг осознал: я каждый день делаю ровно то, о чём рассказывали на тех лекциях. Ищу минимальный воспроизводимый сценарий - это декартовское деление сложного на простое. Формулирую гипотезу так, чтобы её можно было опровергнуть - это Поппер. Выбираю самое простое объяснение из возможных - это Оккам. Оказалось, философия науки - это не про философию. Это операционная система для мозга, который работает с неопределённостью. И эту статью я вынашивал не один год, чтобы наконец объяснить, почему. ]]> https://software-testing.ru/library/testing/general-testing/4514-descartes-popper-bug-in-production Thu, 23 Apr 2026 23:00:00 +0300 Зачем QA‑инженеру читать законы? Картина маслом: выкатываем долгожданный релиз. Архитектура вылизана, покрытие автотестами близко к 100 %, бэкенд держит нагрузку как спартанцы, фронт сверкает. Продакт‑менеджер открывает шампанское, CTO довольно выдыхает. А через месяц в компанию прилетает «письмо счастья» от РКН или ФАС – штраф на полмиллиона рублей. За что? Например: чекбокс согласия на обработку персональных данных на форме регистрации был прожат по умолчанию (нарушение ч. 4 ст. 9 Федерального закона от 27.07.2006 № 152‑ФЗ «О персональных данных»); в рекламном баннере на главной странице забыли зашить токен маркировки (нарушение требований ч. 17 ст. 18.1, последние изменения в которую внесены 26.12.2024, Федерального закона № 38‑ФЗ «О рекламе»). Кто виноват? Юристы, которые не проверили прод? Продакт, который забыл поставить задачу? Разработчик, который скопипастил старый компонент? Чаще всего мы слышим от CTO и лидов, когда приходим на аудит процессов к клиентам, одно и то же: «Ну, это же юридические вопросы, при чём тут тестирование?»При том, что юристы не умеют открывать DevTools, не тестируют позитивные и негативные сценарии в формах и редко заходят на тестовые стенды. А баги комплаенса стоят бизнесу намного дороже, чем поехавшая вёрстка. При том, что юристы не умеют открывать DevTools, не тестируют позитивные и негативные сценарии в формах и редко заходят на тестовые стенды. А баги комплаенса стоят бизнесу намного дороже, чем поехавшая вёрстка. Иллюзия «технического» QA Исторически сложилось, что от тестировщиков ждут проверки функций. Кнопка нажимается? Данные в базу уходят? 500‑ю ошибку не выдаёт? Отлично, в прод! Когда клиенты приходят к нам за аутсорсом тестирования, они обычно приносят пачку ТЗ и ожидают, что мы просто разгрузим их внутреннюю команду: заберём на себя регресс, напишем тест‑кейсы, настроим автоматизацию. И когда на этапе планирования мы предлагаем включить в стратегию проверок комплаенс‑тестирование, многие искренне удивляются. Но для нас QA – это не только поиск технических дефектов, но и управление рисками продукта. Риск блокировки домена или крупного штрафа – серьёзный блокер, рядом с которым меркнет большинство багов в логике. Что мы проверяем, пока вы думаете, что мы просто кликаем по кнопкам Мы давно внедрили в наши процессы слой проверок, о которых большинство продуктовых команд даже не задумывается (пока не клюнет жареный петух). Разумеется, всё это мы заранее согласовываем с клиентом, адаптируя под специфику его ниши. Вот лишь несколько примеров того, что наши инженеры ищут на проектах, помимо стандартных функциональных багов. Ловушки 152‑ФЗ (персданные) Мы проверяем не только наличие текста про политику конфиденциальности. Мы проверяем поведение системы. Блокируется ли отправка формы, если чекбокс не прожат? Не собирает ли форма лишние данные (принцип минимизации)? Корректно ли работает отзыв согласия из личного кабинета, или кнопка «Удалить аккаунт» – это просто заглушка, которая ставит флаг is_deleted в БД, оставляя данные лежать мёртвым грузом? Маркировка рекламы (38‑ФЗ) Боль. Сплошная боль современного рунета. Наши автоматизаторы и ручники проверяют наличие erid токенов в ссылках или на баннерах. Если на проекте есть своя крутилка баннеров, тестировщик убедится, что данные об ИНН рекламодателя не отваливаются при ресайзе окна. Тёмные паттерны и защита прав потребителей Знаете, как Роспотребнадзор любит штрафовать за заранее проставленные галочки на платные страховки или SMS‑информирование в корзине? Мы вычищаем эти «тёмные паттерны» на этапе тестирования флоу покупки. Мы проверяем прозрачность рекуррентных платежей, чтобы клиент чётко видел условия до того, как привяжет карту. Почему это работает именно в аутсорсе? Справедливый вопрос: «Почему я не могу поручить это своим тестировщикам?» Можете. И должны! Но давайте будем реалистами. Инхаус‑команды часто перегружены и не всегда имеют релевантную квалификацию. Они бегут в спринтах, горят в дедлайнах и тонут в техдолге. У них просто замыливается глаз. Когда нужно срочно протестировать новый сложный алгоритм рекомендаций, про проверку возрастного шлюза вспоминают в последнюю очередь. Внешняя команда приносит не только свежий взгляд, но и готовые решения: отполированные фреймворки, чек‑листы и методики (например, «Лаборатория Качества» на рынке 17 лет; естественно, мы работаем с базой, отполированной годами). Например, мы уже на старте говорим: «Ребята, вы делаете финтех‑продукт. У вас здесь дыра в процессах авторизации (по новому закону нельзя регистрировать граждан через зарубежные SSO), а вот здесь оферта не соответствует флоу оплаты». Таким образом, без промедления превращаем юридические абстракции в конкретные шаги для воспроизведения. Да простят нас ваши, и без того перегруженные тестировщики, мы поделимся своим базовым чек-листом, благодаря которому можно проверить хотя бы базовые комплаенс-риски. Качайте бесплатно здесь. Любой QA – это партнёрство, а не просто сервис Рынок изменился. Законы стали жёстче, штрафы – больше, а внимание контролирующих органов – пристальнее. Если ваши тестировщики до сих пор проверяют только то, что написано в ТЗ, вы оставляете свои бизнес‑фланги открытыми. Крутой QA‑инженер сегодня – это немного юрист, немного безопасник и во многом – мотивированный адвокат бизнеса. Поэтому, отдавая тестирование на аутсорс, ищите не просто «руки», которые будут кликать по кнопкам. Ищите партнёров, которые понимают, в какой реальности работает ваш продукт, и готовы защищать его со всех сторон. Международный контекст Кстати, а что делать, если ваш продукт выходит на внешние рынки, где существуют свои жёсткие регуляции и даже оборотные штрафы? Тут всё просто: меняются законы, но не инженерные подходы, потому мы также учитываем практики наших иностранных коллег, базирующихся на GDPR (ЕС), HIPAA (США), PIPEDA (Канада) и других. Раньше мы не делились такими практиками в блоге, но сейчас тема комплаенса и юридических рисков через призму инженерных подходов становится всё актуальнее. Как считаете, стоит ли шире освещать подобные вопросы? Оставьте комментарий под статьёй или свяжитесь с нами любым другим способом, указанным на сайте. Будем благодарны за ваши мысли и предложения! ]]> https://quality-lab.ru/blog/a-vashi-testirovshhiki-zashhishhayut-vash-produkt-i-kompaniyu-ot-millionnyx-shtrafov/ Wed, 22 Apr 2026 10:40:11 +0300 Автор: Арун Вишуанатан (Arun Vishwanathan) Оригинал статьи Перевод: Ольга Алифанова Когда десять лет назад я начинал свою карьеру тестировщика, я был только со школьной скамьи, и формальных подходов к тестированию не знал. Позже, работая с разработчиками в командах разного размера, я узнал о нескольких подходах, включая разработку через тестирование (TDD). Я надеюсь поделиться некоторыми наблюдениями о том, когда, по моему опыту, целесообразно применять TDD. Я также расскажу о случаях, когда традиционные подходы к тестированию или гибридный подход могут быть более подходящими, чем TDD сам по себе. ]]> https://software-testing.ru/library/testing/testing-automation/4458-test-driven-developmen Tue, 21 Apr 2026 23:00:00 +0300 Оригинальная публикация Мы, кажется, пробили новое дно. И что особенно удивительно, Карл! – аккуратно, без паники, с хорошей формулировкой и абзацами. Я сначала не понял, что стало происходить. Было ощущение странного дежавю: читаю change request или баг-репорт, киваю, вроде всё логично... но что-то не так, как будто где это уже читал. Слова правильные. Причинно-следственные связи на месте. Термины употреблены верно. Пытаюсь понять в чём проблема – ноль. Как будто читаешь инструкцию к микроволновке, а не описание реальной проблемы. Пытаюсь прочитать ещё раз и ещё раз - с трудом продираюсь через текст с каким-то смутным понимаем того, что написано. И тут до меня доходит - как обухом по голове. ]]> https://software-testing.ru/library/testing/general-testing/4512--change-request Sun, 19 Apr 2026 23:00:00 +0300 Автор: Эди Стоукс (Ady Stokes) Оригинал статьи Перевод: Ольга Алифанова Почему я написал эту статью Все мы иногда застреваем. Временами нам не удаётся найти путь вперёд или определить следующий шаг, который нужно сделать. С этим можно столкнуться, когда вы решаете задачу, создаёте тестовые артефакты или думаете, как что-то сформулировать или объяснить. Быть «работником умственного труда» непросто. Требуются усилия, дисциплина и практика, чтобы думать за деньги. Но именно на это подписывались тестировщики, и именно это нам и предстоит делать. Давайте поговорим о «затыках» на работе. Что это такое на самом деле, почему это происходит и что мы можем сделать, чтобы продвинуться дальше? ]]> https://software-testing.ru/library/around-testing/processes/4459-how-to-get-unstuck-a-guide-for-testers-or-anyone-else-who-feels-stumped Tue, 14 Apr 2026 23:00:00 +0300 Автор: Никита Филонов, автор курса «Автоматизация тестирования UI + API с Python» Оригинальная публикация Представьте утро. Вы открываете ноутбук, заходите в Allure — и видите красное море. Падает половина автотестов, часть — «временно», часть — «иногда». Почти каждый день начинается с одних и тех же починок, дебага и «вроде теперь стабильно». Знакомо? Скорее всего да, иначе вы бы не открыли эту статью. Сегодня хочу спокойно, без паники и взаимных обвинений, взглянуть на эту ситуацию со стороны. Почему тесты ведут себя так непредсказуемо? Откуда берётся эта нестабильность, и почему она кажется вечной? На самом деле это не случайность. Это закономерный итог накопленных технических решений, компромиссов и, порой, отсутствия инженерной стратегии. Каждый упавший тест — это не просто «флак» или «ошибка окружения». Это пропущенная проверка, потерянное доверие и часы бесполезных фиксов. Если таких тестов сотни, то со временем автотесты перестают быть инструментом качества — и превращаются в источник шума. Но из этого есть выход. Разберём, как подойти к автоматизации осознанно, чтобы тесты действительно помогали, а не мешали. Никакой философии, только инженерные практики и работающие приёмы. ]]> https://software-testing.ru/library/testing/testing-automation/4513--best-practices-for-test-automation Sun, 12 Apr 2026 23:00:00 +0300   27-28 марта в Москве прошла 3-я конференция для технических писателей — TechWriter Days 3. Сайт конференции — https://techwriterdays.ru/. Программа — https://techwriterdays.ru/ru/program/137253 «Я там был, мед, пиво пил» © И хочу поделиться с вами. Конференция отпочковалась от конференции аналитиков, так как тех писы уже — дело стандартное, есть отдельные должности под них. А я сама в свое время и аналитиком на проектах была, да и с документацией работала постоянно, потому что я — бюрократ ))) Так что очень интересно было посетить эту конференцию. Организация тут, как всегда у Владислава с Татьяной Орликовых, на высоте. Еда, чай, место для отдыха, куча всяких активностей, да и просто интересные доклады! Расскажу про те, где я была и где хотела бы. Мой список "посмотреть потом" Тихая эпидемия в IT, или Почему выгорают технические писатели — плохо себя чуствовала, не осталась на последние доклады, ушла домой. Но исходно ставила галочку сходить на доклад. Полистала слайды — интересно и жизненно, особенно про команды, где твою роль не понимают. Хотя это история про выгорание, а хотелось бы "что делать в такой команде", но тоже интересно) Использование стилей MS Word без страха — тут обещают реальные кейсы из жизни, я такое люблю) Внутреннее продвижение базы знаний: от справочника до культуры работы с информацией — внутреннее продвижение тоже очень актуальная тема! Документация как продукт: от текстов к стратегии и управлению опытом — документация как отдельный продукт, в том числе улучшаюший онбординг. Это прям откликает мне, я сама делала онбординг)) Отчеты и метрики в документации: как считать влияние на бизнес — всегда интересно, кому какие метрики зашли Какие доклады я слушала Кому доверить ревью API — техпису или искусственному интеллекту. Камила Мазаева Ссылка на доклад Камила работает в Альфабанке, где много всяких разных проектов. Путь документации там такой: Аналитик → техпис → разработка Технический писатель нужен, потому что документацию пишут разные люди, в разных стилях. А нужен единый, за этим следит техпис. Но техписы тонут в работе — когда приходят документы с опечатками, разным стилем и тд. Поэтому решили нудную работу делегировать ИИ. Посмотрели, что да как, и решили сделать так, чтобы ИИ не вносил правки в текст, а присылал отчет по найденным проблемам: уровень критичности где проблема? как написать лучше И человек уже принимает или отклоняет такие правки. В итоге аналитик открывает чат с ботом, куда уже внесен нужный промт → дал документацию, получил фидбек. Красота! Ну и выводы — ИИ хорошо правит простые опечатки и быстро обрабатывает документы. Но не очень хорош с контекстом, терминологией и работе с неоднозначностью. И, конечно, нужно помнить, что сердце ИИ — хороший промт! Через тернии к звездам: как мы перевезли всю документацию Яндекса на Diplodoc. Эльвира Гильманова и Михаил Кошкин Ссылка на доклад Довольно интересный рассказ о переезде документации с одной платформы на другую. Переезд занял 5 лет! ???? Раньше жили на DITA, которая выглядела как документация из 2000-х годов, перешли на YFM. Всякое бывало, что-то предусмотрели, а что-то — нет. Были и косяки — нужно было объединить документацию. Посмотрели, она написана на разных платформах, провели диагностику, какая лучше, выбрали... DITA. И через месяц узнали, что все пеередут в YFM. Была ситуация со старым багом, который вроде как не очень хорошо ловится, вот и не правили. А потом выяснилось, что популярная документация не могла из-за него мигрироваться. Пытались сделать костыли — заняло квартал с нулевым результатом. А переписать с нуля заняло месяц. Так что хоть "переписать с нуля" и боятся, иногда это самый лучший вариант. И даже самый быстрый, хотя кажется наоборот)) Собрать документацию в один клик: опыт применения языковых моделей и шаблонизаторов. Никита Осокин Ссылка на доклад Ребята работают по ГОСТ — а это часто не про «написать документацию», а про коммуникации, про «правильную» структуру документа. И вот мучались, мучались, и решили сделать свое решение. Да, оно в маркдауне и после ворда писать бывает сложновато, но тут у них ИИ, наученный помогать и подсказывать, как что-то сделать. В итоге раньше переименовали какое-то название — это надо открыть ворд, ctrl + f, поиск, замена... А если разные падежи, оно ещё и не работает! Что сделали? Единый банк переменных. Ну и не только его, конечно)) В итоге что получили? Приходит заказчик: — Ой, а давайте всё же систему именовать не АС "Документирование", а АС "Техпис" Раньше такие просьбы за неделю до сдачи проекта вызывали желание выйти в окно, а теперь "да легко" Масштаб, сложность, автоматизация: как агенты изменили процесс документирования в Yandex Cloud. Александр Яковлев Ссылка на доклад Александр рассказал про их опыт внедрения ИИ. Какие инструменты использовали: Методом проб и ошибок пришли к таким выводам: агент не работает с гитом, не пушит сам — иначе он такого напушит, что только всё испортит тестирование документации тоже на людях — ИИ бы справился, но это хорошее время для ревью. Что входит в настройку агента: системный промт режим фоновые знания Где в итоге агент может реально приносить пользу? Создание структурированной информации — пошаговые инструкции, обзорные статьи Обновление существующей документации на основе тикетов, скринов, истории изменений Подготовка Release Notes Анализ актуальности документации из истории изменений и релизов инструментов. Был кейс — уволился человек, который отвечал за несколько проектов. Попросили ИИ проанализировать документацию на основании как раз таки истории изменений. Да, это заняло 1.5 млн токенов, но был вау-результат и найдено много проблем в доке. Changelog на лету: автоматическая генерация с помощью GitLab. Татьяна Кириллова Ссылка на доклад В чем разница между RN и CL? Release Notes — документация для пользователей Changelog — для разработчиков, что вообще и где менялось. Так вот. Схема до автоматизации, техпис собирает change log сам: Неприкольно! И трудозатратно. Поэтому описали критерии "что хотим от автоматизации", погуглили инструменты и сравнили по своим критериям: Простой подход, но зато выбор становится очевиден! НО! Возникла проблема — робот не человек, ему нужен шаблон. И надо вводить соглашение о коммитах, иначе все пишут как душе угодно, и собранный ченджлог будет просто нечитаем. А это надо убедить разработчиков писать "как положено" ))) В итоге: пока проводят ревизию сообщений планируют прикрутить автоматическое соглашение Ну и закрепили структуру сообщения: Номер задачи — обязательно Тип — fix, new... Описание  Тело (необязательное) Пока обкатывают, впереди ещё долгий путь) Матрица зрелости процессов работы с текстом в ИТ. Анна Терновая Ссылка на доклад Зачем вообще нужна матрица зрелости? Есть несколько разных причин: Анна рассказала про то: Какую литературу использовали при изучении темы Какую матрицу выбрали себе Главная фишка — делить каждую колонку на "наших и ваших", команду разработки и команду документирования. Потому что уровни зрелости могут быть разные и повлиять на чужую команду вы можете не всегда. Ну а дальше смотрим на примерах, как могут выглядеть эти матрицы и что с этим делать. Когда уже есть внедренное решение, всегда можно показать "незрелой" команде пользу — смотрите, вот мы выросли в матрице и какие это профиты дало!  Так что нужно заручиться поддержкой одной из команд, а потом история успеха будет продвигать вас сама =) Подготовка к документированию: читаем ТЗ, собираем информацию. Софья Новикова Ссылка на доклад Софья рассказывала, как собирать информацию из разных источников: А ещё, если документация разбита на разделы, техписы вычитывают каждый раздел — всё ли понятно? А если нет, термины можно сначала погуглить или спросить у ИИ, чтобы не отвлекать коллег лишний раз вопросами! В общем, если информации у вас мало, учитесь её собирать из разных мест, в том числе у коллег. База? База, но о ней надо помнить. Документация как зеркало продукта: роль технических писателей в улучшении пользовательского опыта. Эльвира Дёгтева Ссылка на доклад Эльвира рассказала кейсы из жизни, когда пытаешься сделать мелкую задачу, которая выливается в большой рефакторинг)) Кейсы из жизни — это всегда интересно. И тут как раз кейсы из серии "пройти мимо, сделав вид, что всё ок, не моя же зона ответственности", или начать копать... И копать... И копать))) Интересные истории! Трансфер знаний от уходящих сотрудников. Denis Mazin Ссылка на доклад Тут интересная история — каким-то образом ребята выявили, что 18% сотрудников в зоне риска ухода. И надо бы передать их знания, пока они не пропали... Накидали такую матрицу: Запланировали передачу знаний и понеслось... Сначала сотрудникам некогда этим заниматься. Благо начальство поддержало и поставило высокий приоритет задаче. Но всё равно работу тоже надо работать. В итоге за год сделали многое, и пришли к неожиданному выводу, что передача знаний — это не разовая акция, а постоянная. Уйти может любой, заболеть, а знания брать где? Так что ребята теперь работают над встраиванием этого процесса в основной. Матрица итеративного редактирования. Анна Штольц  Ссылка на доклад Редакторы постоянно сталкиваются со сжатыми сроками. Дают текст на 250 стр и говорят, что есть полчаса. Что делать? В идеале нулевым этапом надо текст просто прочитать — тогда поймешь, хватит времени или надо сразу просить сроки увеличить. Ну а потом идет итеративное вычитывание, потому что так проще, если держать в уме сразу всё, что-то обязательно пропустишь. Да и не всегда нужна полная и подробная вычитка. Выделили такие этапы: Корректура — почти на автомате, всякие опечатки (странно, что не передали это ИИ) Литературная правка Выравнивание стиля — много жаргона? Это плохо. Фактчекинг — названия, имена, даты, логика повествования Отделка Интересно было посмотреть со стороны, как преображается текст, так как Анна показывала все на конкретном примере, а в итоге «до — после».  Уровни качества документирования. Оксана Гаврюшенко Ссылка на доклад Оксана работает в компании, которая делает документацию на заказ. Поэтому каждый раз нужно отвечать заказчику на вопрос «почему так дорого».  Так что ребята сделали разную градацию — что нужно? Одноразовая работа? Чтобы документация потом жила? Должна ли соответствовать ГОСТ? И прочее. Всё это влияет на сроки и стоимость. И главное, что надо научиться понимать — разницу между желаемым и достаточным. Ну а в докладе Оксана приводит примеры своих матриц влияния результата на стоимость. Вполне любопытно посмотреть на чужой подход) Декомпозиция страха: практики взаимопонимания для руководителей и команд техписателей. Мария Макеева Ссылка на доклад Каюсь, на этот доклад я залетела случайно. Исходно собиралась в секцию B, но очень уж название зацепило. Прочитав название (не описание), я подумала, что там будет та же проблема, что звучала на конференции чуть ранее — когда другие отделы не понимают ценность техписов и надо ходить, доказывать её. Мне стало интересно послушать такой доклад, вот я сюда и завернула. А это доклад про то, как вырасти в руководителя был =))) Но тоже неплохой, как стать хорошим руководителем, а не просто начальником с кнутом! Орг вопросы Место проведения — удобная гостиница, которая находится прямо около метро (что большой плюс). Места всем хватает, еды на обеде много всякой разной и вкусной. Помимо обеда — всякие ништяки в кофе зоне. Причем с утра и после обеда это что-то мясное / рыбное. Бутербродики, например. Чтобы можно было перекусить, если пропустил завтрак или приехал на конференцию прям с поезда. Очень здорово сделано ???? Плюс комната для отдыха с аэрохоккеем, VR-очками и даже игровым автоматом)))  А ещё куча разных стендов, где тоже и розыгрыши есть, и пообщаться с докладчиками можно. А ещё туда издательство Питер приезжает и книги продает, дешевле, чем в магазине. Я там прибарахлилась немношко)) Жаль, что серию Head First O`Really они больше не возят, я бы из неё пару книг тоже взяла... Но в любом случае, заняться вам всегда будет чем. А ещё на конференции есть много людей, готовых вам помочь и ответить на все вопросы, так что по орг части никаких вопросов нет) Резюме Конференция — это всегда место вдохновления. И место встреч! Когда ещё вы сможете встретиться с коллегами, живущими в других городах?))) Я рада, что конференция для технических писателей — это теперь отдельная конференция, для всех, кто любит документацию, кто тем или иным образом участвует в её создании. Документация — это очень важно! И здорово, что теперь есть, где поделиться своим опытом!  Буду теперь ждать TechWriter Days 4 =) ]]> http://okiseleva.blogspot.com/2026/04/techwriter-days-3.html Tue, 07 Apr 2026 15:44:00 +0300 Книжка - говно, хотя в ней и есть неплохие моменты. Написана уставшим еба-консультантом, который уже много раз помогал стратегировать в разных компаниях в те времена когда стратегировать было модно и нанимать консультантов тоже. Толика полезной информации в книге есть, но не что-то удивительное до чего не дойти собственной головой на практике. Читать не стоит. Оценка 1/10. ]]> http://test-failed.blogspot.com/2026/04/blog-post.html Tue, 07 Apr 2026 11:42:00 +0300 Почему команды всё чаще доверяют тестирование разработчикам и где в этом подходе скрываются риски для продукта. В QA есть одна вечная тема, которая так или иначе периодически всплывает на каждом втором проекте. Кто должен тестировать продукт? Когда-то в начале развития отрасли все казалось проще простого – разработчик пишет код, а QA проверяет. Баги находятся, фиксятся, проект выходит в люди. Классическая схема и почти уютная. Такое аккуратное «перекидывание кода через забор»: девелопер дописал фичу, кинул в тестирование, пошёл писать следующую. Но индустрия давно ускорилась и релизы стали чаще, а CI крутится круглосуточно. И в какой-то момент кто-то вбросил: а почему разработчик не может проверить свой код сам? Упс. И понеслось… На словах вброс-вопрос звучит вполне разумно. Более того, иногда ткая схема проверки реально работает. Я работала на проектах, где разрабы активно тестировали собственные фичи, и это давало отличный результат. При этом никто не отменял, что у медали вообще-то две стороны. И вот вторая сторона вам не понравится, потому что подход «разраб сам тестирует» не всегда правильный. Если говорить более точно, то он и не «неправильный», он – нуждающийся в балансе. Проскочить в подобном случае точку невозврата ну очень легко. Когда разработчик тестирует свой код ...случается довольно прозаичная, но крутая штука. Давайте начнём с хорошего и посмотрим на плюсы модели работы. Они же есть и иногда очень серьёзные. Моментальный фидбек. Это самый очевидный бонус. Разработчик только-только написал кусок логики. Контекст еще в голове и поэтому когда он запускает тесты или быстро прогоняет сценарии, то ловит баг без напряга и сразу. Никаких задержек, очередей задач QA или сборки на тестовом стенде. Прямо здесь и сейчас. Любая команда, которая хотя бы немного работала с CI/CD, знает, чем раньше поймали дефект, тем дешевле его исправить. Когда я только пришла в тестирование, мне повезло работать с разработчиками, которые исправно писали юнит-тесты и проверяли основные сценарии. Тогда мне казалось, что они нас «объедают», потому что до команды QA (то есть до нас) баги доходили гораздо реже. И если доходили, то обычно уже как раз те, над которыми приходилось поломать голову, интересные, а не банальные null (NPE). Код становится чище. Это как забавный побочный эффект. Хотя я точно знаю нескольких специалистов, которые скажут, что нет такого и вообще как мы могли такое написать И тем не менее…когда разработчик знает, что ему самому писать тесты, внезапно оказывается, что писать тестируемый код гораздо удобнее. Появляются нормальные интерфейсы, декомпозиция логики, понятные зависимости, меньше монолитных функций на сотни строк. Если код невозможно протестировать, значит с архитектурой что-то пошло не так, и разработчик начинает это видеть первым. В хорошем смысле тесты дисциплинируют. Быстрее движутся небольшие проекты. Признаться, на маленьких продуктах или стартапах это вообще может быть спасением. Бывает (к сожалению или счастью) команда из трёх разработчиков и на них один QA (не дай богоскрипт!) на полставки. Релизы каждую неделю. В такой ситуации базовое тестирование разработчиками дает возможность не тормозить поток задач. Девелоперы проверяют свои фичи, QA концентрируется на более сложных сценариях. Работает оно довольно неплохо. До определённого момента, конечно. Но это уже слегка другой разговор. А потом начинаются слепые зоны Я очень люблю разработчиков. Серьезно. Без них у нас не было бы работы. Но есть одна фундаментальная проблема. Суть ее в том, что мы (разработчик и тестировщик) смотрим на систему совершенно по-разному. И дело тут не в компетенции, а в мышлении. Туннельное зрение Разработчик проверяет, работает ли его логика. QA проверяет, как её можно сломать. Это две разные задачи. Когда девелопер тестирует свой код, он почти всегда идёт по happy path. По самому правильному сценарию использования. Ну какой пользователь так делает? Тестировщик играет роль пользователя и начинает задавать неприятные вопросы… а что если пользователь нажмёт кнопку пять раз подряд? а если запрос придёт дважды? а если поле будет пустым? а если данные сломанные? Разработчик редко думает в этой плоскости, потому что его мозг занят другой задачей. Ни в коем случае не потому что не может. Просто он строит систему, а тестировщик пытается её разрушить. Наши роли именно поэтому разделились исторически. Контекстные переключения Есть ещё одна проблема, которую редко обсуждают, это переключение контекста. Создатель кода пишет код. Это состояние созидания. Нужно держать в голове архитектуру, зависимости, бизнес-логику. А наша работа, то есть тестирование, требует противоположного мышления. Нужно искать уязвимости, странные сценарии, крайние случаи, ломать в общем… Можете себе представить одного человека, который постоянно прыгает между этими режимами? Там, где разработчики обязаны написать фичу, покрыть её тестами, прогнать тестирование, пройти регрессию, в итоге упадет скорость разработки. Ну и глубина тестирования останется под вопросом. Иллюзия безопасности Вот уж точно самый опасный эффект. Вдруг кому-то из руководства приходит гениальная мысль (фея Динь-Динь наколдовала, видимо): разработчики пишут тесты, значит отдельный QA не нужен. Доводят эту мысль до подчиненных, те красиво оформляют на бумаге план работ и назначают исполнителей. Ну а что? Все красиво. Есть юнит-тесты, есть CI, билды зелёные. А дальше продукт выходит в прод и оказывается (ну надо же!), что никто не проверял пользовательские сценарии, не проводил исследовательское тестирование, не смотрел на систему глазами реального пользователя. Юнит-тесты проверили анкерные гайки на фюзеляже. Но никто не проверил, летит ли самолёт. Когда автоматизация начинает тормозить разработку Отдельная история, которую я наблюдала на нескольких проектах, где руководство слишком близко к сердцу восприняло популярную мантру «автоматизируйте всё, что автоматизируется». Красоту звучания оставлю оценить любителям, но сразу скажу, что в реальности автоматизация иногда все-таки начинает работать против команды. Только сначала это кому-то кажется идеальной стратегией: юнит-тесты, интеграционные проверки, UI-тесты, длинные пайплайны CI. А потом тестов становится столько, что они начинают мешать разработке. CI собирается по полчаса, часть тестов падает без причины. Разработчики тратят время не на код (они его любят больше, признаем честно), а на перезапуск пайплайнов и поиск, какой из кейсов снова «флакнул» (а это они не очень любят). И вот хваленая автоматизация "почему-то" перестаёт быть ускорителем процесса и превращается в ещё один источник технического долга. Это отдельная большая тема, достойная целой статьи. Поэтому мы обязательно еще разберем, почему тестовая автоматизация иногда начинает тормозить разработку и как команды в итоге чинят свои CI-пайплайны. Ну и конечно, соберем важные сигналы, которые помогут вам понять, что процесс пошёл не туда. Где же проходит граница За годы работы на разных проектах я пришла к довольно простому выводу. Лучше всего работает разделение ответственности. Это сложно, но можно. Не война ролей. А именно баланс. Зона разработчика. Он отлично справляется с юнит-тестами, проверкой бизнес-логики, базовыми интеграциями, поддержкой зелёного билда в CI. Это его территория, его владения. И когда команда это все делает, качество системы реально растёт. Зона QA. Есть вещи, которые почти всегда требуют отдельного взгляда. Тестировщик занимается тем, что разработчик просто не видит: сложные пользовательские сценарии, негативные кейсы, исследовательское тестирование, UX-проблемы, интеграции между системами, нестандартные сценарии поведения. QA смотрит на продукт без привязки к тому, как он был реализован. И в этом огромная ценность. Что проверяется Разработчик QA Бизнес-логика Да, на этапе написания кода Да, на этапе функционального тестирования (после разработчика) и при регрессионном тестировании. Юнит-тесты Да Не напрямую Интеграции между сервисами Частично Да Негативные сценарии Редко Да Пользовательские сценарии Частично Да UX и поведение интерфейса Нет Да Исследовательское тестирование Нет Да В итоге Разработчик, который вообще не тестирует свой код, сегодня выглядит странно. Но разработчик, который полностью заменяет QA, почти всегда приводит проект к проблемам. Лучший результат можно получить, если обе роли работают вместе. Разработчик следит, чтобы его участок системы был надёжным, а QA проверяет, как ведёт себя продукт целиком. И иногда именно на этой границе происходит самый настоящий прорыв — и для специалистов, и для проекта, и для бизнеса. Когда код становится чище, баги ловятся раньше, а продукт выходит в прод без сюрпризов. Ну или почти без них. В IT идеала все равно не бывает, но стремиться к нему нужно, согласны? ]]> https://quality-lab.ru/blog/razrabotchiki-testiruyut-svoy-kod-plyusy-minusy/ Thu, 02 Apr 2026 13:10:38 +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 Что это за техника Вы собираетесь с друзьями в группу и ставите себе цели на 12 недель (3 месяца). Это могут быть как рабочие, так и личные задачи. Такие, которые вы вроде как хотите сделать, но вечно откладываете, так как «некогда, потом, щас, вот только мелочевку разгребу и тот пожарчик потушу». Настало время заняться тем, чем действительно хочется!  Отталкиваясь от глобальных целей, составляете план на неделю. И раз в неделю встречаетесь с группой и обсуждаете, сколько успели, сколько нет. Какой план на следующую неделю. Я, правда, уже давно не встречаюсь, а просто веду файлик "что сделано", откуда потом и просматриваю всё, что успела за цикл. Результаты кратко Основной план: ???? книга по чату — закончить  ???? книга по чату — вычитать ???? книга по тайм-менеджменту — написать 1 главу ????переписать автоматизацию в постмане полностью ???? 1 статья на Хабр С книгой новой чуток продолбалась, а вот курс отложила не по своей вине. Там огромная боль, но об этом чуть ниже...  На самом деле, с учетом двух госпитализаций плановых очень неплохой результат, там же пока врачей обойти, справки собрать... А ещё почти месяц болели по кругу... В общем, «время есть? Делай!», иначе потом придет какой-нибудь песец ???????? Кратко что сделала: Книга 4, SQL:  прошли верстку! книга уже вышла в продажу! Книга 5, ChatGPT: закончила книгу!  вычитала её, от души наредактировав принимаю картинки, пока ещё не все готовы Курс по автоматизации в Postman: Записала ещё пару уроков, обработала Поставила на паузу, потому что в Postman обновилось всё, и сниппеты, и документация ＼(〇_ｏ)／ Статьи на Хабр — 1 статья  Пополнила свой youtube-канал — 1 видео  Инструменты 12 недель — продолжаю вести файлик DONE, это все еще очень круто Новый год!  Новогодняя фотосессия ))) Две госпитализации у младшей дочери (плановые, гемангиома) Записалась в зал, начала заниматься ???? Результаты подробнее Книга 4: SQL В прошлом цикле я книгу прошла редактуру, но верстка только началась. В декабре мы закончили верстку, встали в очередь в типографию и книга уже даже успела выйти в продажу! И всё за один цикл! ＼(〇_ｏ)／ Кайф =))) Книга 5: ChatGPT В новогоднем посте я писала, что после провала с SQL (когда я так накосячила внутри книги, что от меня редактор отказался) «я буду умнее, отдам художницам картинки и буду вычитывать книгу, а не просто ждать!». Так вот. В январские праздники я закончила книгу, ю-ху! И маякнула художницам, что жду только их... Даже немного дежавю повеяло, с SQL все было точно также, просто год назад)) Обещание «быть умнее» я сдержала! Картинки жду, сама стала перечитывать книгу. Оказалось, это прям реально хороший план! Хоть книгу про ИИ я написала меньше, чем за год, вернуться к старому тексту это как в программировании: — Кто эту фигню написал?! Ой, это был я... Почти 2 месяца вычитывала. Ну, точнее как. Читаешь — не нравится. Думаешь, как переделать, а это время... Плюс в исходном варианте вообще не было главы про баг-трекинг, а я смотрела-смотрела на содержание... И решила добавить! А это глава с нуля...  В общем, что-то местами поменяла, что-то переписала, что-то удалила, что-то пополнила... Работы получилось много! Но! Я всё сделала за один цикл!! Есть и грустная новость — книга всё ещё не сдана. И тут дежавю уже не работает... Год назад я ждала до марта, но в марте мы всё сдали. А сейчас почти апрель, обе ещё работают... Я как раз сегодня потыкалась в нано банано и отправила редактору результат с вопросом, подойдет ли для верстки? А то ведь на картинки художниц чуть ли не инструкция была — цвет шрифта, разные слои текста и картинки, обязательно оригинал фотошоп файла... С другой стороны, вставляли же мы скриншоты, и нормально. В общем, обсудили с издательством, мне дали добро на использование картинок с ИИ. Так что следующая книга будет уже с моим авторством изображений =))) Ну, процентов на 70-90, я думаю, что художницам тоже что-то оставлю... Единственная беда — сама по себе нано банана стоит как крыло самолета (около 25к за год), вроде как дешевле взять чат с её функцией, но какой? Пока изучаю тему... Если есть что посоветовать, я вся внимание =)  Ну а статус книги — закончила, уже всё вычитала и причесала, жду художниц! В следующем цикле то точно дождусь (или уже в этой книге заменю на ИИ ????) Книга 6: Тайм-менеджмент Итак, к февралю я уже подразгреблась с 5-ой книгой и стала свободна. А зачем время терять? Занялась следующим проектом. Очень уж хочется мне книгу про тайм-менеджмент написать, про свой опыт 12 недель))) Я пока прикинула такое содержание — 3 части книги: Вводная, что это такое и всякое общее (мотивация и тд) Техники, которые мне НЕ зашли (но могут зайти другим) Техники, которые мне зашли и уже 9 лет со мной! Примерные главы: Я прошлась по всем своим постам из цикла 12 недель и насобирала «мяса», раскидав текст по разным главам. Теперь осталось его переосмыслить, дополнить, и будет красота! Пока сижу на первой главе, как обычно, начало самое сложное. Потом уже можно будет раскачаться, сделать примерную структуру глав и пойдет как по маслу. Пока — раскачиваюсь! Но вообще план на год — написать 2 книги, и это помимо книги про ИИ, потому что её я дописала в январе. Посмотрим, смогу ли! Курсы Автоматизация в Postman У меня был план перезаписать курс по автоматизации в Postman.  Прошлый результат — 9 уроков готовы, 10-ый записан, в обработке. Текущий — 11 уроков готовы. Причем 11 уроков я доделала ещё в январе, 29 числа всё сделала. Радостная такая была, осталось всего 3 урока! А дальше можно и цену поднять, ведь курс обновлен! А потом... Потом постман обновился. Причем не как раньше, чуток. Не-е-е-е-т... Они: 1. Кардинально изменили внешний вид и структуру документации. А я ведь учу изучать документацию... Я ведь в уроках показываю "вот пошли в доку, читаем там...". И все эти уроки разом устарели... 10 лет! Документация менялась, но не кардинально... И вот сейчас ((( 2. Судя по примерам в новой документации, изменен стиль автотестов. То есть код надо писать чуть-чуть по-другому. Это мне тоже непонятно, ведь столько автотестов уже написано, зачем их "ломать"? Да, старые тесты пока работают, но надолго ли? А то чувствую, потом скажут "не работает тест? Обновляйте через постбота!", а он может такой ерунды нагородить... В общем, тесты тоже теперь неактуальны. При этом! В документации уже новые тесты, в самом постмане в сниппетах ещё старые. То есть пока (на начало февраля) ещё не синхронизировали документацию с инструментом. Плюс в марте вышли новые изменения в «что платно, что бесплатно», поэтому с февраля у меня обновление курса на паузе. Я жду, когда все перетурбации закончатся, чтобы... Дописать 3 урока и переписать всё, что снова устарело ((( Самое обидное — я взялась переписывать курс просто, чтобы было. Просто потому, что большая часть курса записана почти 5 лет назад и студенты на это указывают, даже если урок актуален. Потребности обновлять весь курс не было, ну разве что пару уроков. А теперь... Обновились бы они так год назад, ну или я бы дооткладывала перезапись, вот сейчас было бы идеальное время. А так... Я год потратила на работу, которая полетела в мусорку. Год обновляла курс, который снова устаревший, капец. Конечно, всё было не зря. Я ОЧЕНЬ много всего изменила в курсе. Где-то добавила доп. материалов, где-то обновила домашние задания... Так что не всё в мусор, но демотивация была сильнейшая.  Ну, чтож... Бывает... Остальные курсы По остальным курсам мелкие правки по замечаниям от студентов чуток правим описание ДЗ или теста. Есть планы на новый курс-два, но вроде занялась одним курсом, потом заболели дети, потом мы сами, потом ещё один нежданчик прилетел, и вот до сих пор пытаюсь вернуться к работе... Хабр Одна статья, всё по плану =))) Есть идеи на новые, но пока руки не дошли... 1 тест = 1 проверка. Чем хорош принцип атомарности в автотестах в Postman Блог В блог я стала выписывать примеры использования ИИ: ChatGPT, подсчитай количество страниц в книге и авторских листов И рассказывать о том, чего «в 21 веке уже не бывает» по версии моих студентов, ага: Новый функционал? Подождем до последнего. Как банки к АУСН подключались Эльба: ну вы там как-нибудь сами проверьте, где ошибка произошла Не очень много, надо бы исправиться, в первую очередь в статьях на Хабр. Я попробую сделать чуть больше! Ютуб / ВК Мой канал — https://www.youtube.com/c/okiseleva (Дубль в ВК). Тоже грустновато, всего 1 видео: 1 автотест = 1 проверка. Почему этот принцип хорош (Видео в ВК)  Вот тут я хочу хотя бы 2-3 видео выпускать, а то зашла внутрь канала и грустненько стало... Вот этот пункт мне точно надо прокачать! Всякое разное, не рабочее Семья, дети Катюше уже 9.5 мес, она научилась садиться, вставать, ползать на четвереньках и даже немного ходить! Сейчас у нас "вставать всегда, вставать везде, вот лозунг мой, и солнца!" Мы в январе и марте госпитализировались по гемангиоме, прижигали лазером. Пьем атенолол, чтобы ушел объем, следим... Но из-за госпитализаций никак не можем поставить Леше живую вакцину — надо ж сначала Катю привить. А Катя то болеет, то госпитализация скоро... В марте плюнули и поставили прививку за неделю до больницы, иначе мы так совсем от графика отстанем. Теперь Кате осталась 1 прививка и можно Леше живую давать, ура! А ещё госпитализация — это пройтись по врачам, собрать справки, сделать эхо, ЭКГ и тд... Отжирает времени много ((( А ещё дети болели... А болеем мы тяжело, двое малышей — это неделя без сна, минимум. Потом заболеем сами / бабушка, и снова не отдохнешь или поработаешь вечером, потом ещё по кругу может пойти... В общем, мы проболели почти весь декабрь и почти весь февраль. 2 месяца из 3, огонь! Так что я еще много всего успела)) Остальное Ходили в кино! 1. «Злая 2» — очень круто, я в целом догадывалась о концовке, это было логично, но очень понравилось, как они все завертели там)) Проверка планов, поставленных в прошлый раз Основные цели: ???? Книга по ChatGpt — закончить книгу → готово! ???? Книга по ChatGpt — вычитать её  → готово! ???? Книга по тайм-менеджменту — написать 1 главу → в процессе)) Зато насобирала мяса на 20 других глав! ???? Курсы — постман сделать ещё 3 лекции (не верю в полную перезапись с учетом новогодних праздников и начала садика = болезней) → 3 лекции сделала! ???? Статья на Хабр — ну хоть одну! → одна и вышла) Найс ту ду: ???? Youtube-канал — 2 шт — уменьшаем цель до реально достижимой)) → не сделала ((( Но результат достижимый! ???? Встретиться с друзьями  Планы на следующие 12 недель Основные цели: Книга по ChatGpt — сдать в редактуру Книга по тайм-менеджменту — написать 3 главы, по одной в месяц норм план! Курсы — сделать 1 тему нового курса Статья на Хабр — ну хоть одну!  Найс ту ду: Youtube-канал — 2 шт — уменьшаем цель до реально достижимой)) Книга по Python — прочитать 100 страниц Встретиться с друзьями  Курс по постману — сделать ещё 3 лекции (не верю в полную перезапись с учетом новогодних праздников и начала садика = болезней) Хотела перенести ютуб в основные цели, но все же оставлю в найс ту ду... Потому что слишком много целей — плохо. Да, я тут решила снова читать начать, и даже начала! А потом цикл болезней и нежданчиков, и уже 2 недели нет времени читать ((( Вот поставила в план, хочу достигнуть! Резюме Хороший вышел цикл! Вроде главные результаты укладываются в пару строк, перезаписывала курс да пилила книгу, но сколько работы в это вложено! А уж с учетом болезней... Так что всё было неплохо, надеюсь, будет ещё лучше дальше, ведь весной-летом дети болеют меньше, надеюсь поработать! ???? ]]> http://okiseleva.blogspot.com/2026/03/12-33.html Tue, 31 Mar 2026 12:41:00 +0300 В практике аутсорс-разработки мы часто видим одну и ту же драму. На этапе стейджинга все выглядит очень неплохо, в отчетах QA прописано, что система стабильна при 10k RPS, графики ровные, latency в пределах нормы, отчёт зелёный. Но стоит маркетингу запустить кампанию или крупному энтерпрайз-клиенту провести онбординг сотрудников, как сервис превращается в тыкву. А полночь (т.е. ожидаемая серьезная нагрузка) даже еще не наступила. Мы уже говорили о том, как все происходит и самое дурацкое в этой ситуации – ложное чувство безопасности. Если ваши нагрузочные тесты пройдены, а система всё равно легла на 30% от заявленной мощности, значит, вы тестировали сферического коня в вакууме (погуглите, хороший анекдот). Давайте посмотрим, обо что спотыкается SaaS и чего это он все-таки падает, раз отчеты так хороши. Стерильные сценарии vs потока сознания юзера Типичный нагрузочный скрипт (на JMeter или k6) как дисциплинированный Безупречный под рукой Дейнерис. Он делает паузы (think time), идет по «золотому пути» и закрывает сессию. Но это не Игра престолов, а вполне реальная жизнь, поэтому тут всё иначе: Эффект паники (Retry Storm). Если API замедлился до 3 секунд, пользователь уже нервничает и не ждет. Он нажимает «Обновить» или кликает на кнопку «Купить» пять раз подряд. Вместо одного тяжелого запроса база получает пять одинаковых. А через пару секунд ещё пять, потому что юзер решил, что кнопка не нажалась. В результате нагрузку создаёт не количество людей, а их нетерпеливость, паника. Вкладки-убийцы. Мы, как современные пользователи SaaS, держим иногда открытыми 10-15 вкладок сервиса. Каждая из них может слать фоновые запросы (polling, уведомления, обновление статусов). В итоге 1000 живых людей за ПК генерируют нагрузку как 15 000 виртуальных пользователей. Новый «черный лебедь», или нашествие AI-агентов В 2026 году главной угрозой стали не люди, а AI-агенты и RAG-системы ваших же клиентов. Одна моя знакомая любит фразу «насколько это плохо, что аж хорошо». Так вот в отношении ИИ-агентов вполне можно ее использовать наоборот. Они настолько хороши, что аж плохо. Не согласны? Если раньше нагрузка была человекочитаемой, то теперь клиент может подключить к вашему API своего умного помощника ИИ, который начнет выкачивать данные для обучения или индексации… Но! Бот не делает пауз. Вот вам проблема. Он обходит кэш, подставляя уникальные параметры в каждый запрос. И в результате ваш кэш фактически вымывается за секунды, и 90% трафика летит напрямую в БД. Без жесткого Rate Limiting на уровне API Gateway такие агенты выкашивают SaaS быстрее любого DDoS (о безопасности ваших проектов писали тут). Совет от ЛК. Проверьте свои User-Agent логи. Если там внезапно вырос трафик от python-requests или специфических AI-библиотек, это оно, нашествие агентов. Но будьте осторожны, так как продвинутые агенты умеют притворяться обычным Chrome, и тогда их приходится ловить уже по аномальной скорости и машинной последовательности запросов. Архитектурные «бутылочные горлышки» Даже если (не хочется никого задеть, но так бывает редко) код идеален, система упирается в физические и логические пределы. База данных все равно что проклятие Multi-tenancy В SaaS данные всех клиентов часто лежат в одной базе данных. Если один крупный клиент запустит свой тяжелый годовой отчет, что мы увидим? СУБД начнет читать миллионы строк, пересчитывать агрегаты, строить временные таблицы и тут умирают все остальные клиенты, даже те, кто просто зашел почитать профиль. Тяжелый запрос захватывает ресурсы или ставит эксклюзивные блокировки на таблицы, через которые пытаются пройти другие пользователи. Просто потому, что данные всех клиентов лежат в одной БД, начинается тормозуха. Такие проблемы, как мы писали в прошлый раз, решаются изоляцией ресурсов (Resource Quotas) на уровне БД или шардированием по клиентам. Точка насыщения и Scaling Lag Облачный автоскейлинг (AWS, Yandex Cloud) смахивает на попытку догнать уходящий поезд. Это не волшебная палочка, а инерционная система. Новым мощностям нужно время на прогрев, а вашим пользователям нужен результат здесь и сейчас. Scaling Lag. Новым подам в Kubernetes нужно max 2 минуты, чтобы подняться и «прогреться». Если всплеск нагрузки произошел за 20 секунд, подмога просто не успеет. Connection Pool. Допустим, вы добавили 10 новых серверов приложений, но забыли, что база данных принимает только 500 одновременных соединений. Новые серверы просто выбьют старые и система ляжет окончательно. Почему тесты не показывают деградацию? Большинство команд совершает три критические ошибки при анализе отчетов: Ложь среднего арифметического. Среднее время ответа почти ничего не говорит о реальном опыте пользователей. Если оно 200 мс, это звучит отлично. Но смотреть нужно на P991. Если он 15 секунд, значит каждый сотый пользователь просто сидит и смотрит на спиннер. Отсутствие Soak-тестирования, то есть тестирования выносливости. Короткий тест на 15 минут не покажет утечки памяти или фрагментацию индексов. Настоящие проблемы в SaaS выплывают на поверхность через 4-6 часов стабильно высокой нагрузки. Синтетические данные. Тестировать на базе в 1 ГБ, когда в проде 1 ТБ, бессмысленно. На больших объемах планировщик SQL-запросов будет вести себя иначе, а Join-ы, которые летали в тесте, превратятся в бесконечное чтение с диска. Как ЛК защищает бизнес-метрики клиентов Мы в аутсорс-разработке смотрим на нагрузку глазами бизнеса. Падение сервиса не выглядит чисто как какая-то 500-я ошибка (Internal Server Error). Бизнес остро чувствует ее, это потерянный LTV и сожженный рекламный бюджет. Стек musthave-практик для 2026 года: Chaos Engineering. Мы принудительно «убиваем» микросервисы в нагрузочном контуре, чтобы проверить, работает ли Circuit Breaker (предохранитель)2, который не даст всей системе упасть за одним звеном. Graceful Degradation. Проектируем систему так, чтобы при пиках она отключала неважную, но приятную глазу пользователя, мишуру (аватарки, ленту рекомендаций), при этом сохраняла критический путь (оплату и запись данных). Observability 2.0. Мониторим не CPU/RAM, а бизнес-транзакции и длину очередей. Мы считываем симптомы усталости системы за 5 минут до того, как она упадет в глубокий обморок. Это дает нам время на маневр, а вашему бизнесу непрерывность. Что в итоге? В конечном счете, пользователю все равно, сколько у вас микросервисов и какой стек. Ему нужно, чтобы кнопка сработала здесь и сейчас. Наша задача как раз сделать так, чтобы красивые отчеты о тестировании не превращались в тыкву при первом серьезном вызове. SaaS в 2026 году должен быть адаптивным: уметь масштабироваться под AI-ботов, изолировать «шумных соседей» и сохранять лицо даже в условиях частичного отказа.  SaaS падает не от нехватки мощностей, как мы уже сказали. Можно бесконечно масштабировать API, но упереться в лимиты облачного провайдера или блокировки БД. Нагрузочное тестирование для нас – это своего рода поиск того самого кирпичика, который вылетит первым и лучше найти его в тестовом контуре, чем объясняться с клиентами во время сбоя в прод.  Если вам претит отчет для галочки и нужен реальный стресс-тест системы в условиях работы пользователя 2026 года, мы на связи. ]]> https://quality-lab.ru/blog/blog-pochemu-saas-padaet-pri-roste-polzovateley/ Tue, 24 Mar 2026 11:45:53 +0300 Продолжаю рассказывать про «да такого не бывает» в наши дни. У ИП подошел срок платить страховые взносы. У меня вся бухгалтерия в Эльба.Контур, которая и выставила мне задачку. Зашла в эльбу, прокликала задачу до "выставить счет в банке", и тут она мне выдает ошибку — не настроена связь с банком о_О Она автоматизированная и была настроена. Перешла в личный кабинет, и правда, нет связи. Потом и на главной странице уже заметила, что сумма на счету отображается неправильная...  Восстановила соединение с банком и тут же написала в поддержку. Мой исходный вопрос был предельно простой, как быстро Эльба всё подсосет: - У меня была разорвана связь с банком, сейчас восстановила — Интеграция c Альфа-Банком настроена с 18.02.2025. Получается, задача "заплатить страховые взносы" неактуальна, если данные не получала система с 18 февраля? Как быстро она подсосет все, что нужно? Но во что это вылилось, у-у-у-у.... Давайте я сначала покажу нашу примерную переписку за эти 2 дня, от которой у меня до сих пор бомбит, а потом кратко подведу её итоги (если лень читать всё). Переписка с поддержкой Сначала в чате с поддержкой тебе отвечает бот. Он увидел ключевые слова про страховые взносы и накатал огромное сообщение на целый лист (чат с техподдержкой это такой узкий, выплывает справа снизу на экране, вот его лист): - Обязанность по уплате страховых взносов ИП за себя определена ФЗ... (бла-бла-бла, о том, почему я вообще должна платить взносы) - Это вообще не про мой вопрос На эту фразу бот уходит искать человека. Когда я восстанавливала связь, система предложила подписать согласие на передачу данных банком. Я подумала, что все дело в этом, согласие понадобилось, поэтому докинула вопрос: - Почему эльба не написала, что связь с банком разорвана? по сути это же вы просто согласие затребовали подписать, почему не было письма тогда? Ну и как теперь исправить некорректные данные в эльбе? раз она про часть данных не знала То есть жду ответ, что "подождите пару часов и все подсосется" или "сделайте то и то". Ок. Приходит человек: - Если ранее не были загружены операции ранее 18.02.2025 года, то необходимо перенастроить интеграцию с банком. Интеграция настраивается в течении суток. Либо можно скачать выписку банка в формате 1С с расширением *.txt, тогда операции загрузятся сразу. Чтобы загрузить выписку: ... Если платёж уже заведен в Эльбу вручную, то он не задвоится, если будут совпадать: 1. номер платёжного поручения; 2. сумма; 3. дата; 4. ИНН-КПП контрагента. В ином случае в сервисе будет создан дубль операции. Если? Что значит "если"?? - Откуда я знаю, были загружены операции ранее 18.02 или нет? У меня была настроена интеграция, сообщения об ошибке в ней я не получала, и как я должна понять, с каких пор ошибка и что она затронула? все платежи с начала года выверять? Сейчас на главной блок "деньги" вообще не верный - Если платёж уже заведен в Эльбу, то он не задвоится, если будут совпадать: 1. номер платёжного поручения; 2. сумма; 3. дата; 4. ИНН-КПП контрагента. В ином случае в сервисе будет создан дубль операции. Можете просто загрузить операции в раздел Деньги вручную. Если есть лишние операции, их потребуется удалить вручную. *** То есть мне снова сделали копипасту "когда дубля не будет". Только я тестировщиком работаю и прекрасно понимаю, что, раз шанс ошибки и возникновения дублей есть, я хочу его избежать. В конце концов, мне за дубли налоги платить придется, а не им. А ещё очень умилило вот это вот "просто загрузите деньги вручную". Каждую операцию, да. Вручную... В итоге я с ними ругалась, ругалась — почему мне надо загружать лишнее? Или самой искать, с какого момента был сбой? Это ведь их задача — локализовать ошибку. Но техподдержка лишь лапки подняла: - Доступ к учетной записи есть только у вас, консультанты технической поддержки не могут посмотреть информацию, которая отображается у вас в Эльбе. Вам надо посмотреть от какого числа у вас в разделе "Деньги" отражается информация по счету и сверить с данными из интернет-банка. В общем, сами сидите и выверяйте, класс! Самое смешное, что, когда я выверила — сидела и просматривала глазками 2 экрана, деньги в эльбе и в альфа-банке, то с текущей даты и назад до 28 января всё ок. Это я сегодня уже выверяла, а связь с банком восстановила вчера. То есть по сути ответ на мой исходный вопрос мог быть коротким: - Сбой произошел в январе из-за техработ в банке. Так как вы указали при восстановлении связи 18 февраля 2025 года, Эльба должна была все подтянуть. Проверьте на всякие случай поступления за последние пару дней и такого-то января, чтобы убедиться, что всё хорошо. И ВСЁ! Но нет, надо было закидывать меня копипастой, писать какую-то фигню не про мои вопросы, а ещё рассказывать, как я могу сама локализовывать баг вместо них. Сегодня уже ругалась на них, так мне консультанта сменили )))) Видимо, девушка не выдержала моих вопросов "почему эльба не написала мне про сбой", ну а что, они мне копипастят одно и то же, и я свои вопросы без ответа им в ответ копипастила. Пришел парень, который знал систему, наконец-то! Он и пояснил всё: - То что интеграция нарушена, Эльба пишет в разделе "Деньги" и при выполнении задачи по УСН, а так же в разделе "Реквизиты". На данный момент уведомление о разрыве интеграции не реализовано, зарегистрировал пожелание на доработу Эльбы. "Интеграция настроена с 18.02.2025", это значит что все данные с этой даты подтянутся в Эльбу. Эта дата указывается при настройке интеграции с банком, но только в случае если она не была настроена, или была разорвана по кнопке "Разорвать связь с банком". Если интеграция была нарушена, и восстановлена по кнопке "Авторизоваться в банке" то дата не изменится, и за период когда интеграция была нарушена операции подтянутся. (Я ведь спрашивала их, что значит эта дата. Я нажала "восстановить связь — ок", почти не глядя, так как уже делала это раньше. Как в винде, знаете, далее-далее-далее-ок. А там, оказывается, можно указать дату, с которой восстанавливать, я даже внимания не обратила на неё. И нет бы другому консультанту ещё выше по переписке на вопрос "что значит это сообщение" подсказать, что это та дата, которую я указала (я не указывала, она подтянулась с прошлого разрыва связи) при восстановлении. Пока я дождалась этого консультанта, я уже разорвала связь и снова восстановила, как меня попросила поддержка. И вот теперь я заметила эту дату. Почему только техподдержка не подсветила мне это "вот на этом экране вы выбрали дату (скрин), она и отображается в сообщении"?) В вашем случае, если не помните как именно восстанавливали интеграцию, и нет возможности отследить хватает/не хватает операций(например, их было очень много и проверить все затруднительно) то можно подгрузить выписку из банка в формате 1С за весь 2025 и 2026 год в Эльбу. Если операция есть в Эльбе, то как правило она не задублируется, так как выписка из банка и выписка по интеграции идентичны. *** В общем, всё Эльба сделала сама, можно было бы остановить переписку ещё на первом сообщении, при нормальном и грамотном ответе... Кратко Какие были проблемы в итоге: 1. Нет извещения о сбое в системе. Да, связь разрушилась по вине банка, а не Эльбы, и мне техподдержка так и писала "ну это же банк виноват".  Но мне, как пользователю, какая разница кто виноват? Вы видите ошибку в логах, связь разорвана. Можно прислать письмо «Связь с банком была разорвана, пожалуйста, зайдите в ЛК по ссылочке и нажмите "Восстановить" её». Всё. Да, я всё равно это узнаю во время выполнения задачи, но тогда больше шансов, что что-то не подтянется и придется подтягивать вручную. 2. Первая линия техподдержки слабая по данной проблеме. Нет адекватной инструкции на такой случай. Пример я писала выше: - Сбой произошел в январе из-за техработ в банке. Восстановите соединение, подождите сутки. Потом проверьте на всякие случай поступления за последние пару дней и такого-то января, чтобы убедиться, что всё хорошо. И всё. Проверить пару поступлений — это не сложно. А они предлагали проверить "на вкладке денег". За какой период — думай сам. Что проверять? Ну сам как-нибудь...  Ну и объяснить, что значит сообщение в их системе, поддержка не смогла — там отображается дата, которую я сначала не поняла. Если ты систему знаешь, пояснить этот момент — дело пары минут... Ну вот, как-то так) ]]> http://okiseleva.blogspot.com/2026/03/blog-post.html Thu, 12 Mar 2026 13:19:00 +0300   Ссылка на Хабр Принцип атомарности (объект или операцию нельзя разделить на части, не нарушив их целостность или смысл) применяется в как в разработке кода ПО, так и в разработке кода автотестов. И в автотестах Postman он особенно хорош! Давайте разберемся на примерах, почему лучше писать небольшие автотестики, «один тест, одна проверка», чем «много проверок в одном тесте». Готовим тесты Запрос будем отправлять в бесплатную систему Users. Метод doRegister:  URL: http://users.bugred.ru/tasks/rest/doregister Запрос: {     "name": "Демо 1",     "email": "test_demo_1@gmail.com",     "password": "1" } Если с первого раза запрос не упал, отправляем повторно, чтобы получить ошибку в ответе: {     "type": "error",     "message": " email test_demo_1@gmail.com уже есть в базе" } Объяснить с Напишем автотесты на эти 2 поля. Какие тут есть варианты? Мы можем писать маленькие тесты, одна проверка, один тест: // Сохраняем ответ в переменную var jsonData = pm.response.json(); pm.test("Проверяем тип", function () {     pm.expect(jsonData.type).to.eql("error"); }); pm.test("Проверяем message", function () {     pm.expect(jsonData.message).to.eql(" email test_demo_1@gmail.com уже есть в базе"); }); Объяснить с А можем объединить, то есть написать один тест, который проверяет и тип, и message сразу (добавим его в те же скрипты, поэтому переопределять jsonData уже не надо): pm.test("Проверяем тип и message сразу", function () {     pm.expect(jsonData.type).to.eql("error");     pm.expect(jsonData.message).to.eql(" email test_demo_1@gmail.com уже есть в базе"); }); Объяснить с Отправляем запрос — все 3 теста проходят успешно: Отлично! Пока выглядит так, что третий тест даже лучше, за один тест дает информацию, что в ответе всё хорошо. Но что будет при падении? Одна проверка упала Сломаем тесты 1 и 3, поменяв «error» на «error2». Автотесты теперь выглядят так: // Сохраняем ответ в переменную var jsonData = pm.response.json(); pm.test("Проверяем тип", function () {     pm.expect(jsonData.type).to.eql("error2"); }); pm.test("Проверяем message", function () {     pm.expect(jsonData.message).to.eql(" email test_demo_1@gmail.com уже есть в базе"); }); моих курсах для начинающих у студентов порой возникают сомнения в актуальности лекций. Ошибочно кажется, что в 21 то веке: цикл «Code and Fix» не существуется, у всех Agile или аналоги (ну да, ну да...); глупых багов типа перехода через новый год или смены часовых поясов, уже давно нет, их решения «вшиты» в библиотеки кода (ага, щаз) нет проблем «сделали в последние дни, из-за чего огребли проблемы»; нет проблем с документацией; ... Поэтому я рассказываю актуальные истории таких проблем, которых вроде как в 2026 году и быть то не должно... У меня их даже поднакопилось, но... Не записал сразу = забыл ))) Буду постепенно рассказывать тогда. Сегодня я расскажу про АУСН. Сначала короткий рассказ, что это такое, а потом про текущую ситуацию с ним (и проблемы...) Что такое УСН и АУСН Это налоговые ставки для ИП или малого бизнеса. Когда вы работаете в штате, за вас налоги платит работодатель. А если вы открываете юр. лицо, нужно будет платить самому. Зачем? Несколько причин открыть ИП (хотя сейчас есть альтернатива — самозанятый, раньше не было): Работать как ИП на компанию (или несколько разных) — некоторые компании берут только ИП, или наоборот, не берут тех, у кого есть ИП.  Работать на второй работе — на одной трудоустроены, остальное как ИП. Так, например, я с издательством сотрудничаю как ИП и на него получаю гонорар с проданных книг. Так проще и дешевле платить налоги, чем как физику. Получать официальную прибыль — например, за сдачу квартиры в аренду, чтобы не как физик декларации заполнять, а просто честно платить налог с ИП.  Ну и просто работать на себя, но если вы это планируете, то и так всё знаете ???? Открывая ИП (или ООО, или ещё что-то), вам надо выбрать налоговую ставку. По сути раньше были основные варианты: УСН — упрощенный налог, платишь 6% с дохода (не с прибыли, а поступивших денег, неважно сколько ты при этом потратил) «Серьезный» бухучет — там платишь с разницы «доходы - расходы», но бухучета больше, он сложнее + налоговая будет заставлять отчитываться обо всех расходах, чтобы ты туда лишнее не вписал. В общем, обычно берут упрощенку. В ней есть ограничение — 60 млн дохода в год, иначе надо платить НДС и всякое сложное. Потом появился АУСН — автоматизированный налог, где 8%, а не 6% платишь, но "зато" оно платится само, не надо делать отчетность, её считают банки. Но если ты уже платишь за бухгалтерию, то вроде как и нет смысла в этом АУСН... Раньше ) Изменения в 2026 году Поменяли систему. Чтобы не платить НДС и сидеть на упрощенке, максимальный доход по ставкам: УСН — 10 млн рублей в год (вместо 60!!). Но понижают "медленно", в этом году можно 20 млн получить, в следующем вроде 15, потом уже перейдут на 10. АУСН — 60 млн  То есть по сути, если доход больше 10-20 млн (эх, мне бы в эту категорию ????), надо переходить на АУСН. ВОТ ТЕПЕРЬ он стал выгодным! Проблемы перехода (а вот и баги!) Ну и, собственное, сейчас многие стали переходить на АУСН и, сюрприз-сюрприз, стали вылезать баги!  Я тут немного теоритик, так как сама в эту категорию дохода не попадаю. Но знакомый, который перешел, скинул любопытную статью, подтвердив, что встречал такие проблемы — https://www.forbes.ru/finansy/554530-biznes-stal-case-perehodit-na-ausn-s-kakimi-problemami-mozno-stolknut-sa: «С проблемами передачи данных при работе на АУСН сейчас сталкиваются многие предприниматели, и это не частные сбои, а системные», — говорит член совета московского регионального отделения «Деловая Россия» Андрей Глушкин. Ошибки в передаче данных от банков и операторов в налоговые органы наблюдается довольно часто, особенно в начале 2026 года, подтверждает член Ассоциации налоговых консультантов, руководитель налоговой практики адвокатского бюро «БВМП» Александр Андропов. В числе основных причин — неполная готовность банковских систем к интеграции с Федеральной налоговой службой (ФНС), в том числе потому, что многие кредитные организации подключились к реестру уполномоченных кредитных организаций для АУСН (то есть стали банками, где плательщики АУСН могут открывать счета) только в конце 2025-го. «Банки не успели полноценно протестировать обмен данными, что приводит к искажениям в передаваемой информации», — говорит Андропов.  Я сначала, пока читала статью, лишь кивала головой. Конечно, это логично, если раньше единицы работали, то и меньше проблем встречали. Чем больше пользователей, тем больше шанс, что они попадут "в ту самую ветку кода, где есть баг". Ну и раз сейчас массово юрики стали переходить на эту систему, стали всплывать проблемы. — Конечно, банки были не готовы! — думала я. Ведь это только сейчас внедряется, я вот про АУСН услышала год назад, что-то новенькое жеж (я не бухгалтер и поэтому за бухгалтерскими новостями не слежу) А вот что для меня стало откровением в этой статье, так это то, АУСН уже почти 4 года! Оказывается, он запустился летом 2022 года. 3.5 года назад! И при этом банки «не успели протестировать обмен данными». А всё почему? А потому, что банки и сами только недавно стали подключаться к этой системе! Это кажется странным, ведь все равно придется. Но оттянуть до последнего — это состояние души))) Начиная со студенчества, когда в последнюю неделю начинаешь сдавать домашки, и заканчивая... А заканчивая ли? В любом случае в банковских системах есть свои планы на ближайшие несколько релизов. Надо сделать функцию А, исправить функцию Б и вон ту финтюфлюшечку хочется. Так зачем брать в релиз задачи, которые пока не горят? Видимо, клиентов на АУСН было настолько мало, что проще было им отказать "нет, мы не умеем поддерживать такую систему", чем внедрять её. Хотя, конечно, за несколько лет можно было выделить время... Но реальность такова, что подключаться все стали в последний момент — а это всегда опасно (баги есть везде, поэтому нужно время на тестирование и отладку).  Ну и интеграция — это тоже всегда сложно, потому что обычно нет подродного ТЗ, делают как поняли, а оно работает не так, а надо переделывать... В общем, процесс небыстрый! Хоть и 21 век) PS — добавила пост в общую копилку багов. ]]> http://okiseleva.blogspot.com/2026/02/blog-post.html Tue, 24 Feb 2026 20:37:00 +0300 Касательно командной разработки с интенсивным применением LLM — ну да, растёт скорость внедрения изменений. За всем уследить не получается, и мы натыкаемся на нелепые баги, которые можно было бы обнаружить за секунды, ещё до релиза деплоя. Наверное, уследили бы, если бы изменение было планомерным, предсказуемым и затрагивало только одно секундное дело. А оно затрагивает много место сразу, в которые никто не заходил и ломаться было нечему… Если бы всё всегда ломалось предсказуемо, то уж мы бы… QA процессы — можно внедрить, конечно, но в разработке ПО гарантирование качества не гарантирует ни качества, ни отсутствия багов. Долго объяснять, но это так, ПО не делается, как клоны на фабрике, это каждый раз уникальный артефакт со множеством особенностей, из которых некоторые наследуемые, а некоторые неожиданно новые. тестирование стоит на фундаменте из требований, которые надо сперва наладить и запрягать перед каретой, а не после. Если мы деплоим 256 изменений за один раз по вторникам, то как именно трэкать эти самые требования? Где? Кем? Скорее всего, это ПО развивается не по требованиям, а по невнятным ожиданиям бизнеса. Нет требований — нет и гарантий соответствия им, потому что нечему соответствовать, тестирование живёт в режиме «сравнить наблюдаемое с ожидаемым». Нет ожиданий — не с чем сравнивать, остаётся только исследование в режиме «я не уверен, как оно должно работать…» А исследование ПО в QA этого ПО не конвертируется. Любопытно, что всё то, что мы сегодня переживаем, уже было — в начале девяностых, когда понадобилось ускорить поставку ПО, потому что бизнес же тестирует гипотезы и идёт вслепую, а не по продуманному и однозначному пути. И пришёл agile, и все ускорились, и в двухтысячных годах XX века я не видел в разработке живых тест-аналитиков и тест-дизайнеров, к тому времени их уже всех свезли на остров Литтл-Сент-Джеймс (в составе Американских Виргинских островов), где американский финансист Джеффри Эпштейн & Co регулярно путали их с девицами красными. И это случилось так быстро, что в двухтысячных уже всем казалось нормальным, что тестировщик сам придумывает тест-кейсы, сам их дизайнит и сам их выполняет. Ну, как дизайнит… он знает о том, что существует тест-дизайн, где надо какие-то таблицы придумывать, но на это всегда нет времени. Проще читать требования напрямую, на ходу придумывать проверки и сразу их выполнять. Придумывать тест-кейсы — где вы на это время найдёте? А сегодня нам уже и требования негде взять, потому что ПО генерируется быстрее, чем кто-то соображает, зачем его нужно генерировать и что именно оно должно делать. И как именно… И какой бизнес будет стоять за нагенерированным ПО. Те же сайты не нужны сами по себе, они нужны бизнесу как витрина, как сборщик заказов… А ещё в древности ПО поставляли на дисках, и обновлять его было крайне сложно, поэтому наши предки старались его как-то привести в готовое состояние ДО релиза. Но мы уже не они, мы перепрыгнули в парадигму «ПО работает на сервере, к которому мы постоянно имеем доступ, и если мы найдём ошибку — просто быстро её исправим», и это полностью true в отношении мелких ошибок. А если ошибка будет NOT мелкая, ну, откатим софт… наверное. Стоимость исправления ошибки упала, зачем вы требуете время на то, чтобы тестировать тщательно до релиза? Тестируйте после релиза, что вам мешает? Давайте сперва выпустим софт, чтобы продажи были, а потом вы будете его тестировать. Вот вам требования, не нойте. А сегодня и требований «уже не стало, а скоро совсем не будет» © нашсеньор Паниковский. Мне уже предлагают воспринимать под видом требований абстрактные тексты, которые были сгенерированы по сгенерированному коду. Текст получается осмысленным на расстоянии одного предложения, а вместе эти предложения не склеиваются. Всё, как мы любим — без воды, без резолюции, без нервотрёпки, без коагуляции десереализационного инкремента, без хтонических завихрений, без un pahar de tocănică gustoasă la a voastră masa măiastră. Хочешь ещё? Я понимаю коллегу, который тоже задолбан и был вынужден предложить хоть что-то под видом требований, он поднатужился и выдал — дякую, аж пiдскакую. А дальше со всей этой слезинкой ребёнка что делать? В норме я могу, читая требования распознавать ситуации, которые наше ПО должно обработать, распознавать ситуации, которые наше ПО не должно обрабатывать, распознавать ситуации, которые наше ПО не должно обработать, но которые могут произойти распознавать ситуации, про которые наши разработчики требований и ПО по какой-то причине не подумали распознавать ожидания, которые подразумеваются, но не были явно объявлены — не все связи и требования очевидны, не обо всех детальках можно додуматься заранее То есть, мой процесс состоит из нескольких фаз: осознание, обдумывание, согласование, выполнение. Всё это требует какого-то времени. Что можно машинизировать и ускорить? Осознание Тест-кейсы пишут так же, как пишут код — руками на клавиатуре. Начинаешь медленно, затем ускоряешься, и постоянно к чему-то приходится возвращаться. Можно их сгенерировать — вот вам и, кагбэ, ускорение. Но придётся разбираться в нагенерированном. То есть, произойдёт мощный спид ап на первой фазе, а затем… Обдумывание … всё равно мучительно медленный разбор — нужны часы. Ок, я могу сам заниматься тест-дизайном, это, в принципе, знакомая и интересная аналитическая работа, которая направлена не на написание тест-кейсов, а на выявление очевидных и неочевидных связей и требований, и уже из того, что останется, появляются тест-кейсы. Но это требует времени. А ещё тест-кейсы пишут или по требованиям, или по уже работающему приложению. Второй подход ублюдочен, но с него начинают все. Первый подход сложен, но он более разумен и эффективен. Anyway, и на то и на это нужны часы пропорционально количеству функциональностей ПО — чем их больше, тем больше времени нужно. Согласование Очень важный этап, который мы все дружно скипнем. Сколько раз уже скипали, неужели на этот раз что-то бомбанёт? Вроде не должно… Выполнение Вручную тестирование делается медленно — нужны часы. Можно какие-то проверки делать через тот же Playwright, но не все же, и их так или иначе надо будет записать в виде кода. LLM тут может нас спидануть, но местами с очевидно-предсказуемой потерей буквы «з», и придётся разбираться в каждом отдельно взятом кейсе. Нужны часы на подготовку тестов для автоматизации и, к сожалению, в будущем понадобится МНОГО часов на их постоянное переписывание, потому что автоматы будут устаревать и спотыкаться на ровном месте — просто потому, что так они устроены. И надо, чтобы этим занимались отдельные пацаны, и для успеха им нужны уже кем-то продуманные тест-кейсы, чтобы не переключаться между разными уровнями абстракции. Впрочем… А если после всего этого ВНЕЗАПНО выясняется, что требования уже где-то как-то непредсказуемо поменялись, то надо всю эту аналитическую работу выполнять заново. Это реалистично? В погоне «успеть вовремя» её будут выполнять частично, а значит, никаких гарантий не будет, ПО поедет в релиз от станции Тревожность до станции Бадабумц, потому что тестировщики опять пропустили какую-то досадную (местами лютую) мелочь. Может быть, пришло время как раньше, порезать в ролях и принудить тестировщиков выполнять работу, которую раньше делали отдельные юниты? Да, тест-дизайн стал хуже, но остался же? Можно, например, заставить тестировщика придумывать требования. Он же не сможет возразить?! И пусть это будут очень плохие требования, но они же будут, хоть какие-то?! Всё, как мы любим — без воды, в пустыне, под палящим солнцем… Ок. Мы превратим тестировщиков в бизнес-аналитиков «с сильным навыком тестирования». И пусть эти аналитики сами гоняют LLM и сами «генерируют соответствующие артефакты», которые только им самим и нужны. Пусть Джек идёт строить дом… Вот LLM, которая генерирует код проекта. Вот LLM, которая генерирует код проекта, на основе которого генерируются требования к проекту. Вот LLM, которая генерирует код проекта, на основе которого генерируются требования к проекту, на основе которых генерируются юнит-тесты для проверки проекта. Лей в прод. Тут будет большой бэмц, после которого программиста допрашивают через его же сфинктер, а как так получилось, что его красивые юнит-тесты работают, а ПО — с багами. Пропустим эти неприятные звуки и перейдем к следующему ходу. Вот LLM, которая генерирует код проекта, на основе которого генерируются требования к проекту, на основе которых генерируются и юнит-тесты для проверки проекта, и тест-кейсы для проверки проекта сразу в Playwright, чтобы не возиться с ручным тестированием. Лей в прод. Тут пропустим ещё один большой бэмц, после которого всех сразу допрашивают (и не только через сфинктер; что вы так сосредоточились на этом сфинктере, вы больные, что ли?!), а как так получилось, что и юнит-тесты работают, и Playwright работает, а ПО — с багами. Почему вам не хватило времени мозгов проверить руками хотя бы основные happy path? Почему этих happy path так много, товарищи? Давайте заново. Вот LLM, которая генерирует код проекта, на основе которого генерируются требования к проекту, на основе которых генерируются и юнит-тесты для проверки проекта, и тест-кейсы для проверки проекта сразу в Playwright, и тест-кейсы для ручного тестирования. Сжимай свой сосредоточенный сфинктер, раз уж ты ни на чем другом уже не можешь сосредоточиться, и лей в прод. А что лить-то? Мы сразу втыкаемся в то, что ручное тестирование проекта требует времени два раза — и для подготовки (когда анализируют требования и придумывают тест-кейсы), и для выполнения. И это всё никак не ускоряется. Быстро льётся, если без тестирования. А вы же хотели тестирования? Хм… И время идёт, пока мы читали эти ужоснах тест-кейсы для ручного тестировани, та клята LLM уже перегенерировала заново код проекта, на основе которого генерируются требования к проекту, на основе которых генерируются и юнит-тесты для проверки проекта, и тест-кейсы для проверки проекта сразу в Playwright, и новые тест-кейсы для ручного тестирования… и по цепочке всё обновила. Кхм, как говорится, блеать… Если генерирование ПО каждый раз создаёт ПО заново, с непредсказуемыми характеристиками и возможностями, которые надо перетестировывать заново, с нуля, с тем же уровнем недоверия, то в этой схеме не может произойти общее ускорение. В этой схеме есть моменты для локального ускорения, но в целом — нет. Это как таскать воду из колодца домой, и местами на этом пути находить сантиметрики, которые можно срезать, и весь путь туда-обратно как будто-бы сокращается и оптимизируется, да, но в целом как был километр, так и остался, и нужно принципиально другое решение, в котором вода в доме будет постоянно появляться, а таскать воду из колодца уже не придётся. Почему мы вообще занимаемся этим трудом Сизифа, к которому аргонавты каждый день прилетают и клюют печень да «трахаютЪ мозгЪ», уж простите, не знаю как это произносится по-древнегречески!? Если делать ПО, которое будет взаимодействовать только с другими ПО, то постоянное тестирование будет ненужным, оно перейдёт в режим одноразовой задачи, вы можете видеть положительный эффект этой условности в разделе API. А если делать ПО, которым будут пользоваться люди (местами бесконечно глупые, местами дъявольски умные), то и проверять его надо людьми, причём постоянно. Как это ускорить? Может быть, стоит убрать из этой схемы вообще всех, даром, и пусть LLM сами генерируют код и тесты, и впихивают это всё в CI/CD, и выполняют на проде, и пусть другие LLM этим всем пользуются и всё это покупают. Проекты же делают для прибыли, right? В общем, разгоняемся, пока можем. Про торможение будем думать, когда придётся начать тормозить…   Hop, hop, hop, hop, hop, hop, hoba! ]]> https://testitquickly.com/2026/02/20/mesterul-manole-rastoarna-caldarea/ Fri, 20 Feb 2026 15:08:10 +0300 Прочитал сегодня статью: инженеры из Anthropic и OpenAI говорят, что у них 100% кода пишет ИИ. Понятно, что в этом есть и маркетинг — ну а что ещё им говорить Но статья зацепила… Еще буквально недавно “ИИ помогает писать код” звучало как автокомплит и подсказки. А теперь инженеры из Anthropic и OpenAI публично говорят: в их работе ИИ пишет 100% продакшн-кода: “For me personally it has been 100% for two+ months now, I don’t even make small edits by hand,” “I shipped 22 PRs yesterday and 27 the day before, each one 100% written by Claude.” Со стороны OpenAI — максимально прямолинейно: “100%, I don’t write code anymore,” Если код больше не дефицит — что становится дефицитом? 1) Код дешевеет. Ясность — дорожает. Когда “написать” почти бесплатно, получается появляется новая инфляция: инфляция сложности Сами инженеры признают: ИИ может оставлять “dead code” и усложнять простую логику: «However, the transition isn’t without “slop.” Engineers admit the AI still makes mistakes, such as leaving behind “dead code” or overcomplicating simple logic» И это, кажется, станет новой нормой: писать проще, чем удерживать систему в здравом виде. А самый интересный момент — как они это лечат: ИИ проверяет ИИ (ревью агентом кода, написанного агентом): «To combat this, Anthropic engineers now use the AI to review itself.» Кстати, это реально киллер-фича. Я сам постоянно так делаю 2) Профессия “писать код” превращается в “рулить системой”. Там же звучит прогноз: индустрия “six to twelve months away from AI handling most or all of software engineering work from start to finish”. И тут появляется человек-оркестр, как говорят в интернетах  generalist — не “чуть-чуть обо всём”, а человек, который держит картину целиком: ставит рамки: — что нельзя делать, даже если “работает” — принимает решения: как сделать проще и дешевле в поддержке — делает результат доказуемым: тесты, мониторинг, безопасность, сценарии деградации Короче: ИИ пишет детали, а человек “сшивает” разные куски работы и отвечает за смысл и последствия. 3) Самый ценный навык будущего — не “уметь промптить”, а уметь задавать рамки. Очень понравилась формулировка из статьи: “Not all of the things people learned in the past translate to coding with LLMs,” “The model can fill in the details.” То есть детали допишет модель. А наша ценность — сказать, что делать и чего точно не делать, не дать решению разрастись и сделать так, чтобы это можно было проверить (тестами, логами, метриками). Мой вывод, глобально, я думаю ИИ никого не заменит, но люди владеющие ии, просто  вытеснят тех, кто ИИ не владеет. Прогресс не остановить. Какие у вас мысли по этому поводу? Вы же на всякий случай уважительно общайтесь с ИИ? ]]> http://prostoitblog.ru/my-nezametno-pereskochili-strannuyu-granitsu/ Wed, 04 Feb 2026 22:48:38 +0300 Описание книги — https://testbase.ru/books/sql Как заказать: В издательстве: https://bhv.ru/product/sql-kurs-molodogo-bojtsa/ Плюс скоро будет на OZON и других площадках, ищите по названию) Сегодня мне написал издатель с радостной новостью — моя четвертая книга уже вышла в продажу! Пока только на сайте издателя, но скоро и до маркетплейсов доберется! Ура!))) О чем книга SQL — язык общения с базой данных, в которой хранится вся информация вашего приложения. Данные пользователей, их заказов, или что-то другое. Зная SQL, можно посмотреть, что именно лежит в базе. Это нужно поддержке или тестированию для локализации проблемы, разработчику для отладки, а аналитику для анализа данных. Именно этому мы и будем учиться! С картинками котиков, которые объясняют суть, мы разберемся в том, как правильно составлять запросы. И на выходе вы будете уметь: 1. Писать простые select-ы (из одной таблицы) 2. Джойнить таблицы (объединять данных из двух таблиц) 3. Изменять данные в БД В конце каждой главы вы найдете задания для самопроверки. Используйте книгу как тренажер во время чтения, а потом возвращайтесь к ней как к справочнику! ]]> http://okiseleva.blogspot.com/2026/01/sql.html Thu, 29 Jan 2026 20:05:00 +0300 Лет сто назад меня засосала опасная трясина затрясло от того, насколько я стал зависимым от Facebook. Прям-трям постоянно очень было нужно посмотреть на лайки, дизлайки (тогда ещё были) и комментарии. Стало скучно — FB. Стало тревожно — FB. Стало весело — FB, всем сообщить… Удалил FB с телефона. Ну, такоэ, он же через браузер доступен… В Firefox на страницах FB через адблок спрятал все кнопки типа «лайк». Вместо тыцанья лайков можно писать комментарии. Вскоре понял, что и комментарии особо не нужны, и всё стало восприниматься более отстраненно — прочитал и прочитал, нет нужды на всё реагировать. Перевел все записи в режим «для друзей». Со временем вообще перехотелось что-то туда писать — исчезли все факторы «социального одобрения», реально полегчало. Стал делать записи на FB в «заметках», местами даже ценные (техника проезда серпантинов на машине, например), просто потому, что там сохранялась хронология записей. Сегодня все те «заметки» с FB исчезли — от спасибо, мрази… Самой жуткой особенностью FB всегда была абсолютная невозможность смотреть записи в хронологическом порядке, даже в своём аккаунте. Хайнлайн про это всё целый рассказ написал «Они» (They, 1939) — человек находится в дурке, и он уверен в том, что мир неправильный, что им управляют какие-то «кукловоды», а его уверяют в обратном. Но однажды шел сильный дождь, и человек (непонятно почему) отодвинул штору на окне, выходящем на тыльную сторону дома: Очень сильный дождь шел на фасадной стороне, а здесь, с этого окна, погода была прекрасной, солнечной и никакого дождя… И он пытался это всё объяснить Элис, своей жене, а она его уверяла в том, что ему просто показалось… А потом: Существо, которое он знал под именем Элис, не меняя своего облика вошло в комнату, где все они собрались. […] — …И наша программа потерпела поражение из-за того, что Вы не обеспечили тогда дождь не только с фасада, но и с тыльной стороны его дома. Впредь работайте более тщательно над выбором средств. Порядок в рассуждениях приходит от последовательности. Если последовательность убрать, рассуждение начнёт перескакивать с десятое на триста восемьдесят седьмое (почему бы и нет?) и обратно на — на что? На десятое? Нет, ведь в этом окружении нет последовательности. Вместо «десятого» посмотри на «семь тысяч двадцать шестое». Why, кагбэ, not? Нелогично, но логично — просто неочевидно. Я ж не просто перестал кликать по лайкам на FB, а затеял громадное исследование о том, как и почему какие-то записи появляются. И даже научная гипотеза была — мол, алгоритмы считывают, какой контент ты отмечаешь лайками, и формирует тебе ленту записей под твои реакции. Вероятно, полный отказ от лайков приведёт к тому, что лента придёт в логический порядок. И — ничего, бляха, не поменялось, неведома шняга в бэкграунде делает всё, что считает нужным, и единственный способ поменять её поведение — отказаться от её общества. Стал ходить в спортзал смотреть многочасовые записи аварий на Youtube. Отказаться от отвлечения невозможно, но просмотр этого контента хотя бы было полезным — чем больше аварий ты «видел», тем больше шансов их распознать задолго до происшествия (большинство происходят из-за неверных предположений, потому откровенная глупость, и только после чисто технические причины). К чему это я всё… Понятно, что невозможно просто перестать отвлекаться на что-то. Не будет FB и Youtube — будешь упорно считать муравьёв в муравейнике. Сегодня я на Facebook я вообще перестал ходить, и видео с авариями смотрю редко, но накатило неприятное ощущение о том, что я всё равно много зависаю в бездне бессмысленного в других источниках. Как-то сразу пришло и решение о том, что надо перестать реагировать, надо замедлиться: Нигде и никак не трогать кнопку like. Их даже прятать не пришлось, они как-то очень просто игнорируются, вероятно, помог когдатошний опыт насильного скрытия лайков в браузере. А никто и не заметит, что я ничего не лайкаю, быгыг, так что… Твиттер — включил режим «Защитить посты», в нём все записи видны только уже существующим читателям. Комментировать под другими записями можно, но это увидит почти никто, исчезает социальное взаимодействие. Threads — то же замое. Подзамочность ограничивает и мою возможность комментировать некоторые чужие постс, и это очень хорошо… Сигналы о получении новых сообщений — подавить повсюду. Хорошо бы и дверной звонок отключить. На днях прекратил контракт про стационарный телефон, и ничего не поменялось. В браузере есть расширение Enhancer for YouTube — убирает шортсы, убирает все «видео по данной теме», может убрать и комментарии. На экране осталось одно только видео, которое можно посмотреть и закрыть, ничего более. Когда в листе «Смотреть позже» собралось больше полутора тысяч видео — надо удалять, не может быть всё сразу важным и стоящим внимания. А я же ещё не разобрал каталог «Загрузки», там за много лет собралось 76 000 файлов, и не все они нужны, но какие-то важны, а какие-то просто дубли, и это всё тоже надо как-то (когда-то) рассортировать… При просмотре чего-то — не запоминать и не делать вид, что всё понятно, а делать записи в бумажном блокноте, с ручкой в руке. Это помогает замедлиться сосредоточиться, потому что записываешь только самое важное, и пересказываешь. И смысл этого не в том, чтобы записать услышанное, а чтобы после услышанного записать своё рассуждение, а его же надо хоть как-то обдумать. Много видео таким образом не посмотришь, и это помогает замедлиться. А ещё процесс заполнения ручки дорогими чернилами медитативен, последователен, всепоглощающ, однозначен. Выключать компьютеры, когда от них отходишь. Дело даже не в расходе электроэнергии, дело в принудительной смене фокуса. Надо ещё привыкнуть сразу гитары в кофры закатывать, а не перекладывать туда-сюда по комнате… Смотреть старые черно-белые фильмы, в которых последовательно рассказывают какую-то историю, с прологом, монологом и эпилогом. Ходить. Два кэмэ в одну сторону, и столько же обратно — без наушников, без аудиокниг, без цели. И важно to embrace the boredom. Мышление в порядок можно привести только насильно и лучше делать это принудительно, но самостоятельно. ]]> https://testitquickly.com/2026/01/25/likeuri-timpite/ Sun, 25 Jan 2026 10:59:42 +0300   Отдаю очередной должок 10-летней давности - что обещал и планировал прочитать, но долго прокрастинировал. Это не стеб. это стратегия - действительно хорошая книга с годами становится только лучше, получая кучу отзывов от тех кто прочитал раньше.  Книга наверное и была прорывной в 1990 году , но спустя 36 лет это... все еще так.  Книга так себе переведена на русский язык, но смысл сохранился. Принимая во внимание то, как изменилась реальность функционирования бизнеса с 1990 года часть утверждений и примеров приводимых в книге выглядит куцевато.  Системное мышление на уровне организации позволяет проводить действительно большие изменения в организации, но требует пререквизитов, которые собственно Питер Сенге и описал. От себя отмечу что 5 дисциплин обучающейся организации не кажутся мне чем-то прям совсем универсальным или являются исчерпывающим списком того, что в подобного рода организации должно быть. Скорее это тот минимальный базис ниже которого опуститься без последствий нельзя.  Дисциплины: личное совершенствование ментальные модели формирование общего видения командное обучение системное мышление   Стоит сказать, что по каждой из этих дисциплни автор проходится с разной степенью глубины, и это вот как раз снижает оценку данному труду.  Книга будет полезна руководителям либо команд со сложной доменной областью , либо руководителям на большом масштабе.  Оценка 7.5/10  Заметки в XMind https://xmind.app/m/nagd2i  ]]> http://test-failed.blogspot.com/2026/01/blog-post.html Wed, 21 Jan 2026 17:21:00 +0300