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

Что должен знать и уметь успешный тестировщик? Знания и опыт не появляются сами по себе: у каждого QA есть свои книги, статьи и ресурсы, которые помогли ему начать и освоиться в сфере тестирования.

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

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

При этом инструмент предлагает «единый вид всех элементов бэклога — будь то баг или задача по новому функционалу», что помогает приоритизировать общие цели команды. Это значит, что QA могут иметь в Jira общее пространство тест‑кейсов, задач на тестирование и найденных дефектов.

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

Статья будет полезна для всех участников QA‑команд (тестировщиков, тимлидов), кто базово уже разбирается с инструментом и хочет в него углубиться.

Привет, меня зовут Роман Поляков, я инженер по тестированию (QA-самурай) в Т1 Иннотех. В мире ручного функционального тестирования каждый день идёт битва за качество. Смена требований, пропущенные баги, плотные дедлайны и тонны тестовых сценариев могут сломить даже опытного специалиста. Но настоящий QA-самурай не сдаётся. Он превращает рутину в искусство, а стресс — в топливо для роста.

Если вы когда-нибудь думали, что работа QA — это просто сидеть и нажимать на кнопки в надежде, что баги сами обнаружатся, то… вы немного заблуждались! Добро пожаловать в увлекательный и порой весьма запутанный мир тестирования, где каждый день сулит встречу с новыми подводными камнями, ловушками и, конечно же, классическими граблями на пути к качественному продукту.

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

Привет! Продолжаем разбирать малоизвестные, но крайне полезные фичи Chrome DevTools. Меня зовут Святослав Ященко, я тимлид QA-команды Platform V Kintsugi. Это графическая консоль для сопровождения PostgreSQL и Postgres-like СУБД. Ранее я писал о том, как подменить трафик в DevTools. Сегодня покажу, как тестировать производительность web-приложения, не выходя из Chrome. 

Наш продукт — высоконагруженный, как в части бэкенда, так и в части фронтенда. БольшУю нагрузку на web-часть дают графики метрик наблюдаемых баз данных. Нагрузочное тестирование бэкенда в нашей команде — тема отдельной статьи, но об этом постараюсь рассказать в другой раз, а сейчас протестируем производительность фронтенда. Добро пожаловать под кат.

В этом тексте расскажем, как мы за две недели собрали MVP генератора тест-кейсов на базе GenAI для компании IT Media Service. До этого ребята вручную писали сотни тест-кейсов и автотестов к каждому релизу, тратили на это тонны времени, а автоматизация требовала улучшения. 

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

Что происходит с QA-индустрией и куда она движется? Действительно ли профессия умирает или у неё есть будущее?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пользователи GitHub часто используют принудительные пуши (git push --force), чтобы переписать историю коммитов — например, когда случайно закоммитили секреты и хотят удалить их из репозитория. 

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

В статье покажу, как вычислял такие коммиты с помощью GitHub Archive и вытаскивал из них секреты, за которые мне выплатили $25 000 по багбаунти. А еще поделюсь open-source инструментом, который позволит вам самостоятельно искать подобные утечки.

При работе со сквозным тестированием (E2E, end-to-end) в Playwright критическое значение имеет поддержание упорядоченной и масштабируемой тестовой базы. Хорошо организованная структура не только улучшает поддерживаемость, но и облегчает адаптацию новых коллег. В этой статье мы рассмотрим, как организовать тесты в Playwright наилучшим образом, начиная со структуры папок и заканчивая использованием хуков, аннотаций и тегов.

Статья Галины Шайдуровой

Психология тестировщика: почему критическое мышление – это суперсила

Привет, Хабр! Меня зовут Галина, я работаю QA-инженером в Ozon Tech. Если вы думаете, что тестировщики только ищут баги, то вы заблуждаетесь. Мы — не просто охотники за дефектами (хотя баги ловить умеем). Мы те, кто ежедневно выходит на поле боя против самого изощренного противника — нашего собственного мозга.

Вы обращали внимание на то, как легко не заметить очевидное? Например, когда вы ищете очки, а они у вас на голове. Теперь представьте, что тестировщик делает это на уровне сложных систем и интерфейсов, где каждая «потерянная пара очков» может обернуться тысячами разъяренных пользователей.

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

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

В этой статье мы рассмотрим, как Playwright MCP (Model Context Protocol) в режиме агента может автономно исследовать приложение, обнаруживать ключевые функции и генерировать исполнимые тесты — без необходимости в ручном скриптинге.

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

Если вы ежедневно работаете с API-тестированием и используете Postman, то наверняка сталкиваетесь с повторяющимися задачами: ручное получение и обновление токенов авторизации, изменение параметров запросов для разных сред разработки, копирование данных из ответов для использования в следующих запросах. Эта рутина отнимает время и силы, а также увеличивает вероятность ошибок. Что если большую часть этих действий можно автоматизировать?

В этой серии из двух статей мы пошагово разберем 10 самых полезных pre-request и 10 post-request скриптов, которые, по моему опыту, являются наиболее востребованными при тестировании API, особенно для начинающих QA инженеров. В этой и следующей статьях выполнено ранжирование этих скриптов по их важности и частоте использования, чтобы вы могли сразу осваивать и применять на практике самые необходимые из них. Каждый из 20 скриптов будет сопровождаться простым, понятным примером кода на JavaScript, готовым к применению, а также примерами из практики.