Тестирование IT-систем *

Меня зовут Игорь Симаков, я тимлид, руковожу двумя командами. Это две классические продуктовые команды, в которых есть все, кто нужен для полного цикла разработки, от discovery до delivery. Сам я бэкенд-разработчик с десятилетним опытом и не пишу код руками с марта 2026 года. Потом я внедрил в командах практики и перевел всех ребят на агентскую разработку: и QA, и бэкенд, и фронтенд. Так что мои команды уже полгода не пишут код руками

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

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

При проверке десяти статей Haiku совместила PASS и замечание major. Разобрали отчет по исходникам: что исправили, что отклонили и какого контекста не хватило самой модели.

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

Компания по ремонту и отделке квартир в Москве дала мне пять рабочих смет. По ним система выдала 310 замечаний (прогоны 16–21.08.2026). Самая дорогая находка — общий итог одной сметы занижен на 515 786 ₽. Это занижение нашлось ещё при обследовании смет перед ТЗ, а правило под него я написал потом, так что здесь заслуга внимательного чтения, а не кода. Код интереснее другим: 51 подтверждённое замечание он выдал сверх эталонного списка ошибок, составленного при том обследовании. В списке их не было.

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

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

Я собрал конвейер «ТЗ → канонизация → тест‑дизайн → прогон» из 58 специализированных блоков с гейтами доверия: каждый критерий приёмки заземляется цитатой из исходника, серые зоны превращаются в вопросы, а не в угаданную конкретику, повторы бесплатны за счёт кэша. Проверил на синтетическом ТЗ с заложенными болезнями: 9 ловушек из 10 поймал автомат, десятую — человек с вопросником от машины; 26 вопросов стейкхолдерам за 90 секунд, 20 серых зон, 37 BDD‑сценариев за 26 минут. Где платформа врёт и что не доработано — тоже в тексте.

Автор форка Pii-Mask добавил исправления и тесты обработки Word и Excel. На нашей версии 13 его тестов не прошли. Покажу один найденный пропуск и расскажу, как взаимный перенос тестов помог подготовить план исправлений и сохранить улучшения обеих веток.

Репетитора не нанимают по резюме. Ему дают тетрадь реального ученика и смотрят не на то, знает ли он ответ, а на то, где он остановится. Подскажет, в какой строке ошибка, или перепишет задачу за ученика? Скажет «не знаю, давай проверим» или уверенно додумает?

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

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

Хабы: Программирование, Разработка, Управление разработкой
Теги: надёжность, архитектура, спецификация, программирование, управление разработкой

Это первый из трёх постов серии «Надёжное программирование: от кода к технологии». В нём — главный тезис и три столпа. Во втором разберём оракульное смещение и эмпирику DORA, Veracode и FormAI-v2. В третьем — конечного аудитора, шкалу L0–L4 и практические рекомендации.

Сколько сообщений в секунду выдерживает MQTT‑брокер? Без описания нагрузки этот вопрос почти ничего не говорит. Приём сообщений от множества устройств, доставка одного сообщения тысяче подписчиков и обслуживание сотен тысяч соединений нагружают сервер по‑разному.

Я сравнил Mosquitto, EMQX, FlashMQ, HiveMQ Community Edition и XMQ на одном AWS‑стенде. Меня интересовали доставленная скорость, задержка и потребление CPU и памяти, а также то, что происходит, когда брокер не успевает за заданной нагрузкой.

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

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

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

Или все-таки ПО в кризисе?

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

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

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

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

В прошлой статье («Тестируем программы для вскрытия биткойн-головоломок») я сравнивал программы, которые ищут перебором ключ по адресу. Но у части головоломок (номера, кратные пяти: 135, 140, 145, …) публичный ключ уже раскрыт в блокчейне, и для них работают совсем другие алгоритмы: алгоритм кенгуру Полларда и BSGS. Поговорим об этих алгоритмах и программах, их реализующих.

Всем привет! Меня зовут Костя, я QA-инженер в Банки.ру. Общение с агентом у меня давно стало обыденным делом. И в какой-то момент я заметил, что работа тестировщика превратилась в ежедневное объяснение ему одного и того же: «прочти задачу», «составь критерии приёмки», «сделай баг-репорт», «сделай отчёт за сегодня».

Готовых QA-скиллов под мой стек на find-skills не нашлось, поэтому я собрал свои: 10 скиллов для Claude Code — от критериев приёмки и деплоя до логов, баг-репортов, тест-кейсов в Allure и отчёта. Каждую ошибку агента я превращаю в правило внутри скилла. В статье рассказал, как устроен этот QA-конвейер, где агенту нужны мои апрувы, и опубликовал скиллы в открытый репозиторий.

Документ провёлся. Ошибок в коде нет. Тест зелёный.

Открываю оборотно-сальдовую ведомость по 19-му счёту — и вижу, что часть НДС оказалась на 91-м. С точки зрения программы операция завершилась успешно. С точки зрения бухгалтера учёт уже разъехался.

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

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

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

Такими руками стал NeuroReview — автоматический ревьюер пул-реквестов, который работает в продакшене и находит часть дефектов до человеческого ревью или мержа. Мы используем его только на внутреннем коде, подключение добровольное. Сейчас каждый день через него проходит примерно 4 тысячи пул-реквестов — около 40% от всех созданных разработчиками в Аркадии, монорепозитории Яндекса. 

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

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

С комментариями Гейдара Габриэлянца, автора и преподавателя курса «HighLoad-тестирование для 1С и корпоративных систем», разбираем, какие компетенции для этого понадобятся и как меняются задачи по мере профессионального роста.

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

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