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

С виду все просто: дали пентестерам доступ в сеть, они пошарились по серверам, нашли пару уязвимостей, написали отчет. Профит. Но на деле плохо подготовленная проверка легко превращается в хаотичный квест с непредсказуемым финалом.

В лучшем случае вы получите бесполезный список из сотни мелких «дыр» в принтерах и кофемашинах. В худшем — пентестеры случайно обрушат производственную линию или устроят DDoS на Active Directory. А между этими крайностями лежит целый спектр проблем: от юридических рисков, если в документе не очертить скоуп и команда выйдет за рамки дозволенного, до банального несовпадения ожиданий и результатов.

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

Jira — это гибкая система отслеживания задач и багов от Atlassian, которая помогает командам разработки и тестирования вести единое хранилище требований, задач и дефектов. Позволяет ловить баги и фичи на одном бэклоге: по словам Atlassian, в Jira можно «уловить, отследить, решить и отчитаться о багах и проблемах» на протяжении всего процесса разработки.

При этом инструмент предлагает «единый вид всех элементов бэклога — будь то баг или задача по новому функционалу», что помогает приоритизировать общие цели команды. Это значит, что QA могут иметь в Jira общее пространство тест‑кейсов, задач на тестирование и найденных дефектов.

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

Статья будет полезна для всех участников QA‑команд (тестировщиков, тимлидов), кто базово уже разбирается с инструментом и хочет в него углубиться.

В каждом собеседовании наступает момент, когда интервьюер говорит: «Какие у вас есть вопросы к нам?». Для большинства это вежливая формальность. Для сильного специалиста — это главный этап собеседования, на котором уже он оценивает компанию.

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

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

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

Привет, меня зовут Роман Поляков, я инженер по тестированию (QA-самурай) в Т1 Иннотех. В мире ручного функционального тестирования каждый день идёт битва за качество. Смена требований, пропущенные баги, плотные дедлайны и тонны тестовых сценариев могут сломить даже опытного специалиста. Но настоящий QA-самурай не сдаётся. Он превращает рутину в искусство, а стресс — в топливо для роста.

Если вы когда-нибудь думали, что работа QA — это просто сидеть и нажимать на кнопки в надежде, что баги сами обнаружатся, то… вы немного заблуждались! Добро пожаловать в увлекательный и порой весьма запутанный мир тестирования, где каждый день сулит встречу с новыми подводными камнями, ловушками и, конечно же, классическими граблями на пути к качественному продукту.

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

Привет! Продолжаем разбирать малоизвестные, но крайне полезные фичи Chrome DevTools. Меня зовут Святослав Ященко, я тимлид QA-команды Platform V Kintsugi. Это графическая консоль для сопровождения PostgreSQL и Postgres-like СУБД. Ранее я писал о том, как подменить трафик в DevTools. Сегодня покажу, как тестировать производительность web-приложения, не выходя из Chrome. 

Наш продукт — высоконагруженный, как в части бэкенда, так и в части фронтенда. БольшУю нагрузку на web-часть дают графики метрик наблюдаемых баз данных. Нагрузочное тестирование бэкенда в нашей команде — тема отдельной статьи, но об этом постараюсь рассказать в другой раз, а сейчас протестируем производительность фронтенда. Добро пожаловать под кат.

Я заметил, что вокруг новых AI-инструментов для кодинга (типа Cursor AI, ChatGPT, Claude) идёт жаркая дискуссия. Классические программисты порой скептически смотрят на тех, кто активно пользуется генеративным ИИ вместо ручного кодирования. Некоторые считают таких «вайбкодеров» мешком софта без понимания: мол, они просто копипастят то, что выдаёт ИИ. Попробую разобраться в этом лично: ведь для многих из нас эти инструменты открывают новые возможности.

Привет, Хабр! Меня зовут Ваня, и я AQA-инженер. Как и многие из вас, я занимаюсь обучением будущих покорителей Postman и Pytest. И, как многие из вас, я столкнулся с проблемой: все существующие тестовые API — невыносимо скучные.

Todo-листы, интернет-магазины с товарами Item 1, Item 2, API для управления книгами... Серьезно? После пятого GET /todos начинаешь сомневаться не только в своей карьере, но и в смысле бытия. Данные в них стерильны, как операционная, а сценарии предсказуемы, как сюжет российского сериала.

Моим ученикам было скучно. Мне было скучно. Я понял, что нужен свой API. С блэкджеком и... ну, вы поняли. С API, который будет не просто функциональным, но и забавным. Который захочется «потыкать» просто ради того, чтобы увидеть очередной перл в ответе сервера.

Так родился «Cynical Circle API» — API для тех, кто понял жизнь и устал от ванильных примеров.

(Так выглядит наша интерактивная документация. Уже интригует, не правда ли?)

Всем привет! Меня зовут Дима Лунин, я автор курса по экспериментам в Академии Аналитиков Авито. В текущей статье я хочу "обкатать" материал, который мы рассказываем на курсе экспериментов, а также поделиться экспертизой по АБ-тестированию с ребятами, которые только начинают свой путь в аналитике, но уже имеют базовые знания в статистике и в проверке стат. гипотез.

В этом тексте расскажем, как мы за две недели собрали MVP генератора тест-кейсов на базе GenAI для компании IT Media Service. До этого ребята вручную писали сотни тест-кейсов и автотестов к каждому релизу, тратили на это тонны времени, а автоматизация требовала улучшения. 

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

Однажды мне предложили попробовать написать автотест для этого проекта, чтобы понять, будет ли мой подход эффективнее. Я использовал базовый Page Object Pattern и немного модифицированные (ради стабильности) методы Selenium. В результате получился выигрыш в ~10–15%. То есть смысла переписывать тесты особо не было.

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

Круто? Да. Вот только при росте количества тестов очевидно вырастет и время выполнения. Ещё пара сотен тестов — и я буду успевать сгонять за кофе на другой конец города и обратно. Так что нужно искать решение.

Итак, первая часть нашего пути позади. Ваше резюме отшлифовано, мотивация ясна, и вы успешно пробили HR‑фильтр. Вы получили заветное письмо: «Приглашаем вас на техническое интервью». Сердце делает кульбит. Радость сменяется новой, более холодной волной тревоги. Теперь предстоит разговор с теми, кто будет оценивать вашу профессиональную подготовку. И здесь вас может ждать кто угодно. Это может быть ваш будущий QA‑лид или старший специалист по тестированию, проджект‑менеджер (как было у меня дважды), а порой — целая техническая комиссия из разработчика, системного архитектора и тимлида. Важно понимать: далеко не все из них «говорят с кодом на ты», но каждый будет оценивать вашу логику, понимание процессов и техническую смекалку.

Это и есть главное событие. «Boss‑fight» первого уровня, где проверяют не только то, что вы знаете, а то, как вы мыслите, как справляетесь с давлением и готовы ли вы стать частью команды. Кажется, что это экзамен, где каждый неверный ответ — шаг к провалу. Но главный секрет, который мы раскроем в этой статье, прост: техническое собеседование — это не экзамен, а диалог. И ваша цель — не сдать его на «отлично», а провести как равный собеседник.

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

Асинхронность в тестах выглядит как способ «бесплатно» ускорить прогон: пока один тест ждёт ответа сервера, другой мог бы выполняться. Я переписал UI (Playwright) и API (HTTPX) тесты на async/await, прогнал их в CI/CD и посмотрели на результат. Спойлер: магического ускорения не произошло — разбираемся, почему так и когда асинхронность всё-таки нужна.

Что происходит с QA-индустрией и куда она движется? Действительно ли профессия умирает или у неё есть будущее?

Привет Хабр, меня зовут Алина, и я HR-lead компании SSP SOFT (мы занимаемся заказной разработкой). Написать пост про особенности найма сеньоров мне помог наш райтер Сергей, а на саму идею — сподвиг случайно встреченный на просторах интернета пресс-релиз из заглавной иллюстрации. Не буду останавливаться на названии этой компании, его легко загуглить по фразам из скрина. Важно другое — коллеги по отрасли написали про избыток сеньоров на рынке труда в 2Q/2025 г., что казалось немыслимым еще пару лет назад. А как принимают на работу сеньоров, если речь идет не о массовом наборе, а точечно, под конкретные проекты? Об этом я и хотела порассуждать в этом посте.

Бизнес: «Зачем нам тестирование? Разве нельзя написать всё хорошо и сразу?».

Разработчик: «Это не баг – это фича».

Тестировщик: «Ошибки в коде, а крайний кто? Все на тестировщика!».

В статье разберем:

• взгляд заказчика на тестирование ПО;

• мышление тестировщика и разработчика;

• тестировщик и код: нужен ли глубокий дайвинг?

• что же дает тестирование?

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

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

Хабр, привет! На связи Александр Леонов, ведущий эксперт PT Expert Security Center и дежурный по самым опасным уязвимостям месяца. Мы с командой аналитиков Positive Technologies каждый месяц исследуем информацию об уязвимостях из баз и бюллетеней безопасности вендоров, социальных сетей, блогов, телеграм-каналов, баз эксплойтов, публичных репозиториев кода и выявляем во всем этом многообразии сведений трендовые уязвимости. Это те уязвимости, которые либо уже эксплуатируются вживую, либо будут эксплуатироваться в ближайшее время.

С прошлого дайджеста мы добавили в наш список еще 2 трендовые уязвимости в продуктах Microsoft.

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

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

Также существует классификация метрик по методам их получения, которая делит их на базовые и рассчитываемые.

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