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

Каждый раз новый сотрудник приходит к вам с одними и теми же вопросами по Фигме? Или впервые видите макет в Фигме и не знаете, куда нажимать?

Мы посмотрим на Фигму глазами новичка и опытного дизайнера. Тем, кто только сталкивается с Фигмой, постараюсь помочь понять базовую логику работы с файлами, слоями, структурой и совместной работой. А продвинутые пользователи найдут здесь ответы на частые вопросы. Статья в первую очередь будет полезна аналитикам, тестировщикам и другим участникам процесса, которые работают с макетами.

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

Присоединяйтесь к инженерам YADRO и MWS Cloud Platform в Санкт-Петербурге и онлайн — для участия достаточно зарегистрироваться на сайте.

Всем привет! Меня зовут Алексей Архипов. Я работаю начальником отдела тестирования в Национальном клиринговом центре (НКЦ), входящем в состав Группы «Московская биржа». За последние годы мы столкнулись с множеством вызовов в оценке качества программного обеспечения (ПО), особенно в условиях высокой нагрузки и сложности критических систем. В начале работы с QA-командой меня заинтересовал ключевой вопрос — каким образом можно точно измерить качество тестирования? Ответ оказался неочевидным.

В современных условиях тестирование ПО — это не просто процесс проверки функциональности, а ключевой элемент управления качеством. Однако популярная метрика Defect Leakage (DL), которую часто используют для оценки работы QA-инженеров, не всегда отражает реальную картину. В НКЦ мы столкнулись с этой проблемой и разработали для себя более точный подход — Коэффициент эффективности тестирования (КЭТ). В этой статье я расскажу, почему DL не работает, как мы внедрили КЭТ и какие результаты получили.

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

Привет, Хабр! Часто ли вам приходилось часами смотреть на сложный JOIN, пытаясь понять, почему он работает не так, как надо? Или, может, вы только начинаете свой путь в IT и слышите со всех сторон, что без SQL никуда? Вы правы, так и есть. SQL – это не просто строчки кода, это ваш ключ к данным, настоящий швейцарский нож для любого тестировщика, аналитика или разработчика.

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

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

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

Если вы разрабатываете софт для IoT, пишете мобильные приложения, проектируете распределённые системы или просто любите истории о том, как инженерные костыли превращаются в полноценные решения — эта статья для вас.

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

Привет, заводчане! В этой статье вы найдете реальные технические советы по особенностям общения с бездушными ИИ моделями, в частности я расскажу про GPT 4o и свежую 5, но эти советы также применимы и к другим AI.

‼️Сразу внесу ясность: рекомендации предназначены для личных пет-проектов и
не призывают нарушать политику конфиденциальности вашей компании!

Я инженер по тестированию и уже около года поддерживаю работу своей песочницы по практике тестирования и подготовке к собеседованию на позицию Full Stack QA. Опыт вайбкодинга повлёк за собой понимания работы JS, CSS и HTML, если говорить конкретно про веб-проект. Благодаря такому проекту и подходу вайбкодинга, я собрал технические инструкции и заметки как выжать максимум из ответа ИИ моделей, здесь будет больше технических особенностей работы с моделями, нежели готовые промпты. Ниже указал 12 советов, которые упростят вам написание кода, разработку своего проекта, изучение нового стека или учебную практику.

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

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

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

Команда Go for Devs подготовила перевод статьи о пакете synctest, который с Go 1.25 стал частью стандартной библиотеки. Он позволяет писать быстрые и надёжные тесты для конкурентного кода, не усложняя сам код. Теперь асинхронные операции можно проверять без долгих ожиданий и флаки-тестов.

Спрос на QA-специалистов в России продолжает расти, однако конкуренция в этой нише очень высокая. Так, по данным Computerra, в числе наиболее востребованных ИТ-специалистов в 2025 году оказались именно тестировщики и специалисты по написанию автотестов. При этом работодатели всё чаще требуют от тестировщиков навыков уровня начинающего разработчика: знания бэкенда, фронтенда, работы с БД и умения писать скрипты для автотестов. В этой статье мы подробно рассмотрим актуальные языки программирования, фреймворки и инструменты в автоматизации тестирования, требования работодателей, типичные этапы собеседований, а также рекомендации по подготовке.

Баги, пойманные на проде, всегда стоят слишком дорого — и времени, и нервов, и репутации. Юнит-тесты не видят проблем с реальными зависимостями, моки быстро устаревают, а интеграционные среды тормозят разработку. Выход ищут в подходе shift-left: проверять критичную бизнес-логику раньше, прямо в IDE, без ожидания CI. В этой статье разберём, как библиотека Testcontainers позволяет поднимать реальные сервисы в контейнерах, писать интеграционные тесты так же просто, как юнит-тесты, и что это даёт с точки зрения скорости и качества по метрикам DORA.

Привет, Хабр! Отправив детей в школы и детские сады (а кто-то из нас сам идет преподавать в ИТМО и СПбГУ), делимся первым релизом этой осени. Теперь вы можете использовать возможности ассистента в PyCharm. С поддержкой MCPсерверов больше не нужно реализовывать отдельные интеграции для каждого инструмента. Пользовательские Rules и Workflkows помогут сделать работу агента более удобной и корректной.

Разбираем самые странные антипаттерны в автотестах на Python: от sleep(0.1) и стрелочек вниз до глобальных курсоров и "фреймворков" на 3500 строк. Почему так делать не стоит и какие есть взрослые альтернативы.

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

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

Я просто включил «open to work» на LinkedIn — и неожиданно получил оффер в продукт. Пошёл на собеседование «чисто посмотреть» и остался.

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

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

Записки одного QA. Вспомогательная часть автотестов: советы и практики (Playwright + Typescript)

В статье рассматриваются подходы к организации вспомогательной части для автотестов на Playwright: структура проекта, Page Object, helpers, constants и шаги. Приведены практические примеры того, какие решения помогают поддерживать автотесты читаемыми и масштабируемыми, а каких стоит избегать. Материал будет полезен QA-инженерам и разработчикам, начинающим работать с Playwright.

Отладка E2E-тестов может быть трудоёмкой задачей. При падении тестов Playwright нередко приходится вручную анализировать сообщения об ошибках и стек-трейсы, искать причины неудач (например, неправильно подобранный селектор, увеличенные задержки или неожиданные изменения в DOM) и пробовать разные варианты исправлений. Традиционно QA-инженерам приходится копировать текст ошибок и обращаться к документации или чат-ботам вроде ChatGPT с вопросами вроде «почему селектор не нашёлся» или «как увеличить таймаут». Это занимает время и отнимает ресурсы команды.

Тест-кейс тест-кейсу рознь!

Мне, как разработчику автоматизированных сценариев неоднократно приходилось сталкиваться с «нечитаемыми» и непригодными для автоматизации тест-кейсами.

Доработка кейсов своими силами (силами автотестеров) в процессе автоматизации – это сизифов труд.

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

На первом же проекте это дало очень мощный положительный эффект не только для нас, автотестеров, но и для самих ручных тестировщиков: позволило ускорить процесс вникания в суть кейса разработчиками автотестов, а также сократило время адаптации для новых ручных тестировщиков до 2-х недель против 3-х месяцев.

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

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

Итак, начнем урок.