Использование ИИ в работе - одна из самых обсуждаемых тем последнего года. Моя жена активно применяет его в своих задачах, и когда мы что-то обсуждаем, она удивлённо спрашивает: «А ты-то почему до сих пор не используешь ИИ?» И в какой-то момент я и сам задумался - а правда, почему?
Я разобрался в теме, чтобы вам не пришлось. В этой статье поделюсь, как использовать ИИ с умом и пользой на примерах из мира тестирования (QA). Но фишки, о которых пойдёт речь, вполне подойдут и для других профессий.
Я работаю в сервисной компании, и в своей работе мы часто используем российские SD-WAN-решения. Делаем крупные и нестандартные внедрения, а также предоставляем сеть по «подписочной модели», в том числе и SD-WAN. В целом технология сама по себе довольно молодая, но за два года работы мы накопили довольно большой и интересный опыт.
В данной статье я хочу поделиться способом конфигурирования NAT на СРЕ от Kaspersky SD-WAN, который пригодится в случае подключения сетей с одинаковым адресным диапазоном. В статье вы не найдете рассказ про технологию SD-WAN в целом, сравнения решения разных вендоров, преимущества и недостатки сервиса, а также какое решение является «более настоящим» SD-WANом, а какое – только оптимизацией выхода в интернет. Потому что, возможно, все это будет темой для следующих статей. Здесь сфокусируюсь только на технических деталях конфигурирования.
Привет! Меня зовут Александр, я SDET-специалист в SimbirSoft. В этой статье я расскажу, как можно покрыть разрабатываемую часть проекта автотестами на ранних этапах его разработки, если в команде отсутствуют аналитики и присутствуют задокументированные требования только по основному функционалу. Эта статья будет интересна как джунам, так и техническим специалистам middle и выше, а также руководителям команд (team leads) и техническим лидам (tech leads).
Я поделюсь тем, как в такой ситуации были настроены процессы в нашей команде. Мы работаем над проектом с утвержденной микросервисной архитектурой с внутренними и внешними сервисами. Команда работает по Scrum-методологии и состоит из тимлида, разработчиков сервисов, QA и SDET-специалистов. От заказчика поступила лишь основная информация о том, что должен делать продукт и на каких платформах его можно будет использовать. Именно эта информация и была задокументирована в виде требований.
В первой части гайда по тест-дизайну в блоге ЛАНИТ на Хабре мы уже рассмотрели основные техники тест-дизайна, связанные со сценариями и данными. Теперь давайте обсудим, как тестировать ролевую модель приложения.
Действия пользователей в системе и в рамках бизнес-процессов существенно влияют на эргономику, слаженность и безопасность. Работа с множеством ролей и процессов может быть сложной и требует внимания, но понимание этой механики необходимо.
Когда речь заходит о производительности BPM-ldb;rf, главным показателем является пропускная способность заданий и таймеров. Проще говоря: чем больше заданий или таймеров выполняется за определённый промежуток времени, тем быстрее смогут продолжать выполнение процессы или кейсы, которые их используют.
Сегодня расскажем о том, как мы совместно с разработчиками ПО протестировали комплексную отечественную гиперконвергентную платформу виртуализации vStack в нашей лаборатории.
Почему мы уделяем большое внимание проверке совместимости аппаратной части и программного обеспечения? Ответ прост. Подтверждение совместимости позволяет избежать таких проблем, как непредвиденные сбои, некорректная работа ПО или оборудования, потеря данных или другие ошибки и служит гарантией качества и надежности решения для заказчика.
Целью испытаний было проведение функционального и нагрузочного тестирования серверного оборудования Fplus Спутник FPD-R-13-SP и ПО vStack начиная с установки, настройки ПО, запуска различных виртуальных машин (ВМ) и настройки виртуальных сетей и прочего.
По ряду сценариев vStack показал себя относительно быстрее других систем управления виртуализацией на основе oVirt, особенно в режимах создания и загрузки ВМ из готовых образов. В ряде моментов все же возникали вопросы, особенно касающиеся работы консоли и загрузки пользовательских образов, о чем были высказаны пожелания разработчику ПО. Инженеры нашей лаборатории постарались выполнить тестирование и использование данной платформы от лица нашего потенциального заказчика, основываясь только на документации и с минимальным привлечением к работам создателей ПО.
Привет! Меня зовут Антон Семенистый, я старший data science инженер в Авито. Мы с коллегами разрабатываем алгоритмы платного продвижения, и нам часто приходится тестировать новые модели. Как оказалось, A/B-тесты не всегда дают верный результат в сравнении рекламных алгоритмов, поэтому мы перешли на split-тесты. В статье рассказываю про преимущества split-тестов перед A/B для решения AdTech-задач, а также о том, почему и как мы используем эти тесты для ранжирования рекламных объявлений в поисковой выдаче.
Признаемся честно: слово «тестирование» вызывает у многих разработчиков примерно такую же радость, как поход к стоматологу. Большинство морщится и думает: «Опять эти тесты... Лучше бы новую фичу запилил!» И я вас прекрасно понимаю — сам когда-то был в лагере скептиков.
Но после нескольких лет руководства командой фронтенда, десятков ночных дебагов и сотен часов, потраченных на поиск неуловимых багов, я пришёл к неожиданному выводу: качественные юнит-тесты — это не якорь, замедляющий разработку, а реактивный двигатель, ускоряющий её.
В этой статье я расскажу, почему наша команда делает ставку именно на юнит-тесты, и как они могут превратить вашу разработку из хаотичного забега с препятствиями в уверенный марафон с чёткими ориентирами.
Всем привет! В Питере вместе с летней жарой случился релиз Explyt 4.0 c крутыми фичами для написания кода, тестирования и дебаггинга: агентским режимом Explyt Agent и генерацией тестов по исполнению Generate Tests from Execution.
При работе со сквозным тестированием (E2E, end-to-end) в Playwright критическое значение имеет поддержание упорядоченной и масштабируемой тестовой базы. Хорошо организованная структура не только улучшает поддерживаемость, но и облегчает адаптацию новых коллег. В этой статье мы рассмотрим, как организовать тесты в Playwright наилучшим образом, начиная со структуры папок и заканчивая использованием хуков, аннотаций и тегов.
Всем привет! Публикуем вторую и заключительную часть разбора заданий конкурса AI CTF 2025. Задания этой части повышенной сложности! Приготовьтесь вспоминать, как работают ML-модели и сервисы их использующие. А ещё приоткройте учебник эльфийского ;-)
У любого процесса есть своё бутылочное горлышко. Если разобрать его на одной стадии процесса, оно непременно появится на другой. Но одно бутылочное горлышко может соответствовать максимальной эффективности команды, а другое будет тормозить поставку вашей ценности заказчику. При этом заранее угадать на старте проекта, где будет ваше бутылочное горлышко — очень сложно.
Мы расскажем, как искали путь выхода из подобной ситуации. Почему при достаточном соотношении QA и DEV-инженеров в команде у нас сформировалось бутылочное горлышко на стадии тестирования. Как обсуждения пирамиды тестирования и распределения зон ответственности за качество продукта помогли избавиться от недоверия в команде и ускорить поставку ценности.
Будет полезно тем, кто ищет реальные кейсы по оптимизации процессов тестирования и хочет узнать, как построить работающий QA-процесс в условиях ограниченных ресурсов и быстро меняющихся требований.
В 2024 году наша команда приступила к изменению функционала системы раннего выявления проблем у корпоративных клиентов. Ядром этой системы является понятие сигнала. То есть, отражение в системе события, которое показывает, что у клиента могут возникнуть проблемы с обслуживанием долга. Например, информация о том, что компания пропустила платёж по кредитному договору или против нашего клиента возбудили арбитражное дело. Таких сигналов много и именно с их разнообразием связана основная сложность системы. Но сигналы позволяют запустить процессы внутри системы, с помощью которых можно минимизировать риск получения убытков связанных с обслуживанием клиента.
Как понять, что API отработало корректно? Как убедиться, что в ответе пришли нужные данные? И как использовать эти данные в следующих шагах, выстраивая сложные тестовые цепочки?
Именно здесь на сцену выходят post-response скрипты. Это код, который выполняется после получения ответа от сервера. Его основная задача – анализ, валидация и обработка полученных данных. Эти скрипты – ваши глаза и уши в мире API-тестирования, позволяющие автоматически проверять всё: от статус-кода до мельчайших деталей в теле JSON.
В этой статье мы рассмотрим 10 самых полезных post-response скриптов, которые превратят ручную проверку ответов в быстрый и надежный автоматизированный процесс. Давайте завершим наш путь к эффективному тестированию API!
Новые нейронки появляются чуть ли не еженедельно и каждая борется за первенство в лидербордах. Но есть и другой способ оценить их — например, с помощью необычных тестов. Мы в beeline cloud подобрали креативные бенчмарки: от рисования птиц на велосипедах до игр в духе логических загадок.
Привет, Хабр! Мы сотрудники Управления контроля качества компании Capital Group. Непосредственно участвуем в процессах тестирования программных продуктов, которые используются нашими менеджерами, работниками управляющих компаний, гостями и жителями ЖК CG.
Так как релизы наших приложений происходят почти еженедельно и нагрузка на ручных тестировщиков велика, в прошлом году мы внедрили автоматизацию регрессионных тестов. В этой статье расскажем о том, как мы настраивали запуск автотестов для мобильных устройств на реальном девайсе iOS.
Изначально такие автотесты писались и прогонялись на симуляторах, что довольно удобно: можно быстро собирать разные смартфоны и планшеты, проверять работоспособность приложения на различных версиях операционных систем и платформах. Тем не менее проверки должны быть максимально приближены к реальному пользовательскому сценарию взаимодействия с приложением, поскольку, в редких случаях могут возникать ошибки, которые не воспроизводятся на симуляторе. Поэтому, для получения более точных результатов тестирования было принято решение запускать автотесты на реальных устройствах. Со смартфоном Android все получилось быстро и безболезненно, но айфон заставил нас помучаться, этап подготовки показался долгим, сложным и запутанным.
Привет! Меня зовут Кристина, я тестировщик в ППК «Роскадастр» и ревьюер курса «Инженер по тестированию» в Яндекс Практикуме. В этой статье я расскажу, как правильно оформлять задачи в Jira — так, чтобы тестировщик сразу понял, что от него требуется, и выполнил работу без лишних уточнений и задержек.
Яндекс выпустил новую модель для Шедеврума, которая попыталась прикрыть уязвимости, которые эксплуатировались для создания «небезопасного контента» категории 18+. Тем не менее, не всё так радужно и с «детским» режимом они очень торопятся. Некоторые уязвимости в промпте остались, а некоторые добавились. Но самое интересное – попытка спастись от «небезопасного контента» путём целенаправленной порчи датасета. Обо всём этом подробно в тексте.
Статья Галины Шайдуровой
Психология тестировщика: почему критическое мышление – это суперсила
Привет, Хабр! Меня зовут Галина, я работаю QA-инженером в Ozon Tech. Если вы думаете, что тестировщики только ищут баги, то вы заблуждаетесь. Мы — не просто охотники за дефектами (хотя баги ловить умеем). Мы те, кто ежедневно выходит на поле боя против самого изощренного противника — нашего собственного мозга.
Вы обращали внимание на то, как легко не заметить очевидное? Например, когда вы ищете очки, а они у вас на голове. Теперь представьте, что тестировщик делает это на уровне сложных систем и интерфейсов, где каждая «потерянная пара очков» может обернуться тысячами разъяренных пользователей.
Сегодня хочу рассказать, почему критическое мышление — это суперсила любого тестировщика, ссылаясь на теории классиков, таких как Майерс Г. и Кейнер К. Мы разберем, как когнитивные искажения могут мешать находить баги, что помогает развивать аналитический подход, и как нестандартное мышление спасает проекты (и иногда ночной сон).
На работе (вне собственных пет-проектов) тестировщик никогда не существует в вакууме - он решает некоторые задачи бизнеса, а значит все решения должны приниматься с оглядкой на финансовую целесообразность. Иногда это противоречит внутреннему перфекционизму. Сегодня расскажу о некоторых неочевидных принципах автоматизированного тестирования, которые сводятся к тому, что иногда необходимо искать компромисс, а не следовать за тем самым перфекционизмом.
Привет, дорогой друг! Если ты связан с тестированием ПО, то знаешь, как важно иметь надежную и предсказуемую тестовую среду. А если ты ещё и отвечаешь за качество, то наверняка знаешь, как легко всё может пойти не так, если «стенд не поднялся» или «у нас тут staging = prod, но только чуть‑чуть». Сегодня давай попробуем разобраться, какие бывают тестовые среды, чем они отличаются, и зачем вообще они все нужны (и нужны ли?).
