Про то, как автоматизация тестирования сначала даёт максимальный профит, а потом незаметно превращается в дорогой технический долг. И почему это почти всегда вопрос не инструментов, а подхода.
Прокси — один из основных инструментов в арсенале QA-инженера. Charles Proxy, Fiddler и Proxyman давно стали стандартом для анализа и изменения сетевого трафика в процессе ручного тестирования. Их принцип работы хорошо известен и подробно описан во множестве материалов.
Однако возникает вопрос: как использовать подобные возможности в UI-автотестах? Как перехватывать или мокать трафик в автоматизированных сценариях?
Привет, Хабр! Меня зовут Александр, я из Сбера, лидер по автоматизации в Департаменте Сервисы и Безопасности. В тестировании я около 13 лет, и последние лет 10 занимаюсь автоматизацией и её развитием в своём подразделении.
В этой статье расскажу, как с помощью IDE, LLM и RAG‑подхода можно автоматизировать одну из самых рутинных задач автоматизаторов — разработку новых автотестов по ручным сценариям, и при этом сохранять стиль и архитектуру проекта.
Привет, Хабр.
Я регулярно прохожу собеседования — в первую очередь чтобы держать в тонусе знания и понимать, что происходит на рынке. Плюс это помогает не терять ориентир по зарплатам и требованиям компаний.
Заметил, что периодически в чатах, на Хабре и в обсуждениях всплывает вопрос про сезонность найма. Кто-то говорит, что её нет и вакансии публикуются круглый год. Кто-то наоборот уверен, что есть «правильные» месяцы для выхода на рынок.
Поэтому решил поделиться своей насмотренностью на этот счет 👇
Автотесты E2E еще проще, но все равно надежные...
Вначале было Автотесты E2E для самых маленьких. А теперь в simpleE2E есть еще и автоматическое записывание шагов в браузере
Мы можем взаимодействовать с браузером и автоматически записывать шаги. Поддерживается
* Клик (в том числе ПКМ, в том числе с модификатором cntr или другими)
* Ввод текста
* Эталонный скриншот
* Видимость и НЕ видимость элемента
* Проверка содержимого текста (полное совпадение или частичное, или наоборот НЕ совпадение)
* Снятие эталонного скриншота для дальнейшего сравнения
Привет, Хабр!
Меня зовут Владислав Тимашенков, я занимаюсь автоматизацией тестирования в ГК InfoWatch. Мы разрабатываем DLP-систему для защиты контента и предотвращения утечек информации.
Специфика продуктов InfoWatch состоит в анализе самых разнообразных данных. Поэтому практически каждый автотест требует подхода с широким набором параметров. Для нашей команды хорошим решением стало вынести генерацию параметров pytest.mark.parametrize в отдельный компонент, который собирает данные из файловой коллекции проекта.
Существует множество способов параметризировать тестовые функции. Эта статья — пример изящной параметризации Pytest для сценариев, основанных на файловой коллекции проекта с большим количеством данных. Расскажем про наш опыт решения такой задачи.
Параметризация Pytest позволяет сделать из теста каркас, шаблон, который принимает данные для конфигураций, для assert и т.д.
Пример из документации Pytest:
Если в случае классических приложений нефункциональное тестирование часто переносят в разряд “было бы неплохо” и оставляют на потом, то при тестировании AI-приложений так уже не получится.
Привет, Хабр! Это продолжение серии про QA-собеседования.
Если при слове «контейнер» в голове только грузовые суда — эта статья для вас.
Привет, Хабр! На связи снова Максим из ATI.SU. В прошлой статье мы научились собирать логи на iOS устройствах разными способами и теперь для нас не вопрос разобраться, почему кнопка не нажимается, а данные не грузятся.
Но бывают ситуации куда страшнее. Вы запускаете приложение, а оно... тут же исчезает. Или вы работали в приложении, раз... и вы видите домашний экран. А еще приложение может так зависнуть, что помогает только полная перезагрузка самого устройства. Все это — его величество креш (a.k.a. краш, крэш, crash, вылет, сбой, падение, аварийное завершение).
Если привести аналогии, то логи — это жалобная книга, а креш‑отчет — это заключение судмедэксперта. В нём написано точное время смерти, причина и состояние памяти устройства в последний момент жизни приложения.
Для тестировщиков поймать креш и не допустить его до прода — это как для сапёра обезвредить мину раньше, чем на неё наступят. Работу можно сделать и после взрыва, но цена вопроса уже совсем другая. Сегодня я расскажу о 4+ проверенных способах собрать информацию о креше: от уже знакомых нам способов из предыдущей статьи до продвинутых систем мониторинга.
Интеграционные тесты любят все на словах, пока не доходит до окружения, зависимостей и плясок с подготовкой стенда. В статье разберем более практичный подход: как писать изолированные интеграционные тесты с Testcontainers, не превращая их в хрупкую конструкцию из моков и костылей. На примере PostgreSQL и .NET посмотрим, как собрать тестовую среду, которая ведет себя достаточно близко к реальности, но при этом остается воспроизводимой и управляемой. Тема не новая, а боль до сих пор вполне живая — так что давайте разбираться.
В этой статье я хочу поделиться личным опытом эволюции UI-тестов в AQA-проекте. Речь пойдет о том, как из типичных простыней с assertEquals(), множественными прямыми вызовами методов страницы и деталями реализации можно прийти к более выразительному и читаемому подходу — внутреннему DSL поверх Page Object.
Всем привет! На связи Карпенко Савелий, специалист по тестированию на проникновение из группы по борьбе с уязвимостями в компании ТехВилл.
В рамках нашей работы мы регулярно тестируем Active Directory (AD). Это центральный сервис аутентификации и управления доступом во многих корпоративных сетях. С практической точки зрения ошибки в конфигурациях AD часто становятся главной причиной взлома, среди проблемных аспектов можно назвать неверное назначение прав, доступов и использование устаревших механизмов аутентификации. Наличие недостатков в конфигурациях даёт атакующему возможность последовательно поднимать уровень своих привилегий. Ниже собраны типовые ошибки конфигурации, которые чаще всего встречаются на проектах, и показано, как они складываются в цепочки компрометации.
На практике аудит и тестирование обычно начинаются с исходных учетных данных, которые предоставляет заказчик. Если их нет, проникновение в инфраструктуру часто происходит через внешние веб-сервисы и ошибки на периметре (утечки паролей, небезопасные публикации, уязвимости бизнес-приложений). В российской практике одним из наиболее частых векторов для входа считается инфраструктура 1С, из-за повсеместного использования и различного уровня поддержки здесь чаще встречаются и слабые настройки, и типовые уязвимости.
Как устроен процесс собеседования QA-инженера в 2026 году? Из каких этапов он состоит и чем интересуются интервьюеры на каждом из них? В этом гайде я разложил всё по полочкам: что спрашивает HR (и как он оценивает ваши ответы), какие блоки теории нужно повторить manual-инженерам, а какие — automation-инженерам на Java, и как проходит секция с задачами на логику и лайвкодингом.
Внутри — структурированные списки вопросов с разбивкой по темам, реальные примеры из практики и советы, как правильно "продать" себя на каждом этапе. Материал будет полезен как джунам, так и опытным специалистам для систематизации знаний.
Рынок QA больше не про «быстрый вход» и простые решения. Вакансий меньше, требований больше, а старые советы не работают. В статье — приземлённый алгоритм, который помогает начать путь от рынка, а не от обещаний, и не потратить год на подготовку без выхода к офферам.
Как тестировать несколько мобильных приложений в одном «Appium‑проекте». Показываю архитектуру фреймворка, запуск тестов через аннотации, потокобезопасный контекст и подключение новых приложений без дублирования кода.
Как тестировать микросервисы, чтобы не было мучительно больно на проде? Разбираем пирамиду тестирования, интеграционные тесты с Testcontainers, контракты с Pact и нагрузочные испытания. Расскажу, какие практики реально работают в крупных проектах...
Всем привет! Меня зовут Алексей Ковалов, я руководитель отдела модульной верификации в YADRO в департаменте разработки процессорных архитектур. В прошлой статье я рассказывал, как расти верификатору. А сегодня хочу обсудить, как люди вообще приходят в эту профессию, ведь в вузах до недавнего времени верификаторов не готовили.
Дисклеймер: в статье нет технических деталей, так что матерые RTL-разработчики могут заскучать. А еще в ней нет лайфхаков, которые помогут за секунду определиться с карьерой и за три дня стать Илоном Маском. Зато есть реальный жизненный опыт.
Я написал этот текст для ребят, которые не определились с карьерой после вуза или уже твердо решили связаться с «аппараткой», но пока выбирают между разработкой и верификацией. Надеюсь, он поможет сориентироваться.
Последние полгода слежу за тем, как AI-агенты заходят в сферу тестирования. Делюсь честной картиной: что реально работает, где ещё болит, и как это меняет роль QA-инженера.
Привет! Меня зовут Карина, я QA-инженер в hh.ru. Наша компания растёт, а вместе с ней — число команд, вовлечённых в разработку и функционал. Появляются новые сервисы, базы данных, очереди. Каждый компонент требует слаженной работы и надёжной поддержки на тестовых стендах.
Сегодня мы работаем с гибкой тестовой средой, которую можно настроить под любую задачу. В статье расскажу, как вся эта сложная система выглядит изнутри.
Git — это вызов, через который проходит каждый второй новичок в разработке. Ветки называются «asdasd», коммиты — «правки», а pull request пугает своей красной кнопкой. Знакомо?
Меня зовут Сергей Прощаев, я Tech Lead в FinTech и преподаватель на курсах в OTUS. В этой статье разбираем самое главное: как создавать ветки и почему их нельзя называть как попало, что писать в коммитах, как сделать pull request в лучших практиках команд разработки