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

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

Уже больше полутора лет я пишу автотесты на Go. За это время мы прошли путь от «зачем вообще тестировать на Go?» до «почему мы не сделали это раньше?».

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

Привет, Хабр!

Разберём один интересный инструмент для создания CV — простой, полностью бесплатный и без VPN.

Но просто обзором не ограничимся: соберём полноценное резюме с нуля. Чьё именно — оставлю интригой 🙂

Посмотрим, что из этого получится.

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

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

Нам в Иви "повезло" оказаться именно в такой ситуации. Поэтому делимся своим кейсом по тестированию и обновлению SEO-сервиса — без пафоса, с шишками, метриками и выводами, которые реально помогут.

Когда речь заходит про автотесты, первыми на ум приходят проверки для UI, API или для мобильных устройств. Однако автотесты нужны не только для проверки пользовательских сценариев. Они могут решать и менее очевидные, но не менее важные задачи, например проверять работу пайплайнов. Если одни и те же пайплайны используют сотни сервисов и библиотек, любая ошибка в них быстро выходит за пределы одного проекта. У многих команд одновременно могут сломаться сборки, релизы и привычный процесс разработки. В нашем случае такие пайплайны работали примерно для 700 сервисов и более 200 библиотечных репозиториев. Чтобы гарантировать работоспособность пайплайнов, мы пришли к идее покрытия их автотестами.

В статье я расскажу, как мы в Ozon покрывали тестами работу пайплайнов в GitLab CI, какие требования нужно было учесть и как в итоге были устроены end-to-end-тесты для таких сценариев.

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

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

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

Задача была простая: протестировать два веб-приложения перед деплоем. Next.js-портфолио и SaaS-чат — accessibility, консольные ошибки, отзывчивость на мобильных. Рутина.

Открыл Claude Code, подключил Playwright MCP, написал «протестируй приложение». Агент начал работать, делать скриншоты, проверять элементы. На 51-м снапшоте /compact сработал. Текстовый контекст был заполнен на 18%. Я не понял что произошло.

Через час разбирательств я нашёл невидимый image-лимит. Через три часа — понял, что Playwright MCP сжигает в 50 раз больше токенов чем CLI на том же workflow. Через три дня — у меня был рабочий инструмент, который уже тестируют реальные пользователи.

Эта статья — про путь от «хочу просто протестировать» до open-source инструмента, и про архитектурные проблемы, которые заставили его собрать.

Python уже не просто язык для скриптов и Data Science — в 2026 году он стал «клеем», который связывает микросервисы, тесты и CI/CD в Java‑проектах. Как получилось, что даже консервативные Java‑разработчики всё чаще пишут интеграционные тесты на pytest, запускают контейнеры с Testcontainers и рулят пайплайнами в GitHub Actions с помощью Python‑скриптов?

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

Не так давно мне попался ноутбук Acer TravelMate B1 TMB118 с 4 ГБ DDR4. Благодаря размеру и маленькому потреблению он идеально подошел под эксплуатацию в виде печатной машинки и простенького редактора кода. 

Но именно этот малыш заставил меня задуматься: на какие уступки можно пойти по памяти, чтобы комфортно выполнять свою работу. В эпоху, когда комплект из 32 ГБ RAM DDR5 стоит в среднем 40 000 рублей, что сопоставимо с ценой бюджетного ноутбука, интересно, насколько можно опустить планку и существовать на современной системе.

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

После того как я написал статью «Головоломка на 1000 BTC» мне стали писать в личку авторы программ для их решения. В этой статье я расскажу о целом семействе таких программ и протестирую все те, что попали мне в руки, на скорость.

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

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

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

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

Логика на старте понятная:

Безэховая камера осталась позади. Измерения сняты, графики выглядят ровно, чувствительность укладывается в спецификацию, EVM не выходит за допустимые пределы.

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

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

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

Предупрежу, в статье МНОГО БУКВ, поэтому можно сразу перейти к Linux, Windows или к инструментам (они в самом конце).

В разработке качество часто ломается не только на самих багах — но и в тех местах, где работа переходит от одного этапа к другому без ясных условий. Задача уже поехала дальше, хотя acceptance criteria ещё сырые. Формально её можно тестировать, но по факту сначала нужно собирать контекст. Пайплайн зелёный, при этом важная проверка вообще осталась за его пределами.

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

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

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

Каждый, кто активно пользуется GitLab CI/CD, знаком с ситуацией: вы пушите изменения, ждёте минуту-другую, а пайплайн падает из-за мелкой ошибки линтера или отсутствующей зависимости. Исправляете, снова пушите, снова ждёте… Цикл может быть утомительным.

Но ведь GitLab Runner сам запускает ваши джобы в Docker-контейнерах. Почему бы не сделать то же самое локально? Это сокращает время обратной связи с нескольких минут до десятков секунд.

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

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

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

Помните момент, когда сервис работал нормально, но после рассылки, рекламной кампании или наплыва пользователей начал тормозить?

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

Привет! Меня зовут Артем Русов. Около 6 лет я занимаюсь обучением будущих теcтировщиков на платформах Stepik, Udemy и YouTube. И каждый день получаю вопросы о том: что там с тестированием и стоит ли начинать его изучать сейчас?

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

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