Тестирование

NAC-системы долгое время ассоциировались с “монстрами” вроде Cisco ISE или Aruba ClearPass. Но что, если собрать российский NAC из модулей «Медведь», «Лиса» и «Заяц», поставить их на страже сети и попробовать закрыть те же сценарии?

Привет, Хабр! С решениями NAC наша команда работает больше 19 лет. Последние годы особенно интересны: российский сегмент NAC заметно вырос, новые продукты появляются регулярно, а интерес со стороны заказчиков подталкивает нас на постоянный анализ рынка. 

Эта статья — часть цикла о NAC-решениях, которые мы разбираем в нашей сетевой лаборатории. На этот раз в фокусе Eltex NAICE — новичок в области контроля доступа, но далеко не новичок в мире сетей.  Разберёмся, как он устроен, какие задачи реально закрывает и насколько уверенно чувствует себя на фоне более привычных NAC-систем. 

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

Меня зовут Марина Скалина, я QA‑автоматизатор в СберТехе, в команде Platform V Kintsugi — это графическая консоль для сопровождения PostgreSQL и всех СУБД, основанных на PostgreSQL (как наша же СУБД Pangolin). Поговорим о том, что стоит учесть, если вашей команде тестирования необходимо перейти на параллельный прогон.

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

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

На практике всё часто работает чуть иначе.

Да, техничка важна. Никто с этим не спорит. Но оффер нередко ломается не на алгоритмах, не на лайвкодинге и даже не на ошибке в каком-нибудь ответе. Очень часто всё решают вопросы, которые на первый взгляд выглядят максимально безобидно. Из серии: “кем вы видите себя через пять лет?”, “что вас мотивирует?”, “почему хотите уйти?” или “какой у вас был самый большой косяк?”.

И вот именно на них люди регулярно сыпятся.

Не потому что они глупые. И не потому что не умеют разговаривать. А потому что воспринимают эти вопросы как формальность. Как будто это просто обязательный HR-блок, который надо пережить перед чем-то действительно важным.

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

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

Почему вообще такие вопросы так важны

Потому что технические ответы очень часто показывают только верхний слой.

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

Именно поэтому рынок так любит эти странные вопросы, которые вроде бы не про технологии.

Они не проверяют знания. Они проверяют совместимость.

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

Всегда рад новым читателям!

Приветствую, Хабр!

Меня зовут Владислав Тимашенков, я занимаюсь автоматизацией тестирования в ГК Infowatch.

Наша команда столкнулась с популярными болями автотестов для API:

- одно изменение в API требует обновления нескольких тестов;
- проверка структуры ответа распределена по тестам и не централизована;
- валидация вложенных структур и генерируемых полей требует дополнительного кода.

И мы задались вопросом: какой инструмент для валидации контракта нам подойдёт?

В этой статье расскажем о нашем переосмыслении подхода к тестированию API с помощью внедрения Pydantic.

На предприятии, где я работаю, купили пускатель ПБР10А производства «Овен». Мне выдали его для опробования, изучения свойств. Кто-то вычитал где-то, что им можно заменить, применяемые нами на предприятии приборы ПКП1 того же производителя.

Apache JMeter — не просто инструмент. В этой статье разберем, как получать от него реальную пользу. Вы узнаете, почему 80% отчётов о нагрузке бесполезны, как настроить распределённый тест и анализировать не среднее значение, а процентили. Полный гайд от первого HTTPS-скрипта до информативного HTML-отчёта и Best Practices.

AI в тест-автоматизации развивается стремительно, и все пробуют связку Claude Skills с Playwright, чтобы сделать QA-инжиниринг эффективнее.

Часто встречающийся вопрос звучит так:

Это была пятница, шесть вечера. Я сидел перед монитором и чувствовал себя следователем, который зашёл в тупик.

Три часа назад я нашёл странное поведение в приложении. Открыл Jira, но пока заполнял поля — мысль ушла. На рабочем столе уже лежало 15 скриншотов с именами вроде «Снимок экрана 154312.png». Я открыл их наугад, но уже не помнил, к какому запросу какой относится.

«Я потерял контекст». Баг есть, даже помню, как воспроизвести. Но чтобы восстановить цепочку «действие → реакция сервера → скриншот → вывод» — нужен ещё час.

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

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

Меня зовут Александр. Я перепробовал Jira, Confluence, Notion и просто папки на диске. Всё либо медленно, либо хаотично, либо зависит от интернета. Поэтому я собрал свой локальный редактор — под себя, под тестирование. Делюсь историей и кейсом.

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

Меня зовут Маша, я QA Engineer в Doubletapp. Мы с 2020 года аутстафим в бигтехах, банках, стримингах, интеграторах, e-commerce и т. д. Поэтому хорошо знаем, где эта модель ломается и как сделать так, чтобы она действительно работала.

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

Навигация по статье 

— Вливаемся в проект, фиксируем ожидания и критерии успеха
— Интеграция в команду: как не остаться «внешним»
— Работа и результат: как быть полезным вопреки неудобствам
— Блокеры, доступы и прозрачность: защита от репутационных потерь
— Как не выгореть между проектами
— Когда аутстаф начинает работать.

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

В нашем арсенале более 2500 скриншотных тестов, поэтому многие выводы сделаны на основе длительного опыта эксплуатации.

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

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

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

Привет! Меня зовут Андрей Романюк, я руковожу группой качества в онлайн-кинотеатре Okko. В прошлой статье я рассказывал о том, как мы начали взвешивать баги, сам подход к этому взвешиванию, и о том, что это помогло нам сократить количество заранее известных багов, которые мы выкатываем в прод.

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

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

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

Когда мы заходим на проект, то почти всегда встраиваемся в существующую экосистему.

Однако, при таком варианте мы теряем возможность управлять результатом нашей работы.

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

Бывает ситуации и сложнее. Например, у клиента есть CI/CD, но из-за требований безопасности им нельзя подключать внешние раннеры. Бывает случаи, когда у клиента нет своего CI/CD. Поднять его у себя они не могут (нет на это ресурсов, людей или того и другого), а использовать публичные или даже приватные облака запрещает какое-нибудь внутреннее соглашение.

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

Наш стек

Чтобы обеспечить стабильность, мы развернули внутреннюю связку: Self-hosted GitLab + GitLab CI + GitLab Pages.

Привет! Меня зовут Артем Русов. Уже 6 лет я занимаюсь обучением будущих тестировщиков, а также повышением квалификации действующих специалистов. За это время прошел долгий путь от видео в плейлистах на Youtube до курсов бестселлеров на площадках Stepik и Udemy.

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

Привет! Это снова Михаил Федоров. В первой статье я рассказал про архитектуру QA Assist — системы из 11 AI-агентов для автоматизации тестирования. Во второй — честно показал, как «4 часа подключения» превращаются в неделю корпоративной реальности.

Сегодня поговорим о штуке, которая на первый взгляд не имеет отношения к AI. О пирамиде тестирования. О том, почему классическая теория QA внезапно оказывается критически важной, когда вашим тест-дизайнером становится языковая модель с контекстным окном.

Playwright или Selenium на Java — что выбрать для автотестов в 2026 году? Разбираю историю инструментов, различия в локаторах, ожиданиях, стабильности, стоимости поддержки и объясняю, в каких сценариях каждый из них лучше.

В Go нет фикстур, и в интеграционных тестах это быстро превращается в копипаст. Разбираем, как вынести инфраструктуру из автотестов и управлять жизненным циклом ресурсов.

Ранее в статье: Soft Skills для тестировщика: почему «мягкие» навыки важнее «жестких» скриптов я попытался рассказать почему для тестировщика важно развивать Soft Skills, а сейчас разберемся как это реализовать на практике.

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

Эпичная история установки всех* расширений для браузера Firefox. Это был непростой процесс, который-таки увенчался успехом. Не обошлось в нём и без некоторых любопытных поворотов, неразрешённых вопросов и помощи друга.

Как выяснилось, всего у Firefox 84 тысячи расширений. Вроде бы не особо много, и по факту даже меньше 50 ГБ. Так что приступим!

*Всех, кроме 8, которые мы не соскрейпили (или которые удалили в промежутке между моментом проверки их списка на сайте и запуском скрипта), и 42, которые отсутствовали в extensions.json.¹ Так что чисто технически мы установили 99,94% всех расширений.

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

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