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

🛠 Фишка инструмента: Mountebank

Mountebank — это удобный способ поднимать «заглушки» вместо настоящих сервисов: API, SMTP или TCP — без единой строчки кода.

❗️ Поддерживает несколько протоколов из коробки: HTTP, HTTPS, TCP и SMTP. Всё управляется через REST API или JSON — без SDK и сложной настройки.

Где пригодится:

— Когда внешний сервис нестабилен или недоступен

— Чтобы проверить edge-кейсы: 500, таймауты, невалидный JSON

— Если интеграция ещё не готова, а тестировать уже нужно

— Для эмуляции редких и нестандартных сценариев

🍒 Вишенка на торте — можно писать JavaScript-правила для динамических ответов, а также использовать proxy-режим, логирование и валидацию запросов.

Пример простейшего impostera:

{
  "port": 4545,
  "protocol": "http",
  "stubs": [{
    "responses": [{ "is": { "statusCode": 200, "body": "Mocked response" } }]
  }]
}

🔗 Ссылка на GitHub

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

#буст

Proglib Academy — это место, где вы превращаете теорию в практику. Здесь ваши знания становятся проектами для портфолио, а вы — более уверенным специалистом.

Выберите курс, который поможет сделать следующий шаг ⬇️

🚀 Для тех, кто начинает путь в IT:

— Основы IT для непрограммистов
— Программирование на Python (обновлённый)
— Frontend-разработчик с нуля: HTML, CSS, JavaScript

🧠 Для будущих и настоящих Data Scientist'ов:

— ML для старта в Data Science (начинается в сентябре)
— Базовые модели ML и приложения
— Математика для Data Science
— AI-агенты для DS-специалистов (скоро второй поток)

🛠️ Для опытных разработчиков, готовых к росту:

— Алгоритмы и структуры данных
— Архитектуры и шаблоны проектирования

Независимо от вашей цели, у нас есть курс, который поможет её достичь. Переходите в Proglib Academy, выбирайте свой путь и инвестируйте в навыки, которые всегда будут в цене!

💥 Как я обнаружил рассинхронизацию тестового окружения с продом

Наш подписчик работал над критическим релизом и заметил, что автоматические тесты в тестовой среде начинают падать на тех же проверках, которые в продакшене проходили без проблем:

«Мы закрыли этап интеграционного тестирования и запустили полный regression suite в тестовом кластере. Часть тестов на проверку бизнес-логики неожиданно упала: в тестовых данных не создавались архивные записи, а на проде всё работало стабильно. Я сравнил версии миграций и конфигураций между окружениями и обнаружил, что в тестовом кластере не были применены последние DDL-скрипты и обновления триггеров. Также выяснилось, что переменные окружения для подключения к очередям и таймауты в application.yml отличались от продовых.»

❓ Какие приемы вы используете, чтобы гарантировать синхронизацию тестовых и продакшен-окружений?

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

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

✍️ Как превратить описание фичи в тест-план и каталог кейсов

Этот промпт превращает LLM в мини-команду QA. Подходит для ручного и автоматизированного тестирования.

Как работает:

😗 QA0 — запускает процесс

😗 QA1 — уточняет описание

😗 QA2 — строит тест-план по ISO 25010

😗 QA3 — генерирует кейсы

Можно общаться с каждым этапом: добавлять, редактировать, уточнять.

Промпт:

## INITIAL CONTEXT
We are going to work in developing Software Quality documentation.
Quality or test terminology is based in ISTQB body of knowledge.
...
## ROLES OVERVIEW
From now on, I want you to assume the roles of three distinct Software Quality specialists...
...
## QA0 - SUPERVISOR
QA0's task is to review the request, asking for an example...
...
## QA1 - FEATURE REVIEWER
QA1's task is to review the feature description, performing static testing...
...
## QA2 - TEST PLAN DESIGNER
QA2's task is to create a comprehensive Software Quality Test Plan based on ISO 25010...
...
## QA3 - TEST CATALOG DESIGNER
QA3's task is to design a set of formal test cases that cover all the test conditions...

Что получаете на выходе:

➡️ Тест-план по ISO 25010 + ISTQB

➡️ Матрица рисков и пробелов

➡️ Каталог тестов в формате: шаги, приоритет, ожидаемый результат

➡️ Повторяемый и масштабируемый QA‑процесс

🔗 Полный промпт по ссылке

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

#буст

Знакомый кейс ☕️

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

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

🔐 Как автоматизировать проверку токена в Postman

Чтобы не копировать токен каждый раз вручную — можно настроить автоматическую подстановку.

1️⃣ Получаем токен в pre-request script:

pm.sendRequest({
  url: 'https://example.com/api/login',
  method: 'POST',
  header: { 'Content-Type': 'application/json' },
  body: {
    mode: 'raw',
    raw: JSON.stringify({
      username: 'user',
      password: 'pass'
    }),
  },
}, (err, res) => {
  const token = res.json().token;
  pm.environment.set('authToken', token);
});

2️⃣ Подставляем в запросы:

В заголовке:

Authorization: Bearer {{authToken}}

💡 Работает с JWT, OAuth и любыми кастомными токенами. Поддерживает коллекционные переменные, глобальные и окружения.

Используйте в:

— Ручных API-тестах
— Автоматизированных коллекциях
— CI/CD пайплайнах

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

#буст

🏷️ Тесты не должны бояться цвета кнопки

Если ваши автотесты падают после смены класса или текста — проблема не в фронтенде, а в подходе.

В карточках:

➡️ Почему локаторы ломаются — и кто в этом виноват

➡️ Как устроены тестовые идентификаторы

➡️ Что отвечать на аргументы «против»

➡️ Как внедрить data-test-id без бойкота от фронта

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

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

🔥 3 способа скрыть элемент, которые обязан знать каждый тестировщик

В CSS есть несколько для этого способов, и каждый ведёт себя по-своему:

➖ один полностью исключает элемент из потока

➖ другой делает его невидимым, но он остаётся в DOM

➖ а третий — вообще всё ещё кликается

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

— ломаются автотесты, если не учесть способ скрытия

— isDisplayed() и isVisible() могут врать

— доступность (a11y) зависит от метода

— критично при проверке модалок, спойлеров и выпадашек

📌 На картинке — краткая шпаргалка по трем базовым методам. Сохраните, пригодится в каждом втором UI-тесте.

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

#буст

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

Testing Engineer (NGFW) — удаленно (Москва)

Automation QA Engineer — от 120 000 до 200 000 ₽, удаленно (Таганрог)

QA Engineer — от 100 000 до 150 000 ₽, удаленно/офис (Владивосток)

Senior Manual QA Engineer — от 1 500 $, удаленно (Сингапур)

QA Auto (Python) — от 200 000 ₽, удаленно (Москва)

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

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

#свежак

😎 Тестирование кэширования на клиенте

Вы тестируете веб-приложение с системой авторизации. После успешного логина данные пользователя сохраняются в localStorage.

Однако после выхода из системы пользователь продолжает видеть старые данные при повторном входе.

❓ Каким образом можно проверить эту проблему?

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

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

📋 Чек-листы для тестировщика

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

➡️ Complete QA Process Checklist

Подробный чек-лист на весь цикл QA: от анализа требований до релизной верификации. Готовый шаблон доступен бесплатно.

➡️ QA Checklists Explained

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

➡️ The Only Software Testing Checklist You Need

Универсальный чек-лист для ручного тестирования, охватывающий функциональность, API, UI, performance, compatibility.

➡️ Как составить чек-листы для эффективного тестирования

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

➡️ Чек-лист и шпаргалка по тест‑кейсам

Лаконичные примеры чек-листов для веб-приложений: функционал, формы, UI, сценарии. PDF-формат для скачивания.

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

#свежак

💪 Как справляться с флейками в автоматических тестах

Флейки — тесты, которые иногда проходят, а иногда нет, — это настоящая боль для автоматизации.

С ними часто сталкиваются, и вопрос: что эффективнее — стабилизировать окружение, менять инструменты или улучшать практики?

✅ Почему стоит с ними бороться:

— Флейки снижают доверие к автоматизации и усложняют работу.

— Постоянные флейки требуют дополнительных усилий для поиска причин.

— Неправильная конфигурация часто приводит к флейкам.

⛔️ Почему флейки неизбежны:

— Сетевые задержки и внешние сервисы могут вызвать флейки.

— Иногда проблемы в коде или логике тестов могут приводить к флейкам.

— Смена фреймворков не всегда избавляет от флейков.

Как вы решаете проблему с флейками в тестах ❓

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

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

Мем смешной, ситуация страшная 🙂

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

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