Представим, что вы разработчик на JavaScript, Ruby, Python или PHP. Ваш язык программирования не ищет ошибок во время компиляции. Собственно, у него компиляции, как таковой, нету. Если вы допустите синтаксическую ошибку, вы, конечно, о ней узнаете. Когда запустите программу. 
За каждым безупречным цифровым опытом стоит высокопроизводительный API. Независимо от того, работает ли ваш API для обработки потока покупок, медицинского дашборда или стриминговой платформы, проблемы с производительностью на уровне API могут повлиять на всю вашу систему — негативно влияя на скорость, надежность и доверие пользователей.
В этом руководстве мы рассмотрим типы тестирования производительности API, ключевые проблемы и решения, а также расскажем, как на основе метрик производительности принимать осмысленные решения.
Всего за пару недель мы создали инструмент, который превращает трудоёмкий процесс создания проверок в автоматизированный сценарий. Теперь, чтобы запустить тесты, мы делаем всего несколько кликов.
Тест-документация рождается в 5 раз быстрее, а свободное время инженеры используют для исследовательских тестирований, погружения в продукт и проработки нефункциональных требований. И всё это вместо монотонного создания проверок по требованиям.
Всем привет! На связи команда Take it easy. Название говорит само за себя: мы упрощаем жизнь другим командам в релизном цикле и повышаем эффективность производственного процесса.
В любой разработке много времени отнимает тестирование. Поэтому мы решили автоматизировать создание тестовых сценариев API, чтобы помочь тестировщикам. Применили ИИ-инструмент APISpecGen для анализа спецификаций новых API-требований, генерации соответствующих тестовых сценариев, обезличенных тестовых данных по схемам запрос/ответ и select-запросов с помощью GigaChat.
Что, если рутинную и трудоёмкую задачу по написанию тест-кейсов можно было бы поручить ИИ? Мы решили проверить, насколько хорошо ChatGPT справится с генерацией тест-кейсов на основе документа Software Requirements Specification (SRS) — спецификации требований к программному обеспечению. В эксперименте участвовали реальные студенческие проекты, а качество сгенерированных кейсов оценивали сами разработчики. В статье — методика, результаты и выводы о том, где ИИ оказался полезным, а где — всё ещё промахивается.
Тестирование игр — сложный и многоуровневый процесс, требующий не только внимательности, но и мощных инструментов, способных выявлять баги, проверять производительность, автоматизировать рутинные задачи и гарантировать стабильность работы. От браузерных игр до масштабных AAA-проектов — в каждой категории есть решения, способные упростить работу тестировщиков и разработчиков.
В этом обзоре, опираясь на свой многолетний опыт, я собрал самые надёжные инструменты для автоматизированного тестирования игр, которые будут полезны в различных ситуациях — от отладки сетевого трафика и проверки API до нагрузочного тестирования серверов и анализа производительности.
Привет, меня зовут Александр (aka bytehope). Прежде чем прийти к багхантингу, я пять лет занимался коммерческой разработкой. Однако меня всегда больше интересовал поиск уязвимостей, поэтому сейчас свое свободное время я провожу на площадках багбаунти.
Эту статью я решил посвятить уязвимостям, связанным с недостатками контроля прав (Broken Access Control). Вы узнаете, что это очень распространенный баг, который может проявляться самыми разными способами. Конечно, особый акцент будет сделан на практике: я покажу, как отловить четыре разных вида этой уязвимости в лабах Web Security Academy. Начнем с самых простых примеров, поэтому статья подойдет для начинающих охотников. Смело заглядывайте под кат!
Однажды я задумался, почему одни QA-инженеры застревают в мидлах, а другие — дорастают до CTO. Я исследовал эту тему, проводил интервью и пришёл к определённым выводам, которыми готов поделиться.
Дисклеймер: везде, где далее будет использован термин «тестировщики», можно подставлять «разработчики», «аналитики» и даже «менеджеры», ведь скилл-нутриенты полезны вообще всем айтишным специалистам.
Привет, Хабр! Я — Ольга Султанова, руководитель тестирования в Рунити. Сегодня я расскажу о QA-метриках, которые мы применяем в работе: как мы их внедряли, как собираем данные, как автоматизируем и анализируем. А также о том, какие у нас стоят пороговые значения и о том, какие действия мы предпринимаем, когда они нарушаются.
Привет, меня зовут Олег Уланов (aka brain). Я занимаюсь пентестами веб-приложений и активно участвую в багбаунти, зарабатывая на чужих ошибках. Свой путь в наступательной безопасности я начал совсем недавно, но, несмотря на это, меньше чем за год мне удалось ворваться в топ-10 исследователей на Standoff Bug Bounty (сейчас я на 5-м месте — можете проверить 😉).
В своем дебютном посте кратко расскажу об уязвимости с подделкой запросов на стороне сервера (SSRF) и ее видах, покажу, как обнаруживать этот баг и почему его стоит искать даже на статических сайтах, а заодно подсвечу особенности работы с Burp Suite, Collaborator Everywhere и Wappalyzer. Статья будет полезна для прокачки скилов и поможет легче и быстрее обнаруживать SSRF в сервисах, размещенных на площадках багбаунти.
Когда я только начинала работать тестировщиком, снифферы трафика казались мне чем-то далеким. В голове было что-то типа: "Ну, это для тестировщиков мобилок и для разработчиков. Мне оно не надо". Но потом я постепенно начала их использовать и поняла, что сниффер это маст хэв вещь в некоторых случаях!
В этой статье расскажу о нескольких кейсах, где снифферы трафика могут реально сохранить кучу времени и некоторое количество нервов. Let's go!
