Software-Testing.Ru Blog Aggregator http://software-testing.ru/ Software-Testing.Ru Blog Aggregator ru-ru Copyright (C) 2009-2012 Software-Testing.Ru Как я сделала отчет о дифференциальном тестировании через Cursor Я хочу рассказать, как я сделала отчет о дифференциальном тестировании (сравнение двух функций на одних данных) через ИИ. Знаю, что многие уже применяют ИИ и в хвост и в гриву, но также много тех, кто пока не умеет этого делать.

Картинка на заставку, конечно же, тоже сделала через ИИ (нанобанано)
Картинка на заставку, конечно же, тоже сделала через ИИ (нанобанано)

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

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


Мой пример

1. Проведение тестирования

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

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

  1. делаем вторую функцию, 

  2. готовим тестовые данные, 

  3. прогоняем их на старой и новой функции,

  4. анализируем результат — если “да, круто вышло!”, то заменяем одну функцию на другую, если “чет не то”, то думаем дальше.

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

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

Данные собрала, потом написала автотесты. Выглядят они примерно так (для простоты понимания будем сравнивать ФИО):

Опечатка в отчестве;99;Назина;Ольга;Евгеньевна;Назина;Ольга;Еквгеньевна
Объяснить с

Что тут есть:

  • Описание теста

  • Коэффициент похожести

  • ФИО первой пары в трех ячейках

  • ФИО второй пары

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

Если автотест упадет, выглядеть это будет так (допустим, вместо коэффициента 99 вернулся 0):

 Expected:  [2/Similarity]:99

     Actual:  [2/Similarity]:0

Input data: 1. Опечатка в отчестве;99;Назина;Ольга;Евгеньевна;Назина;Ольга;Еквгеньевна

Etalon data: 1. Опечатка в отчестве;99;Назина;Ольга;Евгеньевна;Назина;Ольга;Еквгеньевна

Result data: 1. Опечатка в отчестве;0;Назина;Ольга;Евгеньевна;Назина;Ольга;Еквгеньевна

Это стандартный вывод автотестов:

  • Input data — что на входе

  • Etalon data — что я ожидаю

  • Result data — что тест ожидает

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

Итак, автотесты я сделала. Получилось их довольно много, больше 300, так как много разных сценариев нужно было покрыть + на каждый сценарий надо было сделать 2-6 тестов (тест-дизайн и все такое).

Прогнала на новой функции — 100 падений (цифры эти для примера, но чтобы показать масштаб проблемы формирования результата). Сохранила результаты прогона в файл new.txt.

Прогнала на старой функции — 200 падений (то есть новая работает лучше).  Сохранила результаты прогона в файл old.txt. 

Огонь, осталось оформить!

2. Оформление результата

Я подумала — как я хочу видеть результат? Хорошо бы в виде таблички, чтобы сразу видно “эта функция справилась, эта нет”.

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

Описание

Коэф

ФИО 1

ФИО 2

testOldFunction

testNewFunction

Комментарий

testOldFunction работает, testNewFunction нет

1. Опечатка в отчестве

99

Назина

Ольга

Евгеньевна

Назина

Ольга

Еквгеньевна

Успех

FAIL / ожидает 0

По сути я просто вытащила все колонки из теста и добавила в конец 3 новые для анализа результата:

  • testOldFunction — как справилась старая функция

  • testOldFunction — как справилась новая функция

  • Комментарий — чтобы подсвечивать “тут некритично, а тут обратите внимание!”

Что писать в колонки прогонов:

  • Успех — если в файле прогона функции НЕТ этого теста, значит, он не упал, а прошел успешно. По крайней мере я сохранила в файл именно падения.

  • «FAIL / ожидает такое-то значение», чтобы было видно, что ждем мы (2 колонка) и что выдал тест.

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

  • Старая функция работает, новая нет

  • Новая функция работает, старая нет

  • Обе не работают

И внутри еще сгруппировать (помните ведь, что падений было 200+, да?). Я посмотрела глазками отчеты и выделила некоторые повторяющиеся падения. 

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

  • Сразу увидеть масштаб проблемы — сколько таких сценариев сломалось

  • Понять, что еще сломалось — увидеть все другие падения отдельно, а не так, что через раз будет “снова двойное имя”.

Так, работа понятна! Но делать ее вручную — это ж капец сколько времени! Вытащить из результатов падений что-то одно (например, строку Result data), чтобы открыть в экселе, а не блокноте, чтобы это все скопировать и вставить в таблицу в конфлюенсе.

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

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

Я выгрузила эту табличку из конфлюенс в ворд-файл test_results_demo.docx, чтобы скормить ИИ. Правда, пришлось внести коррективы уже на этом этапе. Исходно то я и правда вставила в конфлюенс тест «как ]]> http://okiseleva.blogspot.com/2026/07/cursor.html Tue, 21 Jul 2026 17:40:06 +0300 Как тестировщику участвовать в open-source проектах Автор: Има-Абаши Эффионг (Ima-Abasi Effiong)
Оригинал статьи
Перевод: Ольга Алифанова

Почему тестировщикам важно участвовать в проектах с открытым исходным кодом (OSS)

Участие в open source помогло мне приобрести множество навыков. Я научилась эффективно и уважительно общаться, что укрепило уверенность при взаимодействии с людьми. И хотя я не пишу код, я стала уверенно пользоваться GitHub и командной строкой в терминалах — навыком, который можно освоить только на практике. Open source предоставляет такую возможность.

]]> https://software-testing.ru/library/around-testing/job/4500-how-to-contribute-to-open-source-projects-as-a-software-tester Sun, 19 Jul 2026 23:00:00 +0300 Мобильный маркетинг начинается с QA: как тестирование влияет на модерацию и рейтинг приложения

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

Эта статья – для тех, кто продвигает мобильные приложения. Можно готовить гениальные рекламные кампании, но низкий рейтинг в сторах убивает конверсию на корню. К тому же магазинов становится всё больше: от классических Play Market и App Store до отечественного RuStore и более экзотических альтернатив – например, AppGallery от Huawei (его пришлось запустить из‑за закрытия доступа к сервисам Google). Работать сложнее из‑за региональной фрагментации интернет‑среды и всеобщей зарегулированности.

Так, может, пусть айтишники сами разбираются? При чём здесь маркетинг?

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

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

За последние полтора года я много общалась с тестировщиками, ходила на вебинары, прочитала книгу Романа Савина «Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет‑стартапах», прошла курсы по QA на Stepik и в учебном центре своей компании. Я не эксперт по QA и не претендую на этот статус, но у меня есть взгляд со стороны маркетинга – и именно с этой точки зрения мне открылась одна неприятная вещь, которой хочу с вами поделиться.

Тезис у меня простой и немного провокационный

мобильный маркетинг

Пройдёт ли приложение модерацию? 
Как пользователи его воспримут? 
Понравится ли оно им? 
Какой отзыв оставят?

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

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

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

Немного о продуктовом подходе

В России мобильные маркетологи нередко отвечают за продвижение и репутацию – занимаются ASO, работают с карточкой приложения, модерируют отзывы, а иногда и следят за опытом пользователя после установки. При этом в небольших проектах техническую часть берут на себя IT‑специалисты, а QA‑инженера зачастую вообще нет. На Западе подход другой: зоны ответственности чётко разделены – есть отдельные ASO‑, ORM‑ и QA‑специалисты, ведь там давно считают качество продукта основой маркетинга (вспомним классику маркетинга – 4P: сначала продукт, потом цена, место и продвижение).

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

Для размышлений

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

  2. По данным исследования Elsevier, сбор обратной связи пользователей при развитии приложения приводит к улучшению пользовательских оценок. Ну а пользовательский опыт напрямую зависит от качества продукта (привет, QA).

Мобильный маркетинг начинается с тестирования

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

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

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

Первый шаг: модерация

Важный нюанс: нет единого списка требований для прохождения модерации. Каждый стор публикует собственные правила. При этом около 80% требований совпадают. Мы собрали их для вас в одну обзорную таблицу.

тестирование мобильных приложений

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

Интересная статистика: по разным оценкам, в App Store около четверти новых приложений не может пройти модерацию с первого раза. Вот что чаще всего становится причиной отказа (по сводкам за 2025–2026 годы):

Приватность (Guideline 5.1.1). Нет ссылки на политику конфиденциальности внутри приложения и в метаданных, приложение просит доступы к геолокации, контактам, камере без внятного объяснения зачем, нет возможности удалить аккаунт прямо в приложении. Apple на приватности повёрнут, и это самый частый повод для разворота.

  1. Краши и баги (Guideline 2.1, «App Completeness»). Ревьюер словил вылет, фриз или нерабочий экран — всё, до свидания. И не важно, что у вас на устройстве всё летает: у него другая модель телефона, другая версия ОС, слабый интернет — и баг вылез.

  1. Метаданные не соответствуют реальности (Guideline 2.3). Скриншоты показывают функции, которых в приложении нет. Или — мой любимый случай — на скриншоте для App Store размещён макет на Android-телефоне. Это мгновенный разворот (это уже точно маркетинговый косяк).

  1. Сырой материал. Тексты «Lorem ipsum», «coming soon», битые ссылки, нерабочий support URL (ревьюер по нему реально кликает и ждёт увидеть живую страницу поддержки).

  1. Покупки и подписки (Guideline 3.1.1). Сломана или спрятана кнопка «Восстановить покупки».

  1. Минимальная функциональность (Guideline 4.2) и клоны (4.1). Например, если Apple считает, что ваше приложение ничем не отличается от браузерной версии продукта.

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

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

Второй шаг: рейтинг и видимость

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

продвижение мобильных приложений

Вот несколько интересных отрезвляющих цифр.

90% приложений, которые попадают в подборки App Store, имеют рейтинг 4,0 и выше. Приложения с рейтингом ниже 3,5 ранжируются примерно в три раза реже в топ-10 по ключевым запросам.  Это подтверждается исследованием AppTweak.

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

77% людей читают хотя бы один отзыв перед установкой бесплатного приложения, 80% — перед платным. Приложение с рейтингом ниже 4,0 часто просто пролистывают, даже если оно стоит высоко в выдаче.

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

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

Откуда берётся низкий рейтинг?

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

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

53% пользователей удаляли мобильное приложение, если сталкивались с серьёзными проблемами — крашами, зависаниями или ошибками.

В индустрии есть бенчмарк стабильности — доля сессий без крашей (crash-free sessions). Норма сейчас около 99,95%. Звучит как почти 100%, но истина в хвостике: приложения, у которых этот показатель падает ниже ~99,7%, статистически уезжают в зону рейтинга ниже 3 звёзд. Десятые доли процента крашей — и вот вам минус звезда.

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

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

Тестирование мобильных приложений

продвижение мобильных приложений

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

Чек-лист сознательного маркетолога

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

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

    • ссылка на политику конфиденциальности есть и внутри приложения, и в метаданных, и она открывается;

    • удаление аккаунта доступно прямо в приложении (если есть регистрация);

    • support URL ведёт на живую страницу с реальным способом связи, а не на 404 или заглушку;

    • скриншоты показывают то, что реально есть в приложении, и соответствуют устройству (никаких андроид-макетов в App Store);

    • никаких «Lorem ipsum» и других сырых штук;

    • кнопка восстановления покупок на месте и работает.

    3. Приложите ревьюеру записку (Review Notes). Если публикуете приложение не вы, то подсветите эту необходимость команде и подготовьте текст. Если в приложении есть вход – дайте демо-аккаунт и логин/пароль ревьюеру. Опишите, как протестировать неочевидные фичи, объясните, зачем вы просите доступ к камере или геолокации. Половина отказов случается просто потому, что при ревью не смогли разобраться. Это, между прочим, чистый копирайтинг – тоже часть нашей работы.

    4. Настройте мониторинг отзывов. Раз в неделю разбивайте свежие отзывы на три группы: баги, проблемы UX и запросы фич. Баги — немедленно командам разработки и тестирования, чтобы они не снижали рейтинг. И отвечайте на негатив в течение 24–48 часов: люди, получившие живой (не шаблонный!) ответ на плохой отзыв, заметно чаще возвращаются и поднимают оценку. 

    5. Подружитесь с метрикой crash-free sessions. Попросите у команды доступ к Firebase Crashlytics или аналогу и оценивайте его как маркетинговый показатель. Падение этой цифры – ранний сигнал, что через неделю-другую к вам поедет волна негатива и просядет рейтинг. Лучше узнать об этом из дашборда, чем из отзывов.

    6. Не лейте трафик на сырое приложение. И это главное. Запустить дорогую рекламную кампанию на продукт, которое крашится у каждого десятого, – значит платить за одно­звёздочные отзывы. Вы своими руками приводите в стор недовольную аудиторию.

    7. Тестируйте не только продукт, но и карточку. A/B-тесты скриншотов, иконки, текстов – это ASO, то есть наше поле. У топовых игр в Google Play больше половины команд тестируют скриншоты по нескольку раз в год, и это даёт ощутимый прирост конверсии. Тут маркетинг и культура тестирования вообще сливаются в одно.

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

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

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

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

    ]]>     https://quality-lab.ru/blog/mobilnyj-marketing-nachinaetsya-s-qa-kak-testirovanie-vliyaet-na-moderaciyu-i-rejting-prilozheniya/ Thu, 16 Jul 2026 17:27:47 +0300     При общении с ИИ не усложняйте вопрос, это сожрет лишние токены  Я тут код исправляла грязными ручками. Скрипт заполнения таблицы составляется примерно так:

    insert into table
( column_1, column_2, column_3, column_4)
    select 'SYSTEM_A',  'ANY',       'ANY',      30 from dual union
select 'SYSTEM_B',  'ANY',       'ANY',      60 from dual union
select 'SYSTEM_C',  'ANY',       'ANY',      60 from dual;

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

    Я вроде понимаю, что где-то в скрипте "typo-fix" нужен, опечатка какая-то, но какая и где? Скрипт большой, самой искать не хочется. Решила сходить к Курсору за советом. И я же научена вводить в контекст, так что подсветила ему, какая именно ошибка мне выдается при сборке:

    Проверь файл C:\tmp\schema\init\my_script.sql. При сборке мавеном падает на создании контекста: Caused by: org.hsqldb.HsqlException: unexpected end of statement : line: 96. Что не так в скрипте?

    Курсор ушел в себя на час! Он насоздавал 17 файлов, запустил 69 команд, перебирая скрипт и всё, что лежит вокруг. Сожрал кучу токенов, что тоже важно.



    А ошибка оказалась банальной, это как внутри JSON-запроса обычно бывает, когда местами строки меняешь:
    • в последнюю строку накопипастил запятую в конце
    • в непоследнюю строку скопипастил БЕЗ запятой в конце
    Тут аналогично, непоследняя строка должна быть с union и без точки с запятой, последняя — наоборот. А я в одном или двух местах сделала криво.

    И можно было просто скормить ИИ-шке файл с вопросом, есть ли в скриптах проблемы. По идее, должен найти, в JSON-запросе находил легко. 

    А тут я подсказала, что собираю мавеном, номер строки, на которой падает. Поэтому робот проверил эту строку — не на ней. Пошел изучать контекст, из чего скрипт в мавене собирается... И все это сожрало кучу времени и токенов =))

    И ведь была у меня мысль просто попросить проверить скрипт на ошибки, вне контекста. Задать вопрос попроще. Не стоило ее отметать ????

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


    PS — эта статья написана в помощь студентам моего курса «Применение ChatGPT в тестировании» 

    ]]>     http://okiseleva.blogspot.com/2026/07/blog-post.html Thu, 16 Jul 2026 17:22:34 +0300     Типы границ для классов эквивалентности Автор: Ольга Назина (Киселёва), автор курса Школа для начинающих тестировщиков

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

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

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

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

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

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

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

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

      ]]> https://software-testing.ru/library/testing/test-analysis/4527-types-of-boundaries-for-equivalence-classes Tue, 14 Jul 2026 23:00:00 +0300 Начинаем работу с мутационным тестированием Автор: Баз Дейкстра (Bas Dijkstra)
      Оригинал статьи
      Перевод: Ольга Алифанова

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

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

      ]]>       https://software-testing.ru/library/testing/other-testing/4499-on-getting-started-with-mutation-testing Sun, 12 Jul 2026 23:00:00 +0300       Настраиваем IDEA с ИИ, уточняем теорию, часть 3  С вами рубрика «где тестировщик может применять ИИ в своей работе»!

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



      1. Как отменить настройку в IDE?

      Тыкнула в эксель-файлик в Giga IDE, он предложил прочитать его как текстовый, я сдуру и согласилась. А там все очень плохо с отображением таких файлов, если что))

      Но теперь, тыкая на любой эксельник, он открывается в ИДЕ криво-косо. И тут или страдать (Open in explorer, чтобы открылась виндовая папка, открывать в ней), или изменить настройку. А где? 

      Отличный вопрос для ИИ! Прям так ему и пишем — что сделали и вопрос "как исправить":

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

      ИИ выдал пошаговую инструкцию:

      Чтобы вернуть настройки и сделать так, чтобы Excel-файлы (.xlsx, .xls) открывались в системном приложении (MS Excel, LibreOffice и т.д.), а не как текст внутри Giga IDE, вам нужно изменить ассоциации файлов в настройках.

      Вот пошаговая инструкция, как это сделать:

      Шаг 1. Откройте настройки

      • Нажмите Ctrl + Alt + S (на Windows/Linux) или Cmd + , (на macOS).

      • Или перейдите через верхнее меню: File (Файл) -> Settings (Настройки).

      Шаг 2. Перейдите в раздел «Типы файлов»

      1. В левой колонке настроек разверните узел Editor (Редактор).

      2. Выберите пункт File Types (Типы файлов).

      ...

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



      2. Как в гига иде поискать по названию класса?

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

      как в гига иде поискать по названию класса?


      ИИ ответил подробно, даже пару способов поиска привел, но меня интересовал вот этот кусочек:

      Этот способ ищет только среди классов, интерфейсов и enum, игнорируя обычные файлы и текст.

      • Windows / Linux: Ctrl + N

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



      3. Что значит опция в гит-команде?

      Давно ничего не коммитила, подзабыла как это делается. Плюс у нас обновились иснтрукцию по созданию бранчей и коммитов туда. Вот, например, перед пушем теперь делаем пуш с --dry-run. А что это такое?

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


      что значит Тестовый push с dry-run ?

      git push origin --dry-run
      И, пожалуйста, порция теории по моему вопросу!

      Флаг --dry-run (в переводе «пробный прогон» или «сухая тренировка») — это режим безопасной проверки.

      Когда вы выполняете git push origin --dry-run, Git не отправляет ваши коммиты на сервер. Вместо этого он имитирует процесс отправки и показывает вам, что именно он собирался бы сделать, если бы вы запустили реальную команду.

      Зачем это нужно?

      Это отличный способ избежать ошибок перед важным пушем. Git покажет:

      1. Какие ветки он собирается обновить.

      2. Какие коммиты будут добавлены.

      3. Какие теги будут отправлены.

      4. Будут ли какие-то конфликты или ошибки доступа, не меняя ничего на самом сервере.

      Пример того, что вы увидите в терминале:

      ...

      Когда стоит использовать:

      ...

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


      В коммите нужен флаг -a, его если и помнила, то забыла. Снова к чату:

      git commit -a -m

      а что значит "-а"?

      Тут ответ приводить не буду, но смысл понятен — видишь что-то незнакомое, спроси чат! Если не понял ответ, можно так и сказать "я не поняла, зачем эта опция, покажи с примером"

      PS — эта статья написана в помощь студентам моего курса «Применение ChatGPT в тестировании» 

      ]]>       http://okiseleva.blogspot.com/2026/07/idea-3.html Fri, 10 Jul 2026 15:15:29 +0300       5 промтов, которые сэкономили мне часы рутинной работы тестировщика Автор: Екатерина Гаврилова (QA Tech Lead в MD Audit)

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

      ]]>       https://software-testing.ru/library/testing/other-testing/4526-ii Wed, 08 Jul 2026 23:00:00 +0300       Как маркетологу готовить сайты и приложения к акциям – и почему нельзя слепо доверять своим айтишникам

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

      Всё поменялось, когда я пришла маркетологом в «Лабораторию качества» – компанию, которая давно работает на IT‑рынке и специализируется на обеспечении качества ПО, сайтов и приложений. Погружаясь в QA‑услуги, я всё чётче видела, насколько это ценный инструмент для маркетолога. Жаль, что раньше мне никто не подсказал: нельзя полностью полагаться на IT. Сколько проблем можно было избежать! Сбои во время рекламных кампаний, падение функционала в самый горячий момент – всё это било по бюджету и репутации. А ведь достаточно было просто проверить площадку для приёма трафика под нагрузкой.

      История о том, как наша реклама обвалила сайт федерального билетного оператора

      Объясню на конкретном кейсе. В 2023 году в Белгороде появился новый парк аттракционов «Калейдоскоп», и отдел, который я возглавляла на тот момент, курировал открытие и продвижение этого объекта.

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

      В начале всё шло хорошо. Я лично зашла в кабинет к нашим разработчикам и спросила, выдержит ли лендинг нагрузку. Конечно же, мне ответили в духе:

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

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

      Мы приступили к запуску и дальше ситуация развивалась стремительно.

      2 августа в 14:30 мы объявили о начале брони билетов. 

      В 14:37 наш лендинг сначала затормозил, а потом обвалился. Потом заработал – и снова обвалился. И так несколько раз: полная катастрофа. 

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

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

      Нагрузочное-тестирование-для-маркетологов

      нагрузочное-тестирование-для-маркетологов

      Тогда я не знала, что всего этого можно было бы избежать, если бы IT‑служба и моей компании, и сервиса Kassir.ru заранее провела тестирование под нагрузкой. Как мы помним, незнание не освобождает от ответственности. Это правило, к сожалению, работает не только в правовом поле, но и в коммуникационном.

      Нужно было что‑то решать. Мы договорились с руководством и для снижения градуса негатива решили раздать ещё 500 билетов, заранее объяснив ситуацию: могут быть сбои, это не обман, а издержки цифровизации. Мы сообщили, что, если желающих снова будет несколько тысяч одновременно, то сайт, к сожалению, может вновь не выдержать такой нагрузки. Тем более что операторы Kassir.ru уже предупредили нас об этом. Вторая волна тоже не прошла без происшествий, но поток негатива всё равно удалось остановить.

      Почему не стоит всё перекладывать на IT-службу?

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

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

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

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

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

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

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

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

      Где тонко, там и рвётся

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

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

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

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

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

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

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

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

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

      Что такое нагрузочное тестирование и зачем это маркетологам?

      Расскажу так, как мне самой объяснили, когда я ещё особо ничего не понимала.

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

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

      Вид тестирования Суть для маркетологов
      Нагрузочное тестирование (load) Выполняется, когд нужно понять, выдержит ли система трафик во время акции. Для маркетолога это страховка: вы заранее знаете, потянет ли сайт ожидаемый приток пользователей
      Стресс‑тест (stress) Задача – найти точку, где система ломается. Нагрузку повышают и создают буквально экстремальные условия, пока сервис не начнёт сбоить. Так вы узнаёте реальный потолок возможностей ваших IT-продуктов до того, как столкнётесь с этим в реальности
      Пиковая нагрузка (spike) Проверяем сценарий «все пришли в одну минуту» – как бывает после рассылки, пуша или поста у крупного блогера. Именно такой резкий всплеск чаще всего срывает акции, и тест помогает к нему подготовиться
      Тест стабильности (soak) Смотрим, как система ведёт себя при долгой нагрузке – например, в течение недельной распродажи. Так выявляют проблемы, которые не проявляются сразу: утечки памяти, постепенное накопление сбоев
      Объёмное тестирование (volume) Выясняем, как сервис справляется, когда в базе не тысяча заявок, а миллион. К концу большой акции база сильно разрастается – и функционал, который отлично работал в начале, может сильно замедлиться

      Главное – получить не просто «всё ок» или «всё плохо», а чёткие цифры. Например: система стабильно держит 8000 одновременных пользователей, при 11 000 начинает тормозить корзина, при 14 000 перестаёт работать оформление заказа. Узкое место – пул соединений к базе данных, на восстановление после пика нужно около двух минут.

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

      На какие метрики нужно ориентироваться?

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

      RPS (запросов в секунду) – показывает, сколько обращений система обрабатывает за секунду. Простая, но надёжная оценка пропускной способности.

      Зачем маркетологу: помогает понять, выдержит ли сайт всплеск трафика во время акции – и не потеряет ли компания деньги из‑за того, что система «не потянет» наплыв пользователей.

      Время отклика – сколько уходит на ответ пользователю. Тут важно не ориентироваться на среднее значение: оно может скрывать проблемы.

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

      Перцентили (p95, p99) – самый полезный показатель. Например, p95 = 2 секунды значит, что 95 % пользователей получают ответ быстрее, а 5 % ждут дольше. Если смотреть только на среднее, можно не заметить, что часть клиентов подолгу висит на загрузке – и терять премиальный трафик.

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

      Error rate (доля ошибок) – процент запросов, которые завершились ошибкой под нагрузкой. Добиться нуля почти невозможно, но важно заранее определить, какой уровень ошибок для вас допустим.

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

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

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

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

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

      Чек-лист: как подготовить площадку перед запуском акции, распродажи или рекламной кампании

      стресс тестирование

      Это то, что спасёт вас от сбоев, проблем и головной боли. Главное –  спланировать и подготовить всё заранее. Даю вам рабочий таймлайн, проверенный на опыте.

      Для тестирования используют разные инструменты – чаще всего JMeter, k6, Gatling, Locust, Яндекс Танк. Из более серьёзных решений – LoadRunner и NeoLoad. Маркетологу не нужно в них разбираться. Достаточно уметь задать простой вопрос: «Каким инструментом, по каким сценариям проверяли и какие цифры получили?»

      За 3–4 недели до старта:

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

      • Опишите, что будет делать пользователь во время акции: как зайдёт на сайт, как найдёт товар, как добавит в корзину и т.д. (всё зависит от конкретно вашего пользовательского пути – чем конкретнее пропишите, рем реальнее будет симуляция нагрузки).

      • Заранее согласуйте бюджет на тестирование, особенно, если в вашей компании нет QA-инженеров.

      За 2 недели:

      • Проведите нагрузочное и стресс‑тестирование на копии системы (на стенде, как называют его в IT). Получите чёткие данные, где именно система начнёт сбоить.

      • Отдельно прогоните сценарий резкого наплыва (spike) – когда все заходят одновременно. Сбои из-за пиковых нагрузок особенно распространены при запуске рекламы.

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

      За неделю:

      • Вместе с IT устраните узкие места или осознанно сократите планируемый поток пользователей. Главное – действуйте на основе данных, а не наугад.

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

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

      В день акции

      Держите рядом дежурного от IT – не просто «на телефоне», а по‑настоящему на связи и готового сразу реагировать.

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

      А кто, собственно, должен платить за тестирование?

      Перехожу к неудобному вопросу: из какого бюджета должны идти деньги на тестирование? IT не закладывает, потому что для них стабильность систем во время акций и распродаж не входит в KPI. Маркетинг не закладывает, потому что считает, что ещё только технических вопросов им не хватает ко всем прочим.

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

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

      нагрузочная проверка сайта

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

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

      По итогу

      Выдержит ли сайт или приложение прирост трафика? Это можно узнать заранее: предупреждён – значит вооружён. Нагрузочное тестирование даёт гарантию и понимание ситуации. С ним вы управляете рисками, а без него – тратите нервы, которых у нас в маркетинге и так не хватает. Доверяйте внутреннему IT, но перед крупными событиями лучше привлечь подрядчика по тестированию нагрузки – и заранее заложить бюджет на QA‑услуги.

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

      ]]>       https://quality-lab.ru/blog/kak-marketologu-gotovit-sajty-i-prilozheniya-k-akciyam-i-pochemu-nelzya-slepo-doveryat-svoim-ajtishnikam/ Wed, 08 Jul 2026 16:47:02 +0300       Как убрать поп-ап с параметром в ТeamСity Столкнулась с такой проблемой — заходишь в ТeamСity (он же ТС) запустить деплой на тестовый контур, нажимаешь «Run», а тебе вылезает поп-ап окно «А вот этот параметр вы какой ожидаете?».

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

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


      Как убрать поп-ап в шаблоне (на N сборок)

      1. Открыть нужную сборку в ТС, нажать "Edit configuration"



      2. Но менять мы будем не эту конкретную конфигурацию, а шаблон! Сверху видим надпись «Based on templates» и список шаблонов, на которых основана сборка, в виде ссылок. Выбираем нужный шаблон и проваливаемся в него.

      3. Перейти в параметры:


      4. Редактировать нужный параметр — кнопка «Edit»

      5. Видим параметры, прописанные одной строкой, но можно нажать кнопку «Edit», чтобы проще их редактировать было:


      6. И вот тут параметр Display:

      • Prompt — вылезать поп-апом
      • Normal — обычный режим
      • Hidden — вообще спрятать параметр (если в конкретной сборке он мешает)

      Меняем на Normal, сохраняем - мы красавцы!


      Как поменять параметр в конкретной сборке

      Если бы надо было оставить параметр в шаблоне, но изменить только в конкретной сборке, основанной на нем, то в конфигурации сборки не надо переходить в шаблон (шаг 2 пропускаем).

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

      ]]>       http://okiseleva.blogspot.com/2026/07/eamity.html Tue, 07 Jul 2026 20:21:52 +0300       Заранее находим, что тестировать: модель ревью требований Автор: Ханиша Арора (Hanisha Arora)
      Оригинал статьи
      Перевод: Ольга Алифанова

      Тестирование программного обеспечения — это не только поиск багов, но и их предотвращение. Случалось ли вам смотреть на требование и думать: «вроде всё нормально»? А затем, спустя несколько недель, наблюдать, как код по этому требованию превращается в баг-репорт, часы доработок или недовольство стейкхолдера? Это знакомо не только вам.

      Именно поэтому была создана модель ревью требований (Requirements Review Model, RRM): чтобы дать тестировщикам и командам простой и единый подход к ревью. Это помогает повышать качество ещё до того, как написана хоть одна строка кода.

      Модель была создана для сертификата Software Testing Essentials от Ministry of Testing (MoT), чтобы обучать тестировщиков-новичков ревью требований. В MoT решили, что будет полезно поделиться моделью со всеми, за пределами сертификата, и поддержать тестировщиков и их команды. Это соответствует их цели — развивать индустрию любыми позитивными способами. Поэтому и написана эта статья!

      ]]>       https://software-testing.ru/library/around-testing/requirements/4498-finding-software-testing-opportunities-early-with-the-requirements-review-model Mon, 06 Jul 2026 23:00:00 +0300       Перестаньте считать баги: современные метрики тестирования для IT-команд

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

      Вот история, которая много лет назад навсегда отучила нас гордиться количеством найденных дефектов. Был у нас релиз – чистый, образцовый. За спринт команда тестирования нашла 214 багов, закрыла 209, а пять оставшихся сочла косметическими – решили поправить позже. На ретро все были довольны: менеджер строил график «найдено/исправлено», стрелочка вверх, дофамин рекой. Релиз выкатили в прод в пятницу вечером (да, знаем, знаем, — это же классика).

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

      метрики тестирования

      Мы тогда чинили это 14 часов. И пока в шесть утра приходилось буквально в пижаме объяснять по телефону, почему мы пустили это в прод, стало ясно: нам платят не за найденные баги, а за то, чтобы релиз был качественным и предсказуемым. Оказалось, всё это время мы измеряли не то. Заказчику было всё равно сколько багов удалось найти - его боль была в том, чтобы релиз не был похож на лотерею.

      Почему считать баги уже недостаточно?

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

      Что не так с этой метрикой? Разберёмся по пунктам:

      1. Она ничего не говорит о качестве продукта. 500 багов в спринте – это плохой продукт или хорошая команда тестирования? А 5 багов – это шедевр разработки или просто никто толком не тестировал? 

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

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

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

      метрики тестирования

      В чём настоящая ценность QA для бизнеса?

      Если коротко: зрелое тестирование должно обеспечивать предсказуемость. Чтобы за день до релиза можно было честно сообщить бизнесу: с вероятностью N% релиз пройдёт без серьёзных проблем, а если что‑то и сломается – то вот в этой зоне, при этом восстановление займёт столько-то минут.

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

      MTBF и MTTR – две QA-метрики нового поколения

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

      MTBF (Mean Time Between Failures) – среднее время между сбоями. 
      Суть: сколько ваша система спокойно работает, прежде чем что-то отвалится. 

      Считается так:

      MTBF = суммарное время нормальной работы /количество сбоев

      Например: работали 30 дней, было 3 серьёзных инцидента – MTBF около 10 дней. Это метрика стабильности. Чем она больше, тем реже сбои.

      MTTR (Mean Time To Recovery) – среднее время восстановления.
      Суть: это метрика устойчивости. Чем она меньше, тем система стабильнее.

      Считается так:

      MTTR = суммарное время простоя / количество инцидентов

      Например: за месяц случилось три инцидента общей продолжительностью 150 минут, поэтому среднее время восстановления (MTTR) составило 50 минут.

      количество багов

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

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

      Именно на основе этих значений рассчитывают доступность (availability) – ту самую, что закладывают в SLA как «четыре девятки».

      Доступность = MTBF / (MTBF + MTTR)

      Почувствуйте разницу. Фраза «нашли 214 багов» говорит о прошлом и отражает сам процесс работы. А показатели «MTBF вырос с 6 до 19 дней, MTTR сократился с 4 часов до 35 минут» показывают реальный результат и дают представление о будущем. Первые цифры уместно обсуждать внутри команды, вторые – спокойно представлять совету директоров.

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

      it риски

      Риск-ориентированное тестирование: как выпускать релизы без лишних затрат?

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

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

      Риск = Вероятность сбоя × Влияние сбоя

      Дальше берём все наши функции/модули/сценарии и раскидываем по матрице.

      Вот рабочая риск-матрица, которую мы используем (5×5 многим избыточна, начните с 3×3):

      Влияние низкое Влияние среднее Влияние высокое
      Вероятность высокая Средний риск Высокий Критический
      Вероятность средняя Низкий Средний Высокий
      Вероятность низкая Низкий Низкий Средний

      Как пользоваться матрицей:

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

      • Средний риск – проверяем разумно, без фанатизма. 

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

      Что вы получаете на выходе:

      • Чёткое понимание рисков релиза

      • Аргумент для бизнеса: «вот этот модуль мы покрываем на 95%, а вот этот – на 40%, потому что цена ошибки тут копеечная». Это взрослый разговор.

      • Защиту от неэффективного расходования ресурсов на проекте.

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

      Какие ещё показатели помогают в управлении IT-рисками?

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

      • Defect Escape Rate, доля «сбежавших» дефектов. Она показывает соотношение багов, найденных до продакшена, к тем, что всё‑таки попали в прод. 

      Escape Rate = баги, найденные в проде / (баги в проде + баги до прода)

      Это самая честная оценка качества тестирования – не сколько багов нашли, а сколько проворонили. Например, 214 багов до релиза и один в проде – это отличная работа. А вот 12 багов до релиза и 8 в проде – явный пробел в покрытии, сколько бы дефектов ни выявили. Стремитесь держать Defect Escape Rate на уровне ниже 5–10% – дальше ориентируйтесь по особенностям проекта.

      • MTBF / MTTR – про них уже писали выше. Это база.

      • Change Failure Rate – доля провальных изменений: она показывает, какой процент релизов приводит к инциденту, откату или хотфиксу. Эта метрика из исследования DORA прямо отвечает на вопрос, насколько предсказуем релиз. У сильных команд показатель держится на уровне единиц процентов, у команд в постоянном аврале – превышает 30%.

      • MTTD (Mean Time To Detect) – это время, за которое команда замечает, что система сломалась. Бывает, что MTTR отличный, но проблема в другом: о сбое узнают от недовольных пользователей в соцсетях спустя два дня. Если вы узнаёте о проблеме последним – быстрое исправление уже не спасает ситуацию.

      • Покрытие рисков важнее покрытия строк кода. Code coverage в процентах нередко вводит в заблуждение: можно иметь 90% покрытия и при этом тестировать то, что не влияет на стабильность системы. Гораздо полезнее отслеживать, какая доля критических сценариев из риск‑матрицы покрыта тестами. Именно этот показатель помогает в управлении IT-рисками , а не показывает формальные проценты.

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

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

      Пошаговый план перехода к риск-ориентированному тестированию

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

      риск ориентированное тестирование

      1. Начните с измерения состояния прода. Без мониторинга и учёта инцидентов MTBF и MTTR – просто красивые термины, а не рабочие метрики. Заведите простой журнал инцидентов: фиксируйте, что случилось, когда, сколько времени ушло на исправление и как проблему обнаружили. Это не требует затрат, но сразу даёт чёткую картину.

      2. Соберите риск‑матрицу – на это хватит одного вечера, а польза сохранится на месяцы. 

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

      4. Введите блеймлесс-постмортемы. Внедрите разбор инцидентов без поиска виноватых. Пусть каждый такой разбор порождает новый тест‑кейс или проверку – так MTBF будет расти естественным образом.

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

      6. Создайте дашборд здоровья релиза с 5–6 ключевыми метриками и разместите его на видном месте. Когда команда ежедневно видит показатели вроде Defect Escape Rate и Change Failure Rate, подход к работе меняется сам собой.

      7. Заранее согласуйте SLO и бюджет ошибок: определите, какой уровень сбоев допустим. Это снимет невроз с ориентацией на «ноль багов» и переведёт разговор в плоскость «у нас бюджет на N минут простоя в месяц, тратим его осознанно».

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

      Во сколько обойдётся такой подход?

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

      Посчитайте стоимость одного серьёзного инцидента: 
      простой сервиса помножить на выручку в час + затраты на устранение (время команды и ставки) + потерянные клиенты и нагрузка на поддержку.

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

      управление it рисками

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

      А что если забить и считать баги дальше?

      Имеете полное право. Только давайте честно про то, что вас ждёт.

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

      • Команду настигнет неумолимое выгорание. Постоянные стрессы, конфликты, переработки. Лучшие уйдут первыми – никто не любит героически чинить то, что можно было предотвратить.

      • QA и разработка будут постоянно конфликтовать. KPI по количеству багов противопоставляет их по самой своей природе.

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

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

      • Самое коварное – что по старым метрикам всё будет выглядеть отлично ровно до того момента, пока не станет слишком поздно.

      Когда стоит обратиться к нам?

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

      1. проводим аудит текущего QA: разбираем, как устроено тестирование, где кроются главные риски, какие дефекты попадают в прод и почему. Даём не формальный отчёт, а реальную картину состояния дел;

      2. помогаем перейти на осмысленные метрики: вместо простого подсчёта багов внедряем MTBF, MTTR, Defect Escape Rate, Change Failure Rate, выстраиваем риск‑матрицу и собираем понятный дашборд – такой, который не стыдно показать руководству;

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

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

      ]]>       https://quality-lab.ru/blog/perestante-schitat-bagi-sovremennye-metriki-testirovaniya-dlya-it-komand/ Wed, 01 Jul 2026 18:37:25 +0300       Как мы написали UI-тесты для ИИ-агента внутри JetBrains IDE Оригинальная публикация
      Автор: Nikolay Nedoseykin

      Как проверить, что ИИ-агент в IDE работает, если на одинаковые запросы LLM отвечает по-разному? Ответы модели недетерминированы, а интерфейс и бизнес-логика вполне детерминированы, и их нужно тестировать отдельно.

      Мы делаем ИИ-агента, встраиваемого в JetBrains IDE. В статье расскажу, как мы выстроили UI-автоматизацию плагина так, чтобы тесты ловили регрессии в интерфейсе, бизнес-логике и при этом не «моргали» из-за нестабильности LLM.

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

      1. Выстраивание UI-автоматизации на примере IDE-плагина

      2. Тестирование приложений с ИИ-функциями

      3. Разделение ответственности между детерминированной и недетерминированной частями системы

        ]]> https://software-testing.ru/library/testing/testing-tools/4524-jetbrains-ide Tue, 30 Jun 2026 23:00:00 +0300 Как ИИ нам проверку уязвимостей сломал Сегодня я расскажу историю о том, как ИИ умеет косячить! А то только success-story везде…

        У нас есть автотесты на уязвимости по базе NVD. И вот что-то эти сборки посыпались пачкой. Тестировщик пошел смотреть… И потом рассказал, в чем дело было:


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


        →

        Вот, будьте бдительны)


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


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


        ]]>         http://okiseleva.blogspot.com/2026/06/blog-post_30.html Tue, 30 Jun 2026 16:03:35 +0300         Мутационное тестирование: не только юнит-тесты Автор: Баз Дейкстра (Bas Dijkstra)
        Оригинал статьи
        Перевод: Ольга Алифанова

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

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

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

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

        ]]>         https://software-testing.ru/library/testing/other-testing/4497-mutation-testing Sun, 28 Jun 2026 23:00:00 +0300         Настраиваем IDEA с ИИ, часть 2 С вами рубрика «где тестировщик может применять ИИ в своей работе»!

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



        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):

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


        Чат мне подробно ответил, причем в контексте нагших прошлых бесед подчеркнул, что этот способ сработает в том числе и с Giga IDE, в которой я и работаю. 

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

        окошко открылось слева сверху, а как его вниз перенести?
        Оказалось, достаточно перетащить, хотя я вроде попыталась, но, видимо, плохо захватила в первый раз))




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


        Для теста мне надо было изменить регистр текста. Я знаю, как это делается в Notepad++, но в IDE эта комбинация не работает. Что делать? Искать по менюшкам или спросить чат!


        а как в гига привести текст в верхний или нижний регистр? как контрол + U в нотепад++

        Очень быстро и очень удобно! Если раньше надо было уметь гуглить, то теперь достаточно добавить себе чат с ботом, и все. 

        Мне особенно нравится то, что ему можно делегировать все тупые вопросы, которые ты иначе бы задавала коллегам как новичок "а как это в IDEA сделать? А то?". Теперь для этого есть чатик! 

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

        PS — эта статья написана в помощь студентам моего курса «Применение ChatGPT в тестировании»
        ]]>         http://okiseleva.blogspot.com/2026/06/blog-post_25.html Thu, 25 Jun 2026 20:22:34 +0300         Психология тестировщика: почему критическое мышление — это суперсила

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

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

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

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

        ]]>         https://software-testing.ru/library/testing/general-testing/4523-psychology-of-the-tester Tue, 23 Jun 2026 23:00:00 +0300         ИИ, помоги мне настроить IDE С вами рубрика «где тестировщик может применять ИИ в своей работе»!

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


        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. Что значит ошибка?

        Проект перевели на Java 25, но ещё не обновили доку. Так что я удивилась, увидев ошибку при сборке:

        Dependency requires at least JVM runtime version 25. This build uses a Java 21 JVM.

        Подумала, вдруг что-то не так поняла? Сходила к ИИ:

        При сборке проекта ошибка: 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?


        После шага 3 мне насоветовали команду:

        winget install EclipseAdoptium.Temurin.25.JDK

        Фича крутая, конечно, появилась в винде! Но я засомневалась, а не перезатрет ли мне это параметры в Path? Потому что другой проект собирается на Java 21 и мне нужны обе версии.

        Собака-подозревака снова пошла к ИИ:

        winget install EclipseAdoptium.Temurin.25.JDK — он установит джаву, но не поменяет Path и Java Home? Я хочу чтобы стояла 21 и 25 версия, но Java Home должен смотреть на 21

        И ведь не зря пошла!

        По умолчанию стандартная установка через winget перепишет ваши переменные JAVA_HOME и Path, сделав Java 25 основной в системе. Инсталлятор от Adoptium (MSI-пакет) устроен так, что он автоматически прописывает себя в системные переменные.

        Если вы хотите, чтобы глобальной версией в системе оставалась Java 21, а Java 25 использовалась только точечно (например, внутри Giga IDE/Gradle), у вас есть два отличных пути.

        ... 


        Более того! Так как ИИ-шка запоминает контекст, то после шагов для установки Java чат-бот сам выдал инструкцию «Как потом настроить это в Giga IDE (IntelliJ IDEA)?»

        Как удобно стало в мире с ИИ! ???? 

        ]]>         http://okiseleva.blogspot.com/2026/06/ide.html Mon, 22 Jun 2026 19:54:11 +0300         Типы границ для классов эквивалентности  


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


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

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

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

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

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

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

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

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

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

        Но то, что физически сделать нельзя, часто в программе сделать можно. Например, ввести в количество участников митапа «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 Работа с нестабильными тестами в Allure 3 Михаил Ланкин, автор статей команды ТестОпс
          Оригинальная публикация

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

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

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

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

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

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

          ]]>           https://software-testing.ru/library/testing/testing-automation/4522-allure- Thu, 18 Jun 2026 23:00:00 +0300           Какие задачи в тестировании пора отдать ИИ, чтобы получить результат, а не новые проблемы?

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

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

          407ba4d8-8b43-4dd9-986b-f0ae0b2eee59-Photoroom_11zon-1

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

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

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

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

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

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

          Матрица принятия решения по привлечению ИИ в QA-задачи

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

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

          1 Контроль входных данных Классификация: открытое/внутреннее/персональное. Барьер по 152‑ФЗ. Персональное и закрытую архитектуру – только в локальный контур. ↓ 2 Контроль среды и модели Изолированный контур для чувствительного. Модель — достаточная, а не самая дорогая. Версии модели и формулировок зафиксированы. ↓ 3 Контроль результата Обязательная проверка специалистом. Модель предлагает – человек принимает. Никакого автоприменения в критичных местах. ↓ 4 Контроль в эксплуатации Метрики: доля валидных артефактов, ложные срабатывания, пропущенные дефекты. Отслеживаем деградацию, готовы откатить. ↓ Результат, которому можно доверять

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

          Первый слой проверки – юридический, и его часто недооценивают. Согласно 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% кейсов невалидны – именно на них уходит дополнительное время проверки.

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

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

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

          1. Поддержка автотестов (самовосстановление локаторов), набор – около 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           Как начать тестировать внутренние покупки (In-App Purchases) на Android Автор: Павлович Евгений

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

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

          ]]>           https://software-testing.ru/library/testing/mobile-testing/4520-in-app-purchases Sun, 14 Jun 2026 23:00:00 +0300           Готова ли ваша IT-инфраструктура к внедрению цифрового рубля?

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

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

          Цифровой рубль

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

          Почему стандартного набора проверок для цифрового рубля недостаточно?

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

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

          • Деньги программируемые. С помощью смарт‑контрактов можно заключать самоисполняемые сделки и ограничивать использование средств определёнными целями. Это принципиально новые сценарии, где нужно тестировать не только то, что должно сработать, но и то, что работать не должно.

          • Плотный регуляторный контур. 115‑ФЗ, идентификация через ЕСИА, электронная подпись, банковская тайна, лимиты и обязательное право выбора способа оплаты. Из‑за этого к обычному функциональному тестированию добавляется обязательный этап – комплаенс‑тестирование.

          • Тест‑базис постоянно меняется. платформа развивается, стандарты регулярно обновляются. Ключевые изменения вступают в силу 1 июля 2026 года – буквально накануне дедлайна. То есть вы стабилизируете релиз против движущейся мишени.

          Если коротко: цифровой рубль превращает простую проверку функций в управление расчётными и регуляторными рисками. А это совсем другие объём и глубина тестирования.

          Какие требования ЦБ нужно проверить до запуска цифрового рубля?

          Цифровой рубль требования

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

          Документ Зачем он тестировщику
          «Требования операционно-технологического взаимодействия на платформе цифрового рубля» (актуальная редакция применяется с 01.07.2026) Главный технический контракт интеграции: как ваш контур общается с платформой. Базис интеграционных и сверочных тестов.
          «Альбомы распоряжений и сообщений» Форматы и структура сообщений/распоряжений. Из них растут позитивные, негативные и граничные кейсы для каждого типа операции.
          «Спецификация на программный модуль» Требования к программному модулю участника. Важно для проверки совместимости и корректной обработки операций.
          «Порядок подключения участника платформы» Регламент подключения. Влияет на сценарии онбординга, выдачи доступа, приостановки и возобновления.
          «Требования и рекомендации к пользовательским интерфейсам…» (актуальная версия – с 01.07.2026) Как должны выглядеть и вести себя клиентские экраны операций. Базис для юзабилити- и комплаенс-проверок (включая право выбора способа оплаты).
          «Порядок оценки влияния клиентского приложения на криптографические средства» (опубликован в мае 2026) Прямо касается ИБ-тестирования: клиентское приложение не должно нарушать требования к встроенным СКЗИ.
          Тарифы оператора платформы Нужны для проверки корректности расчёта и удержания комиссий (см. раздел про комплаенс).

          Главный подводный камень – версионирование стандартов. Зафиксируйте в стратегии тестирования, по каким именно редакциям (с какими датами вступления в силу) вы проверяетесь, и предусмотрите перепрогон при их обновлении. Иначе вы пройдёте сертификацию по старой версии, а в прод выйдете уже с новой.

          9 аспектов тестирования при подготовке к внедрению цифрового рубля

          Переход на цифровой рубль

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

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

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

          Методология

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

          2. Для каждого типа операций – будь то C2C, C2B, B2B или возвраты – прописать позитивные, негативные и граничные сценарии. Опираться на альбомы сообщений ЦБ.

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

          4. Отдельно протестировать ситуации, когда операция прерывается на полпути – например, если связь оборвалась между подтверждением и исполнением. В таких случаях нужно чётко понимать, как система обрабатывает «зависшие» деньги.

          Подводные камни и рекомендации

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

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

          • Идемпотентность с точки зрения пользователя. Если человек случайно дважды нажмёт на кнопку, обновит страницу или отправит запрос повторно из‑за таймаута, это не должно приводить к созданию второй операции. Такой сценарий нужно проверять как обычную функциональность, а не только с технической стороны.

          2. Тестирование смарт-контрактов и «окрашенных» средств

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

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

          Методология

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

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

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

          4. Для «окрашенных» средств. Смоделировать попытки использовать их не по назначению. Система должна блокировать любые нецелевые расходы.

          Подводные камни и рекомендации

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

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

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

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

          Здесь обычно и возникают основные сложности. У вас как минимум четыре ключевых шва: ваш контур и платформа ЦБ, ваш контур и НСПК/СБП с универсальным платёжным QR‑кодом, клиентское приложение и ваш бэкенд, а также касса или терминал и эквайринг.

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

          Методология

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

          2. Поднять стенд с управляемой эмуляцией смежных систем (моки/стабы по контракту), чтобы воспроизводить редкие ответы платформы: ошибки, отказы, нестандартные коды, задержки.

          3. Применять контрактное тестирование на стыке версий – чтобы обновление стандарта не ломало интеграцию молча.

          4. Прогонять сценарии «по шву» и сквозные (е2е), отдельно проверяя асинхронные статусы, таймауты, ретраи и идемпотентность.

          5. Для ритейла нужен отдельный блок проверок: взаимодействие кассы, эквайринга, универсального QR‑кода и фискализации чека (ККТ). При оплате цифровым рублём продавец обязан использовать ККТ как обычно, поэтому важно проверять чек и расчёт вместе – как единую цепочку операций.

          Подводные камни и рекомендации

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

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

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

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

          4. Тестирование сверки и расчётов (реконсиляция)

          Этот слой для обычного продукта почти не важен, а для цифрового рубля – критически необходим. Поскольку деньги учитываются в реестре ЦБ, а ваш контур лишь обрабатывает распоряжения, он должен полностью совпадать с реестром оператора. Любое расхождение может привести к тому, что деньги реального клиента окажутся не там, где нужно.

          Методология

          1. Определить контрольные точки сверки: по каждой операции и по итоговым реестрам за период.

          2. Тестировать идемпотентность по сквозному идентификатору операции: убедиться, что повтор запроса не создаёт второй платёж и не задваивает запись.

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

          4. Проверять расхождения намеренно: внести рассинхрон на стенде и убедиться, что он детектируется и поднимает алерт, а не растворяется.

          Подводные камни и рекомендации

          • «У нас же всё прошло» – самообман. Операция может пройти у вас и не дойти до платформы (или наоборот). Без сверки вы узнаете об этом от клиента, а это худший канал обратной связи.

          • Главный кошмар – двойное списание. Сценарии ретраев и параллельных запросов проверяйте до прода, а не после первой жалобы.

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

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

          Этот вопрос особенно актуален для ритейла и электронной коммерции. Когда вы добавляете оплату через универсальный QR‑код и цифровой рубль, приходится вносить изменения в код – причём именно в той части системы, где и так максимальная нагрузка. А если площадка упадёт во время распродажи, это приведёт к прямой потере выручки и удару по репутации.

          Методология

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

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

          3. Совместно с DevOps искать узкие места: БД, очереди, внешние интеграции, фискализация – и проверять их под нагрузкой по отдельности.

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

          Подводные камни и рекомендации

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

          • Простая арифметика для финдиректора. Один час простоя в пик почти всегда стоит дороже годового бюджета на нагрузочное тестирование. Это не запугивание, это сравнение двух чисел.

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

          6. Тестирование информационной безопасности

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

          Методология

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

          2. Оценить влияние клиентского приложения на встроенные криптосредства – по соответствующему стандарту платформы: приложение не должно нарушать требования к СКЗИ.

          3. Проверять целостность смарт-контрактов и права доступа к их запуску – ЦБ прямо называет это приоритетом ИБ.

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

          Подводные камни и рекомендации

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

          • Криптомодуль – это не «чёрный ящик, а часть системы. Важно проверять, как именно ваше приложение взаимодействует с ним, а не просто отмечать факт подключения СКЗИ.

          • ИБ и комплаенс пересекаются. Ряд проверок (идентификация, управление доступом и аудит операций) – находится на их стыке. Не стоит распределять эти задачи между разными командами так, чтобы зона взаимодействия осталась без ответственного.

          7. Комплаенс-тестирование

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

          Методология

          1. Идентификация и доступ: открытие кошелька возможно только после идентификации по 115-ФЗ, при наличии учётной записи в ЕСИА и ключа электронной подписи. Тестируем позитивные и негативные ветки (нет идентификации, нет ЕСИА, невалидная подпись).

          2. Лимиты: на период пилота действует лимит пополнения кошелька физлица – 300 000 ₽ в месяц. Заводим граничные кейсы: 0, ровно лимит, лимит + копейка, исчерпание лимита частями из разных источников.

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

          4. Тарифы: корректность расчёта и удержания комиссий – приём оплаты бизнесом (C2B) по утверждённому тарифу 0,3% от суммы, но не более 1 500 ₽; переводы между юрлицами (B2B) – фиксированно 15 ₽. Проверяем округление, лимит комиссии, кто и сколько платит.

          5. Персональные данные и банковская тайна: режим конфиденциальности операций, корректный отзыв согласия (а не заглушка, которая ставит флаг «удалено», оставляя данные на месте), минимизация собираемых данных – это 152-ФЗ.

          6. Фискализация: при оплате цифровым рублём продавец обязан применять ККТ в обычном порядке – проверяем выдачу корректного чека.

          Подводные камни и рекомендации

          • Цена комплаенс-бага другая. Функциональный дефект стоит репутации и нервов. Комплаенс-ошибка в расчётах цифровым рублём – это предписания, штрафы и вопросы к самой возможности участвовать в платформе. Это блокер, рядом с которым меркнет большинство багов в логике.

          • Функция «Удалить аккаунт» должна действительно удалять. Классическая ловушка: кнопка есть, а данные остаются. Проверяйте поведение системы, а не наличие текста про политику конфиденциальности.

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

          8. Тестирование офлайн-режима

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

          Методология

          1. Главный класс сценариев – защита от двойного списания: одни и те же средства не должны быть потрачены дважды в офлайне до синхронизации.

          2. Тестировать синхронизацию постфактум: восстановление связи, разрешение конфликтов, порядок применения операций.

          3. Проверять граничные состояния устройства: разряд, потеря данных, рассинхрон часов, частичная синхронизация.

          Подводные камни и рекомендации

          • Конфликт синхронизации – норма, а не исключение. Если произошли две офлайн‑операции, а потом обе дошли до системы, результат должен быть предсказуемым. Иначе на кассе возникнет спор с клиентом. 

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

          9. Регрессионное тестирование и автоматизация

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

          Методология

          1. Выделить критический путь расчётов (открытие кошелька, основные типы операций, оплата по QR, возвраты, сверка) и закрыть его автотестами в первую очередь.

          2. Прогонять регресс автоматически на каждом релизе расчётного контура, а не от случая к случаю.

          3. Следите за стабильностью набора тестов: «мигающие» тесты обесценивают весь регресс, потому что им перестают верить.

          4. Привязывать автотесты к версиям стандартов, чтобы при обновлении контракта быстро видеть, что именно поехало.

          Подводные камни и рекомендации

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

          • Автоматизация – это не «нанять джуна на месяц». Для тестирования расчётов под нагрузкой и интеграций нужны проверенные фреймворки и специалисты с опытом их внедрения.

          Итоговая карта рисков перед запуском цифрового рубля

          Технологические процессы участника платформы цифрового рубля

          Чтобы систематизировать всё, что мы рассказали, используйте итоговую таблицу. Её удобно показать на синке с разработчиками и 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           Археология автотестирования: SUnit, прародитель JUnit Михаил Ланкин, автор статей команды ТестОпс
          Оригинальная публикация

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

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

          Мостик между этими двумя мирами — автотесты, они нужны и тестированию, и разработке. Фреймворк JUnit сознательно писали как можно более простым — в первую очередь для того, чтобы сделать его повседневным инструментом для разработчиков. Люди, работавшие с первыми фреймворками автотестирования, стали также авторами подходов экстремального программирования (XP) и разработки через тестирование (TDD) — т. е. подходов, настаивающих на том, что тестирование — это не «обязаловка», а интегральная часть разработки.

          ]]>           https://software-testing.ru/library/testing/testing-automation/4521-sunit Sun, 07 Jun 2026 23:00:00 +0300           Software Engineering Happiness Index 2025  

          "Лучше поздно, чем как тогда"



          В конце 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           Бюджетное тестирование облачных приложений: Testcontainers и LocalStack Автор: Фернандо Тексейра (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 на самом деле

          Тестирование образовательных платформ

          Если вы руководите EdTech‑продуктом, статья даст вам понимание, что и как обязательно нужно тестировать, на каких этапах и какие вопросы задавать своему QA (внутреннему или внешнему). 90% материала посвящено российскому рынку и реалиям, 10% – интересным кейсам от Coursera, Duolingo и других международных компаний.

          В среднестатистической российской онлайн‑школе «всё хорошо с QA» выглядит так: регресс зелёный, баги в Jira закрыты, тестировщик подтвердил готовность релиза. Накатывается новая фича – скажем, новый формат вебинара или групповой проверки домашек. И вот в 19:55 в чате поддержки появляется первое сообщение: «У меня не открывается урок». Через минуту – уже 12 таких сообщений, через пять минут – 200. К 20:15 вебинар так и не запустился: на платформе по‑прежнему белый экран. Начинается суматоха: методист тегает продакта, продакт – CTO, CTO – разработчика, разработчик – тестировщика. Все в панике, но финансовые и репутационные потери уже не исправить.

          Мы много лет помогаем компаниям из мира цифровых образовательных технологий выстраивать QA и не раз сталкивались с историями разного уровня фатальности. Почти всегда проблема не в конкретных тестировщиках, а в самой системе. Дело в том, что EdTech тестируют как обычное веб‑приложение, не учитывая сложность продукта, специфическую нагрузку, особое поведение пользователей и серьезность последствий ошибок. Если бы об этом писали в учебниках для джунов, мы бы не разгребали ситуации, где школа на 10 тысяч активных учеников живёт без автотестов, а единственный QA – методист, который тестирует как может в свободное от основной работы время (невыдуманные истории из практики коллег, увы).

          Чем EdTech отличается от «просто веба» с точки зрения тестирования?

          Когда говоришь собственникам: «У вас не просто сайт с курсами, видео и оплатой», – они всегда смотрят с легким недоумением, искренне не понимая, зачем выделять отдельный QA‑подход для EdTech. Но на это есть 5 веских причин.

          1. Нагрузка в EdTech неравномерная. У обычного интернет‑магазина пиковые часы – это, условно, вечер и выходные, с предсказуемым ростом в дни акций. У EdTech пик приходится на конкретные даты и время. К примеру, 19:00 МСК, понедельник, старт вебинара – на платформе одновременно оказываются 8 000 пользователей. К 19:01 их уже 11 000, к 19:03 – 14 000, и треть из них видит сообщение «Ой, что‑то пошло не так». Это не просто высокая нагрузка, а резкий удар. Если вы не тестируете систему именно так – с пиковыми всплесками и стремительным нарастанием числа пользователей, – вы не проверяете нагрузку по‑настоящему.

          2. Особенная аудитория c нестандартным поведением, к тому же, довольно часто далёкая от IT. В большинстве школ это: родители школьников (нервничают); сами школьники (легко отвлекаются); взрослые, проходящие переквалификацию (стесняются обращаться в поддержку и просто уходят). Любая ошибка здесь – не просто запись в системе отслеживания багов, а фраза «Всё тупит, я не буду здесь заниматься». Конверсия в обучение – критически важная метрика, и страдает она не из‑за громких сбоев, а из‑за банальных проблем с юзабилити. Поэтому тестировать пользовательский интерфейс в современных образовательных технологиях нужно обязательно.

          3. EdTech‑продукт – это целая экосистема: лендинг, личные кабинеты ученика и родителя, кабинеты методиста и преподавателя, админ‑панель, CRM, биллинг, интеграции с эквайрингом, мессенджерами и видеоплатформой, мобильное приложение, иногда desktop‑плеер для скачанных уроков или даже отдельный класс с интерактивной доской. Всё это должно работать без сбоев. Стандартное функциональное тестирование веб‑приложения здесь не поможет, так как у вас не одно приложение, а сложная взаимосвязанная система.

          4. Контент – это часть продукта. В обычном SaaS пользователь сам вводит данные, и QA их не затрагивает. В EdTech контент – это база: видео, тексты, тесты, интерактивные задания и тренажёры. Каждый новый курс – это новый набор данных, который должен корректно отображаться, воспроизводиться и оцениваться. Когда методисты сообщают: «Мы загрузили 12 модулей нового курса», – для QA это сигнал к регрессионному тестированию. Например, в одном из модулей может оказаться видео с нестандартной кодировкой, которое не загрузится на старом Android‑планшете.

          5. Цена ошибки в 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 секунды – из‑за этого пользователь не понимал, что говорит лектор.

          Тестирование EdTech проектов

          Совет для 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 приложений

          Доля мобильного трафика1 в российских 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 EdTech проектов

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

          • Реализацию права на удаление данных. Может ли пользователь или родитель запросить удаление информации? Что именно удаляется, а что сохраняется по закону – например, данные в логах биллинга должны оставаться.

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

          • Контроль доступов внутри платформы. Например, может ли преподаватель курса А получить доступ к данным ученика из курса B, к которому не имеет отношения? Тест на «горизонтальную эскалацию прав» обязателен: он выявляет риски несанкционированного доступа.

          • Важно проверить безопасность для неавторизованных пользователей. Может ли гость по прямой ссылке открыть чужой урок, профиль или переписку в чате? Такие уязвимости нередко встречаются – хотя их редко ищут целенаправленно.

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

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

          Контур №6. Интерфейс глазами ученика, а не разработчика

          QA EdTech проектов

          В 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-подрядчику?

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

          1. Покажите 2–3 реальных кейса с EdTech-продуктами или платформами с похожим профилем нагрузки. Без названий, под NDA – нормально, но цифры и подходы должны быть.

          2. Какой у вас типовой подход к нагрузочному тестированию EdTech? Какие инструменты используете? Какие профили проектируете?

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

            4. <]]> 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 Полезные навыки тестировщиков, юз-кейсы внедрения ИИ и TestContainers, принципы и инструкции для успешной автоматизации, и многое другое: самые интересные новости тестирования за февраль-май 2026 Опубликован выпуск рассылки за декабрь-январь.

            В выпуске собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов.

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

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

            ]]>             https://software-testing.ru/news/4525-mail-may Thu, 28 May 2026 15:14:35 +0300             Штат, гибрид или аутсорс тестирования: честный разбор экономики QA-команд в 2026

            Аутсорс тестирования

            Это не рекламный текст. Здесь чистая математика. Передо мной не стоит задачи уговорить вас выбрать аутсорс и подписать с нами договор до конца квартала. Мне важно, чтобы вы оценили свою внутреннюю экономику с открытыми глазами, а не «потому что все так делают» или «в интернете написано». В конце статьи я прикрепил калькулятор, где можно посчитать реальные затраты на 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 Как нагрузочное тестирование защищает бизнес от убытков?

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

            Почему мы это написали или история про маркетолога

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

            Frame-633_11zon

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

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

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

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

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

            Что на самом деле происходит под нагрузкой?

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

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

            Автор: Парвин Хан (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 Как ускорить автотесты на Python в Pytest в 8,5 раз Автор: Анатолий Бобунов

              Меня зовут Анатолий Бобунов, я работаю 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               10 мощных тестов с Chrome DevTools Автор: Кастури Раджаманиккам (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‑аудита сайта розничной торговли автозапчастями. Задача была в том, чтобы посмотреть на сайт глазами обычного покупателя: сможет ли он найти нужный товар, поймёт ли, как оформить заказ, не уйдёт ли к конкурентам?.

              Особенности 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               Первый месяц в Bug Bounty: итоги, цифры и выученные уроки Оригинальная публикация

              Мой путь в ИБ начался с нуля - у меня не было опыта работы и образования в айти в целом, будь это системное администрирование или программирование. Я просто планомерно учился и сдавал сертификации. За три года у меня собрался определенный стек: 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: вроде красиво, а летит ли – непонятно.

              Юзабилити‑тестирование

              Шесть вопросов, на которые отвечает юзабилити‑тест

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

              2. Эффективный? Сколько кликов и минут уходит на цель? Сколько из них лишние? Каждое лишнее действие – упущенная конверсия.

              3. Понятный? Нужна ли инструкция, чтобы пользоваться? Если да – у нас плохие новости.

              4. Без ошибок пользователя? Не функциональные баги, а – может ли человек сам ошибиться и насколько легко это исправить?

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

              6. Приносит удовлетворённость? Хочется ли возвращаться?

              Не можете уверенно ответить «да» на каждый из шести по своему продукту – садитесь, читаем дальше.

              Подготовка: пять шагов, без которых юзабилити‑тест превратится в шапито

              Ставим цели

              Самый главный шаг и самый игнорируемый, к сожалению. Без чёткой цели тест превращается в «давайте посмотрим, что не так». Цель всегда привязана к стейкхолдеру: маркетинг хочет конверсии, поддержка – снижения тикетов «как это сделать?», продакт – отстройки от конкурента, юристы – соответствия 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‑исследователя. По каждой из методик: суть, когда и для чего применять, что для этого нужно, какого результата ожидать.

              Превью Юзабилити‑тестирование 20 методик

              Заполните форму, и мы отправим документ вам на электронную почту.

              Проведение: от подготовки до сбора данных

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

              Прогоните первый тест на близком к ЦА пользователе (не на дизайнерах или маркетологах, которые знают продукт). Ведите себя как с настоящим участником: никаких «ой, это просто тест», не делайте подсказок. Запишите пилот на аудио или видео. Пересмотрев, вы внезапно можете обнаружить, что половину времени перебивали или формулировали задачи невнятно. Сделайте работу над ошибками.

              Приступайте к работе в реальных условиях

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

              Во время сессии:

              • Запись (с разрешения) – всегда.

              • Заметки по ходу – 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               Внедряем Testcontainers за два дня или как перестать бояться рефакторинга и начать доверять своим тестам Автор: Леонид Сухин

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

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

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

              Дальше - больше. Множество зеленых галочек, появляющееся на экране при запуске тестов, не могло не радовать. Но вот ты решаешь сделать минимальный рефакторинг, оптимизировать какой-то метод. В этот момент все разваливается на куски. Куча красных тестов! Как, почему? Да просто во внутренней реализации ты перешел на использование другого метода, добавил в метод еще один параметр или что-то подобное. В результате куча тестов перестала работать. И теперь, поменяв одну строчку в процессе рефакторинга, надо поменять еще 30 строк в тестах. В какой-то момент начинаешь ловить себя на мысли - “Ни в коем случае, никаких рефакторингов больше!”

              ]]>               https://software-testing.ru/library/testing/testing-automation/4515-testcontainers- Tue, 28 Apr 2026 23:00:00 +0300               TechWriter Days 3. Как это было  


              27-28 марта в Москве прошла 3-я конференция для технических писателей — TechWriter Days 3.

              Сайт конференции — https://techwriterdays.ru/.

              Программа — https://techwriterdays.ru/ru/program/137253


              «Я там был, мед, пиво пил» © И хочу поделиться с вами. Конференция отпочковалась от конференции аналитиков, так как тех писы уже — дело стандартное, есть отдельные должности под них.

              А я сама в свое время и аналитиком на проектах была, да и с документацией работала постоянно, потому что я — бюрократ ))) Так что очень интересно было посетить эту конференцию.

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


              Мой список "посмотреть потом"

              1. Тихая эпидемия в IT, или Почему выгорают технические писатели — плохо себя чуствовала, не осталась на последние доклады, ушла домой. Но исходно ставила галочку сходить на доклад. Полистала слайды — интересно и жизненно, особенно про команды, где твою роль не понимают. Хотя это история про выгорание, а хотелось бы "что делать в такой команде", но тоже интересно)
              2. Использование стилей MS Word без страха — тут обещают реальные кейсы из жизни, я такое люблю)
              3. Внутреннее продвижение базы знаний: от справочника до культуры работы с информацией — внутреннее продвижение тоже очень актуальная тема!
              4. Документация как продукт: от текстов к стратегии и управлению опытом — документация как отдельный продукт, в том числе улучшаюший онбординг. Это прям откликает мне, я сама делала онбординг))
              5. Отчеты и метрики в документации: как считать влияние на бизнес — всегда интересно, кому какие метрики зашли


              Какие доклады я слушала


              Кому доверить ревью API — техпису или искусственному интеллекту. Камила Мазаева

              Ссылка на доклад

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

              Аналитик → техпис → разработка

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

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

              • уровень критичности
              • где проблема?
              • как написать лучше
              И человек уже принимает или отклоняет такие правки. В итоге аналитик открывает чат с ботом, куда уже внесен нужный промт → дал документацию, получил фидбек. Красота!

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

              И, конечно, нужно помнить, что сердце ИИ — хороший промт!





              Через тернии к звездам: как мы перевезли всю документацию Яндекса на Diplodoc. Эльвира Гильманова и Михаил Кошкин


              Довольно интересный рассказ о переезде документации с одной платформы на другую. Переезд занял 5 лет! ????

              Раньше жили на DITA, которая выглядела как документация из 2000-х годов, перешли на YFM.
              Всякое бывало, что-то предусмотрели, а что-то — нет.


              Были и косяки — нужно было объединить документацию. Посмотрели, она написана на разных платформах, провели диагностику, какая лучше, выбрали... DITA. И через месяц узнали, что все пеередут в YFM.


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

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



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


              Ребята работают по ГОСТ — а это часто не про «написать документацию», а про коммуникации, про «правильную» структуру документа.

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

              В итоге раньше переименовали какое-то название — это надо открыть ворд, ctrl + f, поиск, замена... А если разные падежи, оно ещё и не работает! Что сделали? Единый банк переменных.


              Ну и не только его, конечно)) В итоге что получили? Приходит заказчик:

              — Ой, а давайте всё же систему именовать не АС "Документирование", а АС "Техпис"

              Раньше такие просьбы за неделю до сдачи проекта вызывали желание выйти в окно, а теперь "да легко"




              Масштаб, сложность, автоматизация: как агенты изменили процесс документирования в Yandex Cloud. Александр Яковлев

              Ссылка на доклад

              Александр рассказал про их опыт внедрения ИИ. Какие инструменты использовали:


              Методом проб и ошибок пришли к таким выводам:

              • агент не работает с гитом, не пушит сам — иначе он такого напушит, что только всё испортит
              • тестирование документации тоже на людях — ИИ бы справился, но это хорошее время для ревью.
              Что входит в настройку агента:
              • системный промт
              • режим
              • фоновые знания
              Где в итоге агент может реально приносить пользу?
              1. Создание структурированной информации — пошаговые инструкции, обзорные статьи
              2. Обновление существующей документации на основе тикетов, скринов, истории изменений
              3. Подготовка Release Notes
              4. Анализ актуальности документации из истории изменений и релизов инструментов.
              Был кейс — уволился человек, который отвечал за несколько проектов. Попросили ИИ проанализировать документацию на основании как раз таки истории изменений. Да, это заняло 1.5 млн токенов, но был вау-результат и найдено много проблем в доке.


              Changelog на лету: автоматическая генерация с помощью GitLab. Татьяна Кириллова


              В чем разница между RN и CL?
              • Release Notes — документация для пользователей
              • Changelog — для разработчиков, что вообще и где менялось.
              Так вот. Схема до автоматизации, техпис собирает change log сам:


              Неприкольно! И трудозатратно. Поэтому описали критерии "что хотим от автоматизации", погуглили инструменты и сравнили по своим критериям:



              Простой подход, но зато выбор становится очевиден!

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

              В итоге:
              • пока проводят ревизию сообщений
              • планируют прикрутить автоматическое соглашение
              Ну и закрепили структуру сообщения:
              • Номер задачи — обязательно
              • Тип — fix, new...
              • Описание 
              • Тело (необязательное)
              Пока обкатывают, впереди ещё долгий путь)


              Матрица зрелости процессов работы с текстом в ИТ. Анна Терновая



              Зачем вообще нужна матрица зрелости? Есть несколько разных причин:


              Анна рассказала про то:
              • Какую литературу использовали при изучении темы
              • Какую матрицу выбрали себе
              Главная фишка — делить каждую колонку на "наших и ваших", команду разработки и команду документирования. Потому что уровни зрелости могут быть разные и повлиять на чужую команду вы можете не всегда.

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

              Так что нужно заручиться поддержкой одной из команд, а потом история успеха будет продвигать вас сама =)



              Подготовка к документированию: читаем ТЗ, собираем информацию. Софья Новикова


              Софья рассказывала, как собирать информацию из разных источников:


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


              В общем, если информации у вас мало, учитесь её собирать из разных мест, в том числе у коллег. База? База, но о ней надо помнить.


              Документация как зеркало продукта: роль технических писателей в улучшении пользовательского опыта. Эльвира Дёгтева


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


              Кейсы из жизни — это всегда интересно. И тут как раз кейсы из серии "пройти мимо, сделав вид, что всё ок, не моя же зона ответственности", или начать копать... И копать... И копать))) Интересные истории!


              Трансфер знаний от уходящих сотрудников. Denis Mazin


              Тут интересная история — каким-то образом ребята выявили, что 18% сотрудников в зоне риска ухода. И надо бы передать их знания, пока они не пропали...

              Накидали такую матрицу:


              Запланировали передачу знаний и понеслось... Сначала сотрудникам некогда этим заниматься. Благо начальство поддержало и поставило высокий приоритет задаче. Но всё равно работу тоже надо работать.

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


              Матрица итеративного редактирования. Анна Штольц 


              Редакторы постоянно сталкиваются со сжатыми сроками. Дают текст на 250 стр и говорят, что есть полчаса. Что делать?

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

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



              Выделили такие этапы:
              1. Корректура — почти на автомате, всякие опечатки (странно, что не передали это ИИ)
              2. Литературная правка
              3. Выравнивание стиля — много жаргона? Это плохо.
              4. Фактчекинг — названия, имена, даты, логика повествования
              5. Отделка
              Интересно было посмотреть со стороны, как преображается текст, так как Анна показывала все на конкретном примере, а в итоге «до — после». 


              Уровни качества документирования. Оксана Гаврюшенко


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

              Так что ребята сделали разную градацию — что нужно? Одноразовая работа? Чтобы документация потом жила? Должна ли соответствовать ГОСТ? И прочее. Всё это влияет на сроки и стоимость. И главное, что надо научиться понимать — разницу между желаемым и достаточным.



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


              Декомпозиция страха: практики взаимопонимания для руководителей и команд техписателей. Мария Макеева



              Каюсь, на этот доклад я залетела случайно. Исходно собиралась в секцию 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             Мои 12 недель в году. Часть 33 (вышла книга по SQL, закончила книгу про ИИ)

            Первый опыт, второй, 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 статья на Хабр

            С книгой новой чуток продолбалась, а вот курс отложила не по своей вине. Там огромная боль, но об этом чуть ниже... 

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

            Кратко что сделала:

            1. Книга 4, SQL: 
              1. прошли верстку!
              2. книга уже вышла в продажу!
            2. Книга 5, ChatGPT:
              1. закончила книгу! 
              2. вычитала её, от души наредактировав
              3. принимаю картинки, пока ещё не все готовы
            3. Курс по автоматизации в Postman:
              1. Записала ещё пару уроков, обработала
              2. Поставила на паузу, потому что в Postman обновилось всё, и сниппеты, и документация ＼(〇_ｏ)／
            4. Статьи на Хабр — 1 статья 
            5. Пополнила свой youtube-канал — 1 видео 
            6. Инструменты 12 недель — продолжаю вести файлик DONE, это все еще очень круто
            7. Новый год! 
            8. Новогодняя фотосессия )))
            9. Две госпитализации у младшей дочери (плановые, гемангиома)
            10. Записалась в зал, начала заниматься ????

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


            Книга 4: SQL

            В прошлом цикле я книгу прошла редактуру, но верстка только началась. В декабре мы закончили верстку, встали в очередь в типографию и книга уже даже успела выйти в продажу! И всё за один цикл! ＼(〇_ｏ)／

            Кайф =)))



            Книга 5: ChatGPT


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

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

            Обещание «быть умнее» я сдержала! Картинки жду, сама стала перечитывать книгу. Оказалось, это прям реально хороший план! Хоть книгу про ИИ я написала меньше, чем за год, вернуться к старому тексту это как в программировании:

            — Кто эту фигню написал?! Ой, это был я...

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

            В общем, что-то местами поменяла, что-то переписала, что-то удалила, что-то пополнила... Работы получилось много! Но! Я всё сделала за один цикл!!

            Есть и грустная новость — книга всё ещё не сдана. И тут дежавю уже не работает... Год назад я ждала до марта, но в марте мы всё сдали. А сейчас почти апрель, обе ещё работают...

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

            В общем, обсудили с издательством, мне дали добро на использование картинок с ИИ. Так что следующая книга будет уже с моим авторством изображений =))) Ну, процентов на 70-90, я думаю, что художницам тоже что-то оставлю...

            Единственная беда — сама по себе нано банана стоит как крыло самолета (около 25к за год), вроде как дешевле взять чат с её функцией, но какой? Пока изучаю тему... Если есть что посоветовать, я вся внимание =) 

            Ну а статус книги — закончила, уже всё вычитала и причесала, жду художниц! В следующем цикле то точно дождусь (или уже в этой книге заменю на ИИ ????)


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


            Итак, к февралю я уже подразгреблась с 5-ой книгой и стала свободна. А зачем время терять? Занялась следующим проектом. Очень уж хочется мне книгу про тайм-менеджмент написать, про свой опыт 12 недель)))

            Я пока прикинула такое содержание — 3 части книги:
            1. Вводная, что это такое и всякое общее (мотивация и тд)
            2. Техники, которые мне НЕ зашли (но могут зайти другим)
            3. Техники, которые мне зашли и уже 9 лет со мной!
            Примерные главы:



            Я прошлась по всем своим постам из цикла 12 недель и насобирала «мяса», раскидав текст по разным главам. Теперь осталось его переосмыслить, дополнить, и будет красота!

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

            Но вообще план на год — написать 2 книги, и это помимо книги про ИИ, потому что её я дописала в январе. Посмотрим, смогу ли!


            Курсы



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

            У меня был план перезаписать курс по автоматизации в Postman. 

            Прошлый результат — 9 уроков готовы, 10-ый записан, в обработке.
            Текущий — 11 уроков готовы.

            Причем 11 уроков я доделала ещё в январе, 29 числа всё сделала. Радостная такая была, осталось всего 3 урока! А дальше можно и цену поднять, ведь курс обновлен!

            А потом... Потом постман обновился. Причем не как раньше, чуток. Не-е-е-е-т... Они:

            1. Кардинально изменили внешний вид и структуру документации. А я ведь учу изучать документацию... Я ведь в уроках показываю "вот пошли в доку, читаем там...". И все эти уроки разом устарели... 10 лет! Документация менялась, но не кардинально... И вот сейчас (((

            2. Судя по примерам в новой документации, изменен стиль автотестов. То есть код надо писать чуть-чуть по-другому. Это мне тоже непонятно, ведь столько автотестов уже написано, зачем их "ломать"?

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

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

            Плюс в марте вышли новые изменения в «что платно, что бесплатно», поэтому с февраля у меня обновление курса на паузе. Я жду, когда все перетурбации закончатся, чтобы... Дописать 3 урока и переписать всё, что снова устарело (((

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

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

            Конечно, всё было не зря. Я ОЧЕНЬ много всего изменила в курсе. Где-то добавила доп. материалов, где-то обновила домашние задания... Так что не всё в мусор, но демотивация была сильнейшая. 

            Ну, чтож... Бывает...



            Остальные курсы

            По остальным курсам мелкие правки по замечаниям от студентов чуток правим описание ДЗ или теста.

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


            Хабр

            Одна статья, всё по плану =))) Есть идеи на новые, но пока руки не дошли...



            Блог

            В блог я стала выписывать примеры использования ИИ:


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


            Не очень много, надо бы исправиться, в первую очередь в статьях на Хабр. Я попробую сделать чуть больше!



            Ютуб / ВК


            Тоже грустновато, всего 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             Эльба: ну вы там как-нибудь сами проверьте, где ошибка произошла Продолжаю рассказывать про «да такого не бывает» в наши дни. У ИП подошел срок платить страховые взносы. У меня вся бухгалтерия в Эльба.Контур, которая и выставила мне задачку.

            Зашла в эльбу, прокликала задачу до "выставить счет в банке", и тут она мне выдает ошибку — не настроена связь с банком о_О

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

            Восстановила соединение с банком и тут же написала в поддержку. Мой исходный вопрос был предельно простой, как быстро Эльба всё подсосет:

            - У меня была разорвана связь с банком, сейчас восстановила — Интеграция 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             1 тест = 1 проверка. Чем хорош принцип атомарности в автотестах в Postman  


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

            Принцип атомарности (объект или операцию нельзя разделить на части, не нарушив их целостность или смысл) применяется в как в разработке кода ПО, так и в разработке кода автотестов.

            И в автотестах 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 то веке:
            1. цикл «Code and Fix» не существуется, у всех Agile или аналоги (ну да, ну да...);
            2. глупых багов типа перехода через новый год или смены часовых поясов, уже давно нет, их решения «вшиты» в библиотеки кода (ага, щаз)
            3. нет проблем «сделали в последние дни, из-за чего огребли проблемы»;
            4. нет проблем с документацией;
            5. ...
            Поэтому я рассказываю актуальные истории таких проблем, которых вроде как в 2026 году и быть то не должно... У меня их даже поднакопилось, но... Не записал сразу = забыл ))) Буду постепенно рассказывать тогда.

            Сегодня я расскажу про АУСН. Сначала короткий рассказ, что это такое, а потом про текущую ситуацию с ним (и проблемы...)



            Что такое УСН и АУСН

            Это налоговые ставки для ИП или малого бизнеса. Когда вы работаете в штате, за вас налоги платит работодатель. А если вы открываете юр. лицо, нужно будет платить самому. Зачем?

            Несколько причин открыть ИП (хотя сейчас есть альтернатива — самозанятый, раньше не было):
            1. Работать как ИП на компанию (или несколько разных) — некоторые компании берут только ИП, или наоборот, не берут тех, у кого есть ИП. 
            2. Работать на второй работе — на одной трудоустроены, остальное как ИП. Так, например, я с издательством сотрудничаю как ИП и на него получаю гонорар с проданных книг. Так проще и дешевле платить налоги, чем как физику.
            3. Получать официальную прибыль — например, за сдачу квартиры в аренду, чтобы не как физик декларации заполнять, а просто честно платить налог с ИП. 
            4. Ну и просто работать на себя, но если вы это планируете, то и так всё знаете ????
            Открывая ИП (или ООО, или ещё что-то), вам надо выбрать налоговую ставку. По сути раньше были основные варианты:
            • УСН — упрощенный налог, платишь 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