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

Однажды мы со Standoff 365 договорились сделать крутой конкурс для начинающих багхантеров и представить его на PHDays Fest. Каково же было наше удивление, когда за первые 5 минут в конкурсе зарегистрировались 17 человек, всего же было 74 участника и 10 победителей. Еще больше удивило то, что багхантеры были вовсе не начинающие: в конкурсе участвовали сильнейшие хакеры страны. В этой статье разберем, какие были задания.

Мы приняли решение сделать конкурс в формате CTF. Для этого с нуля в ChatGPT была разработана платформа. Как показала практика, код, который написала нейросеть, оказался неидеальным в плане безопасности, но в целом после исправления некоторых проблем все стало работать стабильно.

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

Если вы начинающий специалист в автоматизации тестирования, или автотестировщик с опытом, готовый обсуждать и улучшать стратегии тестирования, то с радостью представляю вам первый пост в серии, посвященный разборам подходов к тестированию ПО. Здесь я разбираю свой взгляд на способы решения реальных задач по тестированию, используя Playwright + TypeScript.

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

В лучшем случае вы получите бесполезный список из сотни мелких «дыр» в принтерах и кофемашинах. В худшем — пентестеры случайно обрушат производственную линию или устроят 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 г., что казалось немыслимым еще пару лет назад. А как принимают на работу сеньоров, если речь идет не о массовом наборе, а точечно, под конкретные проекты? Об этом я и хотела порассуждать в этом посте.