Библиотека тестировщика | QA, тестирование, quality assurance, manual testing, autotesting, ручное тестирование, автотесты

😈Тестирование обхода проверки расширений при загрузке файлов

Веб-приложение позволяет пользователям загружать изображения. На сервере при загрузке проверяется только расширение файла (см. на картинке).

Какой тест-кейс наиболее эффективно выявит обход этой проверки ❓

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

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

⭐️ Тестирование под капотом: инструменты, практики и подходы для углублённого уровня

Эта подборка — не про «что такое юнит-тесты», а про инженерные подходы к качеству: надёжная автоматизация, интеграция с CI, тестирование на уровне API, контрактов и перформанса.

➡️ Test Automation Strategy – принципы построения надёжной архитектуры автотестов, выбор инструментов и разделение задач в команде.

➡️ Playwright Automation — глубокое погружение: параллельные браузеры, настройка сред, Trace и Debugging.

➡️ 16 Best Test Automation Practices to Follow in 2025 — чек‑лист от BrowserStack: от стратегии и CI до модульных тестов и AI‑поддержки.

➡️ Deep Dive into Playwright Test Runner and Configuration — обзор полного lifecycle‑конфига Playwright, parallel exec, фикстуры, отчётность.

➡️ Flaky-тесты: что это такое, какие они бывают и что с ними делать.

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

#свежак

😎 4 браузера, которые могут удивить даже закаленного тестировщика

Chrome уже раздражает, Firefox глючит — а тестировать надо. Мы с коллегами перебрали кучу вариантов и вот что реально работает:

🔘 LibreWolf — чистый форк Firefox без телеметрии, заточен под приватность. Минус — не самый гибкий для кастомизации.

🔘 Brave — быстрый Chromium с авто-блокировкой рекламы. Отличный вариант для тестов в «чистом» виде.

🔘 Thorium — зверь на Chromium: меньше лагов, лучше рендер. Подходит для тяжёлых интерфейсов и нагруженных стендов.

🔘 QuteBrowser — только клавиатура, никакой мыши. Лёгкий, быстрый и отличный для фокусной проверки логики.

Если постик зашёл, то поддержите бустом канала 🙂

Какой браузер сейчас у вас основной? Делитесь в комментах 👇

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

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

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

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

⭐️ Почему баги всплывают прямо перед релизом

Кажется, все готово: тесты зеленые, фича собрана, команда на связи. Но за день до релиза — баг.

Разбираем в карточках:

➡️ Почему не спасают даже автотесты и многоступенчатые проверки

➡️ Чем тестовая среда отличается от боевого окружения

➡️ Как дедлайны и нехватка QA-ресурсов влияют на баги

➡️ Почему важно подключать тестировщика и продакта заранее

➡️ Что ломает стабильность при работе с микросервисами

Во второй части — конкретные решения: как перестроить процесс так, чтобы багов становилось меньше, а релизы — спокойнее.

🔗 Полный текст статьи — по ссылке

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

😧 Фишка в Postman

pm.sendRequest — мощная функция в Postman Sandbox, позволяющая выполнять дополнительные HTTP-запросы из pre-request или test-скриптов. Это полезно, когда нужно динамически получить данные во время выполнения теста.

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

🔘 Получение access-токенов или временных ключей перед выполнением основного запроса.

🔘 Вызов зависимого API и сохранение ответа для последующего использования.

🔘 Проверка отклика стороннего сервиса (например, email или webhook) в рамках одного сценария.

🔘 Имитация более сложных интеграционных сценариев без стороннего кода.

✅ Пример использования: получение токена и сохранение в переменной окружения

pm.sendRequest({
  url: 'https://auth.example.com/api/token',
  method: 'POST',
  header: {
    'Content-Type': 'application/json'
  },
  body: {
    mode: 'raw',
    raw: JSON.stringify({
      username: 'testuser',
      password: 'securepassword'
    })
  }
}, function (err, res) {
  if (err) {
    console.error('Ошибка при получении токена:', err);
    return;
  }

  if (res.code === 200) {
    const token = res.json().access_token;
    pm.environment.set('authToken', token);
  } else {
    console.warn('Неожиданный статус:', res.code);
  }
});

➡️ После этого можно использовать {{authToken}} в других запросах, например, в заголовке:

Authorization: Bearer {{authToken}}

Важно:

— pm.sendRequest асинхронный — убедитесь, что основной запрос не зависит от результата, если вы используете его в test-скрипте.

— Для критически важных сценариев лучше использовать Pre-request Script — тогда вы гарантируете порядок выполнения.

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

#буст

🔍 Тестирование микросервисов vs монолита

Тестировщики привыкли к разным архитектурам. Что сложнее обкатать на прочность — единый монолит или многосервисный кластер?

✅ Испытания микросервисов:

— Распределённые вызовы (HTTP/gRPC, очереди) требуют эмуляции сервисов.

— Контрактное тестирование (Pact) защищает от конфликтов версий

— Сетевые сценарии: таймауты, ретраи и отказоустойчивость.

💡 На одном из проектов при обновлении сервиса аутентификации без Pact-теста в staging неожиданно сломался вход на фронтенд — тестировщики не эмулировали новый JWT-формат, и 30% сценариев упали.

✅ Преимущества монолита:

— Один процесс: end-to-end тесты запускаются сразу на всей системе.

— Минимум инфраструктуры — достаточно локального или staging-сервера.

— Простая отладка через IDE-брейкпойнты и профайлинг.

Как найти «золотую середину»:

➡️ Вводите микросервисы по частям, оставляя критичные фичи в монолите

➡️ WireMock, Hoverfly или Mountebank помогут «подтасовать» внешние зависимости

➡️ Автоматизируйте развёртывание через Docker Compose + тестовые контейнеры — чтобы окружение было идентичным на каждом прогоне

А у вас что сложнее далось: ловить таймауты в Kubernetes или гонять тесты на монолите? Поделитесь своими историями в комментариях! ✏️

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

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

⭐️ Инструмент недели: читаемые автотесты с Gauge

Gauge — это фреймворк для автоматизации тестирования от ThoughtWorks, построенный вокруг идеи читаемых спецификаций.

Зачем нужен:

➡️ Читаемые тесты, как документация — Gauge использует markdown + шаблоны шагов, что делает тесты легко понятными даже для менеджеров и аналитиков

➡️ Многоязычность — вы пишете шаги на любом языке: Java, JavaScript, Python, C#, Go и других

➡️ Расширяемость — богатая система плагинов (репорты, CI-интеграции, IDE-поддержка, mock-серверы)

Как использовать:

1. Установите Gauge:

npm install -g @getgauge/cli

2. Сгенерируйте шаблон проекта:

gauge init java

3. Напишите .spec файл на Markdown с тестами:

# Проверка логина
## Успешный вход
* Ввести логин "user"
* Ввести пароль "pass"
* Нажать "Войти"
* Проверить, что пользователь авторизован

4. Определите шаги в коде (например, на Java):

@Step("Ввести логин <login>")
public void enterLogin(String login) {
    // реализация
}

5. Запустите тест:

gauge run specs

⚡️ Что важно знать:

— Gauge отлично подходит для командной работы — когда QA, разработчики и аналитики работают вместе над спецификациями.

— Поддерживает параллельный запуск тестов, что критично для больших тест-сьютов.

— Плагин Gauge для VSCode позволяет запускать тесты прямо из редактора.

— Это open-source, активно поддерживается и развивается.

🔗 Сайт проекта и документация

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

#буст

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

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

🔍 Как провести ревью кода и не пропустить уязвимость

Этот промпт помогает провести глубокий аудит и оценить качество кода — не как разработчик, а как тестировщик.

Промпт:

Представь, что ты QA-специалист. Твоя задача — проверить корректность предоставленного кода.

Цель: выявить ошибки, граничные случаи, уязвимости, а также предложить тест-кейсы.

Проверь:

1. Понимание и назначение кода
2. Валидность и невалидность входных данных
3. Граничные условия (min/max/edge)
4. Обработку исключений
5. Нефункциональные аспекты (например, утечки памяти, многопоточность)
6. Безопасность (SQL-инъекции, XSS и т.д.)

Дополнительно:

– Предложи улучшения
– Оцени читабельность и поддержку
– Придумай тест-кейсы для оценки поведения кода

Вот мой код: <вставить_код>

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

➡️ Выявляет баги, о которых не подумал разработчик

➡️ Помогает составить набор тест-кейсов для ручной или авто‑проверки

➡️ Даёт рекомендации по улучшению архитектуры, читабельности и безопасности

Когда использовать:

— При ревью чужого pull request

— Перед релизом фичи

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

🔗 Источник

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

#буст

❓ Вопросы по Selenium

На собеседовании по автоматизации тестирования вам могут задать вопрос о различиях между методами findElement и findElements. Важно понимать, когда и какой метод использовать для поиска элементов на веб-странице.

В карточках разберем:

➡️ Как работает метод findElement и когда его использовать

➡️ Как работает метод findElements и в каких случаях он полезен

➡️ Основные отличия между этими методами и их применения в тестах

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