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

Всем привет! Меня зовут Ксения и я вот уже почти 9 лет в тестировании. Не так давно поймала себя на мысли, что мой аккаунт на Хабре совсем запылился. А ведь за годы работы у меня было достаточно много опыта на различных позициях от ручного тестировщика до руководителя и мне действительно есть чем поделиться. Так и пришла в мою голову мысль поднять в очередной раз тему развития в тестировании. Мне кажется, что эта тема будет актуальна всегда. Эта статья будет первой, в планах у меня уложиться в три, но там уж как пойдет. 

Привет, Хабр! Меня зовут Женя, я SDET в «Островке». В этой статье расскажу, как мы решали задачу интеграции автотестов в CI/CD, когда тесты и код живут в разных репозиториях.

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

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

Давайте разберем два подхода к интеграции DeepEval с LlamaIndex Workflow:

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

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

Привет, Хабр! С вами снова Ольга Султанова, руководитель отдела тестирования Рунити. В этот раз расскажу, как мы автоматизировали рутинные задачи в нашем отделе с помощью собственного бота, сократили работу над почти десятью мелкими задачами, сосредоточились на более важных делах и стали регулярно отмечать дни рождения в команде. А еще подсветим проблемы. Статья будет полезна, прежде всего, тимлидам, тестировщикам и разработчикам. Подробности под катом.

В этой статье разберём процесс написания API автотестов на Python, используя современные best practices. Кроме того, мы настроим их запуск в CI/CD с помощью GitHub Actions и сформируем Allure-отчёт с историей запусков. Цель статьи — не только показать, как писать качественные API автотесты, но и научить запускать их в CI/CD, получая удобные отчёты о результатах.

Хабр, привет! Меня зовут Денис, я ведущий тестировщик в крупном банке, а ещё недавно — выпускник курса «Инженер по тестированию» в Яндекс Практикуме. В этом материале я расскажу, как «вкатывался» в IT после работы директором сетевого супермаркета и внедрял Scrum в ростовской агропром-компании, а ещё — как не опустил руки в поисках первого оффера (хотя очень хотелось).

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

Меня зовут Елена Пранова. Я инженер по автоматизации тестирования в ОК. В этой статье я расскажу об автоматизации проверок логирования в ОК, особенностях работы с Kafka, написании тестов для проекта статистики и не только.

Всем доброго времени суток! При работе над проектом мне и команде пришлось тестировать передачу сообщений по протоколу STOMP через WebSocket соединение. Обычно для таких задач я использую Postman, который, поддерживает установление WebSocket-соединений, хоть и в beta-версии. Однако при тестировании я столкнулся с проблемой: согласно спецификации STOMP, в конце каждого фрейма должен находиться нулевой байт (NULL, 00). При этом при отправлении сообщения через Postman нулевой байт не передается корректно. В этой статье я расскажу о причинах этой проблемы и о найденным мной решении.

Когда речь идет о браузерных расширениях для веб-тестирования, перед тестировщиком открывается огромное количество инструментов. Однако большинство из них (около 90%) предназначены исключительно для ручного тестирования. Лишь небольшая часть расширений помогает автоматизировать тестирование без навыков программирования, и совсем немногие действительно специализируются на поддержке автоматизированных тестов.

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

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

Меня зовут Сергей Лебедев, я QA Lead в Яндекс Лавке. И сегодня я расскажу как подготовиться к интервью, если у вас мало или совсем нет опыта в найме и отборе кандидатов. Какие вопросы задавать, как анализировать ответы кандидатов и принимать взвешенные решения, чтобы собеседование проходило комфортно и эффективно для всех участников.

Неприятная ситуация: продукт проходит тщательную проверку на всех этапах разработки, а после релиза всё равно возникают неожиданные ошибки… А ведь это происходит, потому что тестирования на ранних стадиях (shift-left testing, «влево») не всегда достаточно, чтобы гарантировать стабильность продукта. Поэтому важно учитывать и тестирование в продакшене (shift-right testing, «вправо»). 

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

Всем привет!
В этой серии из нескольких статей мы разберемся, что делать тестировщику на проекте с кафкой (как впервые, так и имея какой-то опыт). Здесь я не буду говорить о брокерах и zookeeper-ах, о том, как развернуть кафку. Но мы разберемся, как её настроить и как с её помощью тестировать ваши микросервисы.

Начнём с «базы» (точнее, теории).
Apache Kafka — распределённый программный брокер сообщений с открытым исходным кодом, разрабатываемый в рамках фонда Apache на языках Java и Scala.

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

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

С какими сложностями мне пришлось столкнуться... Ну во первых пришлось немного полазить в доке постмана, но там только поверхностно описано, не смог найти как сделать запрос. Гуглёж вопросов других бедолаг мне тоже не особо помог, т.к. там были немного другие кейсы.

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

Итак исходное положение. Имеем некую коллекцию запросов в постмане и все креды для авторизации сохранённые в переменных.

У нас есть запрос Auth, который получает токен авторизации.

Статья нацелена в первую очередь на PHP backend-разработчиков уровня junior/middle, чтобы познакомить с теорией, которую спрашивают на собеседованиях, и с практическими примерами/советами, полезными для разработки.

Здесь хочу рассказать зачем вообще тестировать код, какие инструменты использовать, какие есть паттерны и тп.

Долго сидела девица и думала: что такого она умеет делать, за что ей платят денюжку. И тут осознала, запускать крупные стрессовые проекты. Быть QA для тревожника - это ну мед, медятина. А если еще ты вечная стартапница, кортизоловые горки обеспечены. Так как браться за объемные проекты, которые нужно было сделать "еще вчера" и при этом не отъезжать в отпуск в пнд?

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

А еще тут набор базовых правил, которые в принципе и так известны человечеству, но как и в случае здорового образа жизни лишним не будет проговорить о главных принципах (иначе откуда было бы столько коучей в нашем времени)?

Смоделируем ситуацию:

Автоматизация тестирования, которая не ломается при первом редизайне

Как мы проектировали, внедряли и поддерживаем живую систему автотестов

Как использовать в тестировании ИИ? Как тестировать сам ИИ? И главное: как не завязнуть в излишнем хайпе вокруг ИИ, а совершенствоваться и в «нехайповых» темах вроде безопасности или нагрузки?

Мы уже много лет проводим конференцию по тестированию Heisenbug. Если посмотреть, как менялась программа с годами, получится срез актуальных для индустрии вопросов, который постепенно изменялся со временем. Например, можно проследить, как с определённого момента среди тем появилось название Playwright, и никуда уже не делось (вот и в этот раз встретится).

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

В программу ещё вносят последние детали, и отдельные доклады здесь не описаны — пусть тогда они будут секретом-сюрпризом.

Привет, Хабр!

Cегодня рассмотрим то, как мокировать зависимости в Go. Мокирование — это замена реальных зависимостей на предсказуемые заглушки для изолированного и быстрого тестирования. Вместо реальной БД или внешнего API подставляем stub, mock или fake, которые возвращают заранее определённые результаты или фиксируют вызовы. В Go это реализуется через интерфейсы и dependency injection: определяется контракт (интерфейс) и используем его в коде, а в тестах подставляем нужную заглушку.