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

В области автоматического тестирования я работаю уже 15 лет. За это время я работал как в крупных компаниях, так и в небольших стартапах. Использовал различные языки программирования и технологии. Был частью разных команд — от специализированных групп разработчиков автоматического тестирования до смешанных команд, где вместе работали и разработчики, и тестировщики. За время карьеры занимал различные позиции и дорос до Senior Automation Engineer.

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

В этой статье мы подробно рассмотрим одно из нагрузочных тестирований портала Compo B2B, проведенное совместно с компанией Лига Цифрой Экономики. Мы опишем какие инструменты и методики использовались, с какими проблемами столкнулись, как правильно интерпретировать результаты тестирования и почему даже небольшая нагрузка тесно связана с масштабированием.

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

Конвейер непрерывной интеграции и поставки CI/CD является эффективным инструментом быстрого и качественного выпуска программного обеспечения. Разработчики и тестировщики активно используют те преимущества непрерывной разработки, которые дает данный пайплайн. Но экосистема решений 1С тоже позволяет построить конвейер CI/CD.

В этой статье мы рассмотрим построение такого пайплайна на основе инструментов, предлагаемых 1С.

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

Всем интересующимся — добро пожаловать под кат!

Продукты класса ContentCapture работают с большими объемами документов, и для бизнеса критична скорость их обработки. Но как убедиться, что система не замедлится после выхода очередного релиза? Здесь на помощь приходит тестирование: QA-инженеры регулярно проводят замеры скорости распознавания — например, при обновлении технологии или запуском нового проекта.

Казалось бы, все просто: автоматизируешь тесты, замеряешь время — и получаешь объективные метрики для оптимизации. Но на практике даже идеальная автоматизация не спасает от неожиданных сценариев.

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

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

Практическое руководство по получению сертификата ISTQB по тестированию AI (ИИ), в котором рассказывается о преимуществах, трудностях и практических советах для успеха. Эта статья содержит личные впечатления о том, как сертификация улучшила карьерные возможности, укрепила уверенность в тестировании проектов на базе ИИ и предоставила структурированный путь к овладению навыками тестирования ИИ. 

Начнем с боли, знакомой каждому. У любой уважающей себя компании есть своя цифровая «антресоль» — растущая гора DOCX-документов, неструктурированные PDF-файлы, раздувшийся Confluence и километры переписки в почтовых ящиках. Найти там что-то часто попросту невозможно. И тут на сцену выходят LLM и RAG-системы.

Retrieval-Augmented Generation — это технология, которая обещает превратить информационную свалку в упорядоченную библиотеку. Идея простая: даем мощному ИИ доступ к корпоративным знаниям, а поисковик в нужный момент находит релевантный документ и подает его модели. Должен получиться идеальный корпоративный ассистент, который знает все о продуктах, помнит каждую инструкцию и отвечает клиентам мгновенно и без ошибок.

Но есть загвоздка. Что если этот умный помощник, вдруг начнет галлюцинировать?

Мы с командой решили устроить тест пяти RAG-системам на реальных данных. От корпоративных платформ до open-source решений — AutoFAQ Xplain, Yandex, AnythingLLM, Witsy и Onyx. Мы заставили их работать с неудобными форматами, включая отсканированные PDF и устроили слепой экзамен на точность ответов. В роли экзаменаторов выступили два независимых эксперта и две нейросети-оценщика.

В этой статье расскажем:

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

Результаты вас удивят. Также будет ссылка на GitHub — вы сможете повторить наш эксперимент.

Идеальной методологии тестирования не существу… А вот и да, существует.

Привет, Хабр. На связи Константин Синанов, директор отделения аутсорсинга экспертизы тестирования, и Александр Александров, ведущий инженер-тестировщик в IBS. В этой статье мы расскажем о системном подходе к тестированию, который применяется в нашей компании на проектах любой сложности.

Раньше вас ревьюил злой коллега — теперь это делает AI. AI Review — open-source инструмент, который сам проверяет код прямо в CI/CD. Поддерживает OpenAI, Claude, Gemini, GitLab и GitHub. Быстро, честно и без боли.

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

Экономическая ценность репутации в российском контексте

Деловая репутация российских компаний сегодня измеряется не только лояльностью клиентов, но и конкретными финансовыми показателями. Согласно исследованию, проведенному в 2024 году, организации с высоким уровнем доверия к своему бизнесу и клиентам демонстрируют заметно более высокую рентабельность, что подтверждено на примере финансового сектора и сферы розничной торговли. Укрепление доверия способствует увеличению прибыли и устойчивости компаний благодаря повышенной лояльности клиентов и эффективности управления. В частности, рентабельность капитала в банковском секторе в 2024 году достигала около 24%, что частично связано с ростом доверия клиентов и партнеров.

Восстановление репутации после кризиса зачастую требует значительно больших ресурсов, чем профилактика инцидентов и проблемных ситуаций. Например, после масштабного сбоя в системе онлайн-банкинга одного из крупнейших российских банков в 2023 году, банк понес многомиллионные затраты на компенсации клиентам, а также на маркетинговые и PR-кампании, направленные на восстановление доверия. По оценкам экспертов, эти затраты могли быть в 5-7 раз выше, чем стоимость превентивного тестирования и мер по предотвращению подобных инцидентов. Такие кейсы демонстрируют, что инвестиции в профилактику, безопасность и качественную подготовку инфраструктуры значительно экономят средства и помогают минимизировать репутационные риски.

Салют, Хабр! 

Меня зовут Александр, я руковожу разработкой Фермы и Чембера в SberDevices. Про Ферму я уже рассказывал в прошлой статье. Сегодня, как и обещал (спустя полтора года, да) расскажу, что такое чембера. 

В целом чембер — от английского chamber, или камера. Так вышло, что изначально для тестирования умного устройства SberPortal были закуплены радио- и звуконепроницаемые камеры. Внутрь помещался наш объект контроля — DUT (device under test, «тестируемое устройство»). С тех пор закрепилось: всё, что делает чемберная команда, — это «чембер», даже если там нет камеры. Хотя корректнее говорить, что мы занимаемся разработкой тестовых станций. Занимательный факт: менеджеры произносят «чАмбер», а инженеры — «чЕмбер».

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

С момента официального объявления Kotlin как предпочтительного языка для Android‑разработки в 2017 году язык стремительно завоевал популярность не только в мобильной сфере, но и в автоматизации тестирования.

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

Всем привет! Меня зовут Елена Пилюгина, я ведущий разработчик отдела автоматизации бизнес процессов складской логистики в Magnit Tech.

В этой статье я расскажу про свой опыт покрытия тестами процессов в приложении на Spring Boot с Camunda 7. Покажу, как можно создать конструктор для тестирования процессов, варианты тестирования процессов в динамике и статике, поделюсь конкретными примерами кода, покажу преимущества BDD тестирования. Конечно, в рамках одной статьи невозможно охватить все технические аспекты, но я постараюсь показать выбранный мной подход к тестированию. Также буду рада, если заодно получится показать, что создание тестов может быть увлекательным и творческим процессом.

Привет, Хабр! На связи @mirez, в этой статье я подробно разберу, как решал задачу по получению бэкапа базы данных в сегменте Standalone на Standoff Hackbase. Нашей целью была система контроля посетителей PassOffice.

Мы пройдем все этапы: от обнаружения уязвимости в debug-режиме Flask до получения полного контроля над сервером. В процессе исследуем обход двухфакторной аутентификации, SQL-инъекцию и подмену библиотек для выполнения произвольного кода.

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

В эпоху повсеместного внедрения AI/ML мы часто фокусируемся на вычислительной мощности GPU и моделях, но упускаем из виду, что уникальная архитектура сетевых фабрик для AI создает новую поверхность атаки. Если в традиционных ЦОДах мы выстраиваем эшелонированную оборону и контролируем трафик на периметре, то в мире AI/ML эти парадигмы требуют серьезного пересмотра.

Привет, Хабр! Меня зовут Вадим, я уже много лет в тестировании и сейчас работаю Head of QA в Альфа-Банке (Беларусь). За эти годы я успел поработать с десятками инструментов, написать сотни тест-кейсов и... потратить неприлично много времени на рутину, которую можно было автоматизировать ещё вчера.

Знаете, есть такая особенность нашей профессии - мы автоматизируем всё вокруг, но часто забываем автоматизировать собственную боль. Сегодня хочу поделиться решением одной из таких "болей", с которой сталкивается каждый QA-инженер, работающий с ТестОпс: необходимость вручную синхронизировать тест-кейсы после каждого прогона автотестов.

На практике знание того, как НЕ писать тесты, может быть столь же важно, как и знание того, как их писать. В интернете можно найти множество материалов про “тесты с запашком”; в частности, им посвящено несколько очень полезных глав в книге Джерарда Месароша о паттернах в xUnit.

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

Привет! Продолжаем разбирать малоизвестные, но крайне полезные фичи Chrome DevTools. Меня зовут Святослав Ященко, я тимлид QA-команды Platform V Kintsugi — это графическая консоль для сопровождения PostgreSQL и Postgres-like СУБД. Ранее я писал о том, как тестировать производительность через вкладку Performance. Материала набралось так много, что мне пришлось разбить его на две статьи. Сегодня мы поговорим об утилите Performance monitor, инструменте Chrome Task Manager и о том, как вывести FPS сайта на экран. Приглашаю под кат!