Если вы работаете в тестировании, то Docker должен быть в вашем ежедневном инструменте так же прочно, как баг-репорт в Jira. Современный QA — это не просто “прокликать” интерфейс. Мы работаем с API, БД, UI-автотестами, моками и целыми микросервисами. А значит, нам нужно уметь быстро разворачивать изолированные и воспроизводимые окружения.
В этой статье — сжатая, но насыщенная шпаргалка по Docker-командам, которые особенно полезны тестировщику.
Привет, Хабр! На связи Сергей Зыбнев aka poxek. Начинал свой путь в багбаунти как сисадмин, потом заведовал WAF'ами в МТС, затем несколько пентестерских компаний, а теперь работаю в Бастионе и профессионально ломаю то, что раньше защищал. Последние четыре года веду Telegram-канал Похек, где рассказываю про найденные уязвимости и про то, как можно было предотвратить их эксплуатацию.
В этой статье — главные инструменты для поиска уязвимостей, которые я использую в ежедневной работе. Это не подборка ради подборки: для каждого инструмента приведу пример из собственной практики, чтобы было понятно, где и как их применять.
Если хотите понять, какие инструменты выбрать и как эффективно применять их в реальных пентестах — добро пожаловать под кат!
Тестирование — важнейший аспект разработки программного обеспечения, особенно для веб‑приложений. В Go тестирование встроено в язык и предоставляет мощные инструменты для написания и выполнения тестов. В этой статье мы рассмотрим поток веб-приложения на Go, как писать модульные тесты для каждого слоя приложения.
Автоматизация тестирования с Cypress становится всё популярнее, а кастомные команды — одним из ключевых инструментов для повышения читаемости, переиспользуемости и поддерживаемости тестов. В этой статье разберём, что такое кастомные команды, почему Cypress рекомендует отказаться от классического Page Object Model (POM), а также рассмотрим, как грамотно организовать и структурировать свои команды.
Если вы используете Allure, то знаете: отчёты могут быть разными: с фильтрами, деревом фич, ссылками на баги, а могут быть унылой простынёй из сотен тестов без смысла и структуры.
Всё зависит от того, как вы помечаете тесты. Allure даёт мощную систему аннотаций, и если её использовать с умом — отчёт превращается в полноценный инструмент для анализа и коммуникации.
Ниже 6 уровней аннотаций, которые помогают держать тестовую базу в порядке. Без перегруза — только то, что действительно работает.
За каждым безупречным цифровым опытом стоит высокопроизводительный API. Независимо от того, работает ли ваш API для обработки потока покупок, медицинского дашборда или стриминговой платформы, проблемы с производительностью на уровне API могут повлиять на всю вашу систему — негативно влияя на скорость, надежность и доверие пользователей.
В этом руководстве мы рассмотрим типы тестирования производительности API, ключевые проблемы и решения, а также расскажем, как на основе метрик производительности принимать осмысленные решения.
Обычно специалисты, особенно начинающие, смотрят только в код. Но настраивая процессы автоматизированного тестирования, стоит отрываться от кода и внимательнее смотреть на процессы — именно тут кроется плодородная почва для оптимизации.
В двух частях этой статьи расскажем о вариантах оптимизации тестирования, которые можно применить как внутри тестов, так и, условно, снаружи, т. е. в обертках и прочих внешних инструментах. Сегодня поговорим о «внешних» инструментах.
Текст подготовлен по материалам выступления приглашенного спикера внутри компании.
Разбираемся, как организовать нагрузочное тестирование на Python с Locust — с сидинговыми сценариями, кастомными API-клиентами на HTTPX, конфигурацией через Pydantic и автоматическим запуском в GitHub Actions. Всё — на практике, с архитектурой, фреймворком и публикацией отчётов в GitHub Pages.
Поиск работы в IT — настоящий «чёрный ящик». Мы рассылаем резюме, проходим созвоны, получаем странные вопросы и туманные отказы. Что на самом деле происходит в голове у рекрутера? Почему один и тот же ответ где-то вызывает восторг, а где-то — вежливое «мы вам перезвоним»?
Чтобы пролить свет на этот процесс, мы разобрали более 10 часов записей живых, нефильтрованных эфиров с QA-практиками. В роли наших проводников выступят:
Lead QA Ада Ширченко (7+ лет в QA), Senior QA Юлия Самусева (8+ лет в QA) и Middle+ QA Евгений Гусинец (3+ лет в QA)
Это были не лекции, а честные диалоги, где начинающие тестировщики задавали самые наболевшие вопросы. Мы скрупулезно проанализировали эти разговоры и упаковали их в серию статей. Представляем наш «Сезон 1» — полный путь джуна от первого резюме до заветного оффера.
Мы не нашли свежего исследования про QA и решили: нужно делать своё. Так появилось наше первое большое огромное исследование про QA в России.
Что внутри?
— Как работают в QA: какие процессы, инструменты и подходы используют.
— Зачем тестировщики работают: мотивация, удовлетворённость сферой и зарплатой.
— Будущее QA: как инженеры видят развитие профессии и какую роль в этом сыграет AI.
Приправили статистику комментариями ребят из сообщества.
Под катом собрали несколько важных инсайтов. С полной версией исследования можно ознакомиться по ссылке: https://qa-survey-2025.2gis.ru
В предыдущих статьях я приводила примеры применения техники тест‑дизайна «таблица решений» для тестирования фронтовых фич и алгоритмов. В этой статье я хочу привести пример, как применять таблицу решений для тестирования скриптов.
Такое представление тестов экономит время на расписывание большого количества тест‑кейсов, придает проверкам наглядность и облегчает их поддержку и расширение в будущем.
Приветствую читателей моей статьи!
В тестировании я уже 8 лет. Начала тогда, когда это еще не было мейнстримом :-)
Однако, сегодня эта профессия стала очень популярной и, по слухам, новичкам практически невозможно начать карьеру в этом поприще. Многие ребята сталкиваются с проблемой «донести» свое резюме до компании и попасть на собеседование. Поэтому я решилась на эксперимент и опубликовала резюме новичка без опыта работы на hh.ru, чтобы посмотреть – получится ли получить обратную связь.
Итак, входные данные.
Я взяла реальную историю и описала свои знания и навыки 15 летней давности т.е. на момент выпуска из колледжа.
Привет, Хабр! Чтобы не вводить никого в заблуждение, кратко перескажу, о чём пойдёт речь. Если тема будет вам близка или вы сталкивались с подобным, буду рад узнать ваше мнение и послушать советы.
Краткий пересказ:
Как я/мы в компании создаём процесс тестирования практически с нуля. Какие шаги предпринимались и как вообще получается в современном мире существовать без тестирования.
Вводные данные:
Я — QA, который работает в средней по размерам IT-фирме, которая, в свою очередь, является «дочкой» довольно крупной промышленной компании и обеспечивает поддержку и разработку внутренних систем. Когда я только пришёл, помимо меня был только один тестировщик на ~15 разработчиков. Ни о каком адекватном процессе тестирования речи и не шло.
Работа осуществляется в рамках спринтов по две недели. Задачи, выполненные разработчиками, проверяются во время ревью более крутыми разработчиками, затем мерджатся и раскатываются на тестовый стенд, где уже их проверяет аналитик на соответствие требованиям.
В целом, кажется, ничего плохого нет — две линии проверки. Вот только количество багов явно было больше запланированного, а это, в свою очередь, вызывает ночной кошмар любого менеджера: сдвиг сроков.
Было принято решение взять нескольких тестировщиков, да не просто каких-то, а с навыками автоматизации, чтоб оно всё там как-то само.
Так я, собственно, и попал в команду — молодой и неопытный. На самом деле, не настолько всё было плохо: разработчики работали по TDD, так что unit-тестов хватало, и пайплайны отрабатывали автоматически. Да, не было тестирования как процесса, но ведь давным-давно, в далёкой-далёкой галактике, именно так и начиналось программирование.
Всего за пару недель мы создали инструмент, который превращает трудоёмкий процесс создания проверок в автоматизированный сценарий. Теперь, чтобы запустить тесты, мы делаем всего несколько кликов.
Тест-документация рождается в 5 раз быстрее, а свободное время инженеры используют для исследовательских тестирований, погружения в продукт и проработки нефункциональных требований. И всё это вместо монотонного создания проверок по требованиям.
Пользователи GitHub часто используют принудительные пуши (git push --force), чтобы переписать историю коммитов — например, когда случайно закоммитили секреты и хотят удалить их из репозитория.
На первый взгляд кажется, что коммит исчез, но на самом деле GitHub его не стирает. «Удаленный» коммит остается доступен по хэшу — пусть и без прямых ссылок. GitHub продолжает хранить такие коммиты вечно.
В статье покажу, как вычислял такие коммиты с помощью GitHub Archive и вытаскивал из них секреты, за которые мне выплатили $25 000 по багбаунти. А еще поделюсь open-source инструментом, который позволит вам самостоятельно искать подобные утечки.
Признаемся честно: слово «тестирование» вызывает у многих разработчиков примерно такую же радость, как поход к стоматологу. Большинство морщится и думает: «Опять эти тесты... Лучше бы новую фичу запилил!» И я вас прекрасно понимаю — сам когда-то был в лагере скептиков.
Но после нескольких лет руководства командой фронтенда, десятков ночных дебагов и сотен часов, потраченных на поиск неуловимых багов, я пришёл к неожиданному выводу: качественные юнит-тесты — это не якорь, замедляющий разработку, а реактивный двигатель, ускоряющий её.
В этой статье я расскажу, почему наша команда делает ставку именно на юнит-тесты, и как они могут превратить вашу разработку из хаотичного забега с препятствиями в уверенный марафон с чёткими ориентирами.
При работе со сквозным тестированием (E2E, end-to-end) в Playwright критическое значение имеет поддержание упорядоченной и масштабируемой тестовой базы. Хорошо организованная структура не только улучшает поддерживаемость, но и облегчает адаптацию новых коллег. В этой статье мы рассмотрим, как организовать тесты в Playwright наилучшим образом, начиная со структуры папок и заканчивая использованием хуков, аннотаций и тегов.
Как понять, что API отработало корректно? Как убедиться, что в ответе пришли нужные данные? И как использовать эти данные в следующих шагах, выстраивая сложные тестовые цепочки?
Именно здесь на сцену выходят post-response скрипты. Это код, который выполняется после получения ответа от сервера. Его основная задача – анализ, валидация и обработка полученных данных. Эти скрипты – ваши глаза и уши в мире API-тестирования, позволяющие автоматически проверять всё: от статус-кода до мельчайших деталей в теле JSON.
В этой статье мы рассмотрим 10 самых полезных post-response скриптов, которые превратят ручную проверку ответов в быстрый и надежный автоматизированный процесс. Давайте завершим наш путь к эффективному тестированию API!
Привет! Меня зовут Кристина, я тестировщик в ППК «Роскадастр» и ревьюер курса «Инженер по тестированию» в Яндекс Практикуме. В этой статье я расскажу, как правильно оформлять задачи в Jira — так, чтобы тестировщик сразу понял, что от него требуется, и выполнил работу без лишних уточнений и задержек.
Статья Галины Шайдуровой
Психология тестировщика: почему критическое мышление – это суперсила
Привет, Хабр! Меня зовут Галина, я работаю QA-инженером в Ozon Tech. Если вы думаете, что тестировщики только ищут баги, то вы заблуждаетесь. Мы — не просто охотники за дефектами (хотя баги ловить умеем). Мы те, кто ежедневно выходит на поле боя против самого изощренного противника — нашего собственного мозга.
Вы обращали внимание на то, как легко не заметить очевидное? Например, когда вы ищете очки, а они у вас на голове. Теперь представьте, что тестировщик делает это на уровне сложных систем и интерфейсов, где каждая «потерянная пара очков» может обернуться тысячами разъяренных пользователей.
Сегодня хочу рассказать, почему критическое мышление — это суперсила любого тестировщика, ссылаясь на теории классиков, таких как Майерс Г. и Кейнер К. Мы разберем, как когнитивные искажения могут мешать находить баги, что помогает развивать аналитический подход, и как нестандартное мышление спасает проекты (и иногда ночной сон).
