И не говорите, что это не вы 😍

🐸 Библиотека тестировщика

#развлекалово

🙄 Переписывать старые тесты или улучшать текущие

Когда тесты устаревают или начинают давать ложные срабатывания, встает вопрос: что с ними делать?

➡️ Какие плюсы переписывания с нуля:

Учёт новых технологий и подходов, улучшение структуры и читаемости

➡️ Минусы:

Требует значительных временных затрат и существует риск ошибок в новых тестах

➡️ Какие плюсы улучшения существующих тестов:

Быстрая корректировка, экономия времени и легкость в поддержке

➡️ Минусы:

Ограничения старой архитектуры и потенциальная неэффективность

Как подходите вы Переписываете или улучшаете тесты? Пишите в комментариях ✏️

🐸 Библиотека тестировщика

#междусобойчик

🟣 Подборка материалов по тестированию микросервисов в Docker-контейнерах

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

➡️ Как тестировать микросервисы с использованием Docker: основные подходы и инструменты для создания и тестирования изолированных контейнеров с микросервисами

➡️ Практика тестирования контейнеризированных микросервисов: как использовать Docker Compose для организации тестовых окружений для микросервисов и управления их зависимостями

➡️ Нагрузочное тестирование микросервисов в Docker: как проводить нагрузочные тесты в контейнеризованных микросервисах, оценивая их производительность под различными условиями

➡️ Тестирование безопасности микросервисов в Docker: как проводить безопасность контейнеров, включая проверку образов на уязвимости и правильную настройку доступа

➡️ The Best Way To Use Docker For Integration Testing In .NET: видеогид показывает, как использовать контейнеры для тестирования интеграции микросервисов в .NET-приложениях

🐸 Библиотека тестировщика

#свежак

❓ Что происходит, когда вы вводите URL

Когда вы открываете сайт, браузер запускает целую цепочку сетевых шагов — подключение, запрос, обработка, ответ.

Чтобы находить ошибки на стыке клиента, сервера и сети, важно понимать эту последовательность.

Разберемся с этим на практике — в формате опроса👇

🐸 Библиотека тестировщика

#междусобойчик

🥖 Топ-вакансий для тестировщиков за неделю

QA Automation Engineer Python — удаленно (Москва)

QA специалист-тестировщик — от 1500 ₽/час, удаленно (Челябинск)

QAA Lead — удаленно/гибрид (Москва)

Automation Mobile QA Enginer — 260 000 ₽, удаленно

Инженер по нагрузочному тестированию — от 200 000 ₽ до 420 000 ₽, удаленно (Москва)

➡️ Еще больше топовых вакансий — в нашем канале QA jobs

🐸 Библиотека тестировщика

#свежак

📌 Шпаргалка по CDN и кэшированию

Содержит ключевые моменты для тестирования взаимодействия с Content Delivery Network (CDN), включая:

➡️ Обработку запросов

➡️ Кэширование и отказоустойчивость

Это поможет при тестировании системы и выявлении проблем с недоступностью серверов.

🐸 Библиотека тестировщика

#буст

⭐️ Как ускорить регрессионное тестирование под CI/CD

Регресс при частых релизах часто тормозит процесс. Чтобы этого избежать, нужна быстрая и прицельная проверка.

Почему важно:

📍 Ручной тест не поспевает за релизами

📍 Тестируются не те участки, где чаще всего возникают баги

📍 Без приоритезации снижается доверие к стабильности

Что делать:

1️⃣ Разделяем регрессию на уровни

— Smoke (5–10 ключевых кейсов) — быстрое подтверждение работоспособности

— Sanity — базовая проверка новых фич

— Полный регресс — по расписанию или при крупных релизах

📌 Используйте отдельные теги/группы в TestRail, Allure, Xray, Testomat или CI-джобах

2️⃣ Применяем Risk-Based Testing

— Расставьте приоритеты: что критично при падении

— Анализируйте, где чаще всего бывают баги

— Используйте баг-репорты и ретроспективы для корректировки регрессии

📌 Визуализируйте покрытие: high risk vs. low impact

3️⃣ Интегрируем регрессию в CI/CD пайплайн

— Запускайте smoke-тесты на каждом pull request

— Основной регресс — раз в сутки/неделю (ночной запуск)

— Используйте флаги @smoke, @critical, @release

📌 Инструменты: Jenkins, GitLab CI, Allure TestOps, TestCafe, Playwright

4️⃣ Ускоряем: параллельность и селективный запуск

— Делайте параллельные джобы (разделение по модулям или фреймворку)

— Используйте dependency-based запуск (only tests affected by changes)

📌 Системы: knapsack, Test Impact Analysis, Git diff + tag фильтры

5️⃣ Автоматизируем отчеты и оповещения

— Результаты тестов сразу в Slack, Telegram или JIRA

— Покрытие и статус регресса — в дашборде

— Быстрый фидбек команде при падении

💡 Советы:

— Не пытайтесь автоматизировать весь регресс — автоматизируйте главное

— Поддерживайте живой список приоритетных тестов — и регулярно пересматриваййте

— Комбинируйте ручной и автоподход: часть регресса можно проверять exploratory

🐸 Библиотека тестировщика

#буст

Страшно спросить, но еще страшнее не понять 🔥

🐸 Библиотека тестировщика

#развлекалово

🌟 Как превратить сценарий теста в готовый Selenium-скрипт

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

Промпт:

Act as a QA automation engineer.
Write a Selenium test in [Python/Java/JS] using [pytest/JUnit/etc.] that automates the following scenario:
[вставь шаги теста: открыть страницу, заполнить форму, проверить сообщение].
Добавь комментарии, обработку ошибок и логирование шагов.

Что дает этот промпт:

➡️ Генерирует рабочий автотест под твой сценарий

➡️ Учитывает валидации, тайминги и негативные кейсы

➡️ Структурирует код и делает его пригодным для CI/CD

🐸 Библиотека тестировщика

#буст

😱 Когда баги не фиксируются

Один тестировщик поделился историей о том, как он нашёл критический баг, но команда не восприняла его всерьёз, что привело к серьёзным последствиям:

«Я работал в e-commerce компании почти 15 лет назад. QA из главного офиса позволили нескольким багам попасть в продакшн в одном релизе. После этого руководство, которое не совсем разбирается в работе с компьютерами, придумало идею: разработчики должны специально вставить баги в следующий релиз и не сообщать об этом QA, чтобы проверить, поймаем ли мы их. И сделали это прямо перед новогодними праздниками, когда был кодовый фриз. Разработчики потратили время на создание “фальшивых” багов, чтобы научить нас уроку. Это было ужасное решение. Да, баги не были критическими, но факт того, что ресурсы были потрачены зря, чтобы «показать нам», запомнился надолго.»

❓ Как вы реагируете, если команда не воспринимает баги всерьёз? Бывали ли у вас такие случаи?

🔗 Источник

🐸 Библиотека тестировщика

#междусобойчик