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

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

Меня зовут Андрей, я веб-разработчик. Последние пару лет я, как и многие из вас, живу в состоянии лёгкого параноидального напряжения. Каждое обновление законодательства, каждый новый список запрещённых ресурсов — это не просто «ещё одна бюрократия», а реальный риск для бизнеса и репутации.

Штрафы за нарушение 152-ФЗ или размещение ссылок на экстремистские организации могут достигать 15 миллионов рублей. Блокировка домена — вопрос времени. А ведь на большинстве сайтов запрещённые элементы «вросли» в код на уровне CMS, шаблонов и CDN.

Я устал вручную искать url в консоли. Мне нужен был инструмент.

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

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

В прошлой части уже описали некоторые «внешние» инструменты (ссылка). Сегодня поговорим о возможностях внутри самих тестов.

Текст подготовлен по материалам выступления приглашенного спикера внутри компании.

Пошаговое руководство для Manual QA, которые хотят перейти в автоматизацию. Как выбрать направление, язык и инструменты, какие шаги пройти и что добавить в портфолио, чтобы уверенно расти в Automation QA.

Привет, Habr! Меня Женя Паршин, и я инженер по автоматизации тестирования, работающий преимущественно в e-commerce. В этой статье я расскажу, почему создание собственного фреймворка для автоматизации — это не "изобретение велосипеда", а практичное решение.

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

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

Одним из инструментов, предоставляющих возможность автоматизации данного вида тестирования, является Playwright.

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

В Postman есть возможность загружать данные из файла — указал в запросе «возьми имя из файла», сделал файл на 100 имен, и вуаля! Запускаешь 1 запрос, а он выполняется 100 раз с разными данными.

Так удобно готовить тестовые данные. Заранее прикинул классы эквивалентности, и создал всё одним махом. Нужно исправить? Вот он, файлик, в формате csv или json — легко читается, легко исправляется. 

А вот что с этим файликом делать дальше? Как сказать постману, что мы хотим подставить эти данные в запрос или в автотест? Где какой синтаксис использовать? Об этом и поговорим в статье на примере системы Users.

Если вы давно хотели разобраться с CI/CD, научиться запускать высоконагруженные API или наконец-то понять, как работают трансформеры в ML — вам сюда. В августе мы проведем 60 открытых уроков по ключевым темам разработки, архитектуры, безопасности, тестирования, анализа и управления.

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

Всем привет! На связи Арслан, тимлид команды тестирования компании «Совкомбанк Технологии». В этой статье я поделюсь опытом успешного внедрения методов искусственного интеллекта и больших языковых моделей (LLM) в тестирование программного обеспечения. 

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

Привет, Хабр! Я Святослав Волохов, QA-инженер в AGIMA. Тот, кто хоть раз тестировал сложный интеграционный сервис с десятками зависимостей и внешними API, да еще и в финтехе, знает — без грамотно выстроенной системы тестирования не обойтись.

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

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

Для улучшения работы инженера по обеспечению качества (QA) с помощью метрик и карты пути клиента (Customer Journey Map), важно понимать, как эти инструменты могут быть использованы для повышения качества продукта и минимизации ошибок на разных этапах разработки.

У него в резюме Python, Playwright, Pytest, Jenkins, Docker, Kafka, GitHub, GitLab, и он вёл QA-гильдию в Третьем Царстве. А потом пришёл на собес — и не смог объяснить, чем отличается UI-тест от интеграционного. Мы дали задачу. Он попытался её решить. Мы все плакали. Он — тоже.

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

До внедрения TMS процесс тестирования был довольно локальным — QA и команды внутри проектов самостоятельно определяли насколько плотно покрывать проверками функционал, где и как эти проверки хранить, какой выбирать формат для отчетов по регрессам. Такой подход имеет право на существование, но он не масштабируется, неудобен в случае усиления команды новыми участниками и совершенно непрозрачен для клиентов. Мы решили перейти от подхода «у каждого свое» к централизованной и прозрачной для всех стейкхолдеров системе.

Если ты уже начал осваивать тестирование, но Кафка для тебя — по-прежнему только чешский писатель, у нас плохие новости….

Но есть и хорошие! Сегодня мы поговорим про брокер сообщений Apache Kafka: из чего он состоит, как работает, зачем нужен и где применяется. А главное — разберем на конкретных примерах, как его можно протестировать.

Если вы работаете в тестировании, то Docker должен быть в вашем ежедневном инструменте так же прочно, как баг-репорт в Jira. Современный QA — это не просто “прокликать” интерфейс. Мы работаем с API, БД, UI-автотестами, моками и целыми микросервисами. А значит, нам нужно уметь быстро разворачивать изолированные и воспроизводимые окружения.

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

Привет, Хабр! На связи Сергей Зыбнев aka poxek. Начинал свой путь в багбаунти как сисадмин, потом заведовал WAF'ами в МТС, затем несколько пентестерских компаний,  а теперь работаю в Бастионе и профессионально ломаю то, что раньше защищал. Последние четыре года веду Telegram-канал Похек, где рассказываю про найденные уязвимости и про то, как можно было предотвратить их эксплуатацию.

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

Если хотите понять, какие инструменты выбрать и как эффективно применять их в реальных пентестах  — добро пожаловать под кат!

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

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

Если вы используете Allure, то знаете: отчёты могут быть разными: с фильтрами, деревом фич, ссылками на баги, а могут быть унылой простынёй из сотен тестов без смысла и структуры.

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

Ниже 6 уровней аннотаций, которые помогают держать тестовую базу в порядке. Без перегруза — только то, что действительно работает.