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

Кратко о себе: в прошлом разработчик смарт-контрактов (с 2017 года), с 2022 года работаю аудитором смарт-контрактов. Эта статья для тех, кто так или иначе интересуется информационной безопасностью и непосредственно аудитом смарт-контрактов (да и процессом аудита в целом).

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

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

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

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

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

Привет, меня зовут Смирнов Владимир, и я отвечаю за тестирование торгового бэкенда в EXANTE. Разработка кипит, регрессионные наборы автотестов растут - всё это сопровождается хаосом и различиями тестовых окружений, из-за чего неизбежно растёт и число нестабильных падений (ака флаки), за завесой которых могут теряться реальные проблемы. Как мы регулярно поддерживаем автотесты в приемлемом состоянии и стараемся не тратить на это слишком много времени? Об этом и поговорим.

ZConnect — второй месяц вайб-кодинга, или как я делаю свой удалённый рабочий стол

Прошло уже больше месяца с прошлой статьи. За это время в моём проекте ZConnect появились передача файлов, NAT traversal, клики по UAC, установщик со службой, мультимонитор, адресная книга, Android-клиент, тёмная тема.

Заодно поймал забавный краш в mrwebrtc 2.0.2 на нестандартных sample rates, выложил проект в open source и окончательно понял, что вайб-кодинг всё больше начинает напоминать лудоманию.

В статье расскажу: что удалось сделать; на какие грабли наступил; как ИИ помогает и мешает одновременно; и почему поддерживать большой проект в режиме «вайб-кодинга» оказалось утомляюще.

Привет, Хабр! Меня зовут Юра Жанов, я занимаюсь автоматизацией тестирования в hh.ru.

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

Если вам обещают, что ИИ ускорит разработку в 5 раз — скорее всего, вам пытаются что‑то продать. Особенно если «волшебство» сводится к установке плагина в IDE.

Меня зовут Алиса Герасимова, я руковожу отделом функционального тестирования в центре разработки и машинного обучения «Инфосистемы Джет». В статье расскажу, как ИИ ускорил одну из наших команд разработки, но с цифрами из реального мира. Поговорим про метрики, разграничение ролей между человеком и ИИ, а также честно покажем, где машина больше мешает.

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

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

Уже больше полутора лет я пишу автотесты на 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 не выходит за допустимые пределы.

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

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