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

Что, если рутинную и трудоёмкую задачу по написанию тест-кейсов можно было бы поручить ИИ? Мы решили проверить, насколько хорошо ChatGPT справится с генерацией тест-кейсов на основе документа Software Requirements Specification (SRS) — спецификации требований к программному обеспечению. В эксперименте участвовали реальные студенческие проекты, а качество сгенерированных кейсов оценивали сами разработчики. В статье — методика, результаты и выводы о том, где ИИ оказался полезным, а где — всё ещё промахивается.

Представьте, что вы — повар в ресторане. Вы приготовили новое блюдо, но не пробуете его перед подачей гостю. Результат? Клиент может отравиться или остаться недоволен вкусом. Точно так же в программировании: без проверки код может содержать ошибки, которые проявятся в самый неподходящий момент. Unit-тесты — это как дегустация блюда перед подачей. Они проверяют отдельные части кода (методы, классы) на корректность, чтобы вы были уверены: всё работает так, как задумано.

Но это не простые разработчики, а те, кто будет выступать завтра с докладами на нашем ежегодном бесплатном митапе Frontend Mix. 😎 Ребята расскажут про рефакторинг приложений за 10 секунд, стандарты тестирования во фронтенде, анимацию и уязвимости в финтехе. Ссылка на страницу конференции и регистрацию будет ниже, а пока оценим ответы на вопросы ИИ. 👇

С каждым днем все больше продуктов создается и запускается с помощью ИИ.
К сожалению, с безопасностью у них пока не очень.

Как понять, что реально делают ваши UI автотесты?

ui-coverage-tool — это инновационный инструмент нового поколения, не имеющий аналогов. Он визуализирует покрытие прямо в браузере, работая с реальным приложением. История по каждому элементу, фильтры по действиям, динамика и полная наглядность — всё, чтобы не просто тестировать, а понимать и улучшать.

Разбираем, как писать масштабируемые и читаемые UI автотесты на Python с использованием паттернов PageObject, PageFactory и PageComponent. Разберем на атомы как устроены эти подходы, когда их применять и чем они отличаются. Всё это — на примере тестового проекта UI Course с CI/CD и наглядными отчетами в Allure.

Как начать работу над проектом, написать тестовую документацию, понять, когда и как переходить к автоматизации… и выжить?

Работа QA всегда связана с множеством документации— и это часто утомляет. И мне, как ленивому человеку и QA, хочется ускорить и автоматизировать все, что сделает мою (а возможно и вашу) работу легче и приятнее. 

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

Ты – тестировщик. А знаешь ли ты свой уровень? А главное — знаешь, куда двигаться дальше?

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

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

Сегодня разберёмся, почему без autospec=True ваш безобидный @patch из unittest.mock может превратить зелёный репорт в мину замедленного действия.

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

Игра по своим правилам. Рассказываю, как с помощью DevTools и нестандартных методов можно выйти на первое место в Telegram MiniApp.

Работая с монорепозиториями на Nx, часто возникает необходимость получить единый отчёт о покрытии кода. Однако по умолчанию каждый проект генерирует отдельный файл, что затрудняет анализ. В этой статье расскажем, как с помощью nyc-merge объединить все отчёты в один.

Тестирование — это наука не о том, чтобы доказать, что программа работает корректно, а о том, чтобы доказать, что она работает НЕкорректно. И если доказать это не удалось, то с какой-то вероятностью программа работает корректно. Остается некоторый пробел. Давайте рассмотрим, что за это за пробелы, откуда берутся и как можно их минимизировать.

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

Это вторая часть статьи о Kafka (первая тут). Давайте продолжим разбираться.

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

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

Всем привет, меня зовут Стас, я техлид в Mish Product Lab.

Тема возникла не просто так: внутри команды у нас было немало споров и дискуссий о том, какой инструмент для проксирования и терминации SSL лучше использовать в различных ситуациях. Изначально все наши гипотезы были основаны больше на личных предпочтениях, чем на реальных данных. Мы долго спорили, надеясь, что истина будет где-то рядом с нашими любимыми решениями. Но в итоге пришли к выводу, что единственный способ получить действительно объективный ответ — это протестировать и сравнить различные варианты на практике.

Именно так родилась идея провести сравнительный анализ производительности HAProxy, Envoy, Nginx, Caddy и Traefik с поддержкой SSL/TLS. Мы хотели понять, какой из инструментов «из коробки» предоставляет наилучшую производительность и минимальные накладные расходы, особенно при обработке SSL-трафика, который, как известно, требует дополнительных ресурсов из-за шифрования и дешифрования.

Всем привет! Меня зовут Ксения. В предыдущей статье я рассказывала вам о своем подходе к построению карты компетенций для команды тестирования. Там я описала зачем нужна карта компетенций, как можно подойти к ее построению и как провести оценку.

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

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

В воспитании детей есть интересный каламбур: если вы в любой момент времени не знаете, чем заняты ваши дети, то, возможно, это уже не ваши дети. Перефразируя под процессы обеспечения качества в проекте, можно сказать: если вы не знаете, чем занимаются ваши QA‑инженеры, и не внедрили метрики в проекте, то, возможно, это уже не ваш проект?

Меня зовут Илья я лид тестирования в проекте Сбер Диск. Про управление командой тестирования поговорим как‑нибудь в другой раз. А сейчас мне хотелось бы обсудить именно метрики тестирования.

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

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

Всем привет! Попарное тестирование (pairwise testing) - одна из самых распространённых техник тест дизайна. Уверена, вы уже про неё читали в книгах, сертификациях, статьях…

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