Тест зелёный, а фича сломана — потому что проверка смотрит на форму, а не на эффект: имя поля в файле есть, а в разметку оно не попало. Семь таких случаев из живого проекта на TypeScript и PostgreSQL: колесо мыши, которое убил мой собственный CSS-фикс и диагностика, проверившая defaultPrevented вместо прокрутки; подстрока, совпавшая с другой подстрокой; комментарий в SQL, прочитанный как код; метка источника, из-за которой отчёт показывал ноль и этот ноль читался как «людей нет». С кодом, разбором каждой ошибки и числами мутационного прогона на 13 400 мутантов.

Привет, меня зовут Артем Русов. Я автор курсов и образовательных материалов для тестировщиков. Сегодня первое сентября, и это удобный повод подвести итог одной работы.

С февраля я собираю курсы по тестированию, устроенные как игра: Древняя Греция для REST API, Древний Египет для GraphQL, город Цифроград для основ компьютерной грамотности. Сюжет, персонаж-проводник, задания в декорациях мира.

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

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

Когда 180 тестов каждый раз проходят форму входа, авторизация начинает съедать десятки минут и ломаться на рейт‑лимитах, SSO и редиректах. Разберём рабочую схему: получить токен по API, закэшировать состояние и передать его браузеру до старта приложения.

Merge queue гоняет полный сьют один раз на каждый пул-реквест в группе. Четверо ждут посадки — четыре полных прогона, причём последний из них уже содержит три остальных. Обязаны ли те три прогоняться? Мы построили одноразовый стенд, прогнали на нём четыре способа останавливать лишние прогоны и померили каждый: один сажает сломанный код, один залипает намертво, один безопасен и стоит ровно столько же, сколько мы платим сейчас. Четвёртый — наш, и он экономит около 19 машинных минут на посаженный пул-реквест ценой примерно четырёх минут ожидания.

ИИ-агент способен пройти путь от анализа задачи до создания и запуска сценария в Vanessa Automation. Но практический результат зависит не столько от выбранной модели, сколько от качества тест-плана, ограничений для агента и организации всей цепочки.

Вводный вебинар предварял стартующий 1 сентября 2026 года курс «Автоматизированное тестирование в 1С». Его провел ведущий разработчик ИТ-лаборатории Инфостарта и автор курса Александр Кунташов. Эксперт показал, как с помощью ИИ и Vanessa Automation пройти путь от исходной инструкции до работающего автотеста, а затем отдельно разобрал вопросы участников о безопасности данных, MCP, сопровождении сценариев и интеграции с CI/CD...

Четвёртая часть цикла про TDCV2 — открытый конструктор тестовых данных, который я пишу сам.

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

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

1C Extension Auditor — инструмент для анализа совместимости расширений 1С после обновления типовой конфигурации.

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

Также рассказываю, чем Auditor отличается от 1C Extension Checker 2.0 и как эти инструменты могут использоваться вместе.

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

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

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

Для предварительной проверки таких ситуаций мы разработали 1C Extension Checker 2.0 — самостоятельную внешнюю обработку, которая помогает проверить подключённые расширения и зафиксировать обнаруженные проблемы в едином протоколе.

Последние месяцы я рецензирую научный софт для JOSS, Journal of Open Source Software. Это настоящий рецензируемый журнал с редколлегией, только статья в нём короткая, около тысячи слов, а главный объект ревью - репозиторий с кодом. Ревью идёт в публичном GitHub-треде под именем рецензента, и весь процесс от заявки до вердикта открыт любому желающему. Я инженер, не учёный: ни PhD, ни публикационного списка у меня нет.

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

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

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

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

Эта статья о том, как встроить регрессию в Scrum так, чтобы она работала весь спринт. Разберём анализ влияния до разработки, наборы проверок P0-P3, тестовую пирамиду, flaky tests, тестовые данные, проверки после релиза и решение о выпуске с понятным остаточным риском.