📌 Поднять API-заглушку за 1 команду

Когда нужен REST API без бэкенда — json-server поднимает заглушку за секунды. Особенно полезно при мокировании данных в автотестах, CI/CD или нестабильном API.

npx json-server --watch mocks/db.json --port 5050

Что действительно удобно:

— Реагирует на GET, POST, PUT, DELETE без конфигураций

— Автоматически сохраняет изменения обратно в db.json

— Работает как stateful-мок: можно писать, читать, удалять данные «вживую»

💡 Хитрые приёмы:

— Эмуляция задержки ответа:

npx json-server --watch db.json --delay 800

— Интеграция с Playwright или Cypress:

в beforeAll() можно запускать json-server как фоновый процесс

import { exec } from 'child_process'
beforeAll(() => exec('npx json-server ... &’))

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

#буст

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

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

📌 Как тестировать платежные сценарии

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

1️⃣ Понимаем процесс платежа:

— Узнайте, какие платёжные провайдеры используются (например, Stripe, YooKassa, PayPal)

— Разберитесь в потоке: покупка → авторизация → списание / возврат

— Убедитесь, что есть доступ к sandbox-среде и тестовым картам

2️⃣ Позитивные сценарии (успешная оплата):

— Оплата с валидной картой, включая 3-D Secure

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

— Отображение суммы, валюты и комиссии на всех шагах

3️⃣ Негативные сценарии (ошибки и сбои):

— Ошибка оплаты (недостаточно средств, неверная карта, отказ банка)

— Обрыв соединения или таймаут при оплате

— Проверка на защиту от повторной отправки и дублирования платежей

4️⃣ Возвраты и отмены:

— Тестирование полного и частичного возврата

— Проверка правильного обновления статуса и истории заказа

— Убедитесь, что возврат действительно поступает на карту / кошелёк

5️⃣ Безопасность и соответствие требованиям:

— Данные карт не должны храниться (если нет PCI DSS)

— Используется HTTPS и шифрование при передаче данных

— Есть защита от фрода и лимит попыток оплаты

6️⃣ Интеграции и системные действия:

— Проверка логов и алертов на сбои

— Корректная синхронизация с CRM, email-уведомлениями, backend

— Админка позволяет отслеживать платежи и делать возвраты вручную

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

#буст

😎 Как тестировщики спасают продакшен

Вышел новый выпуск подкаста «QAk‑QAk — и в продакшен» с Борисом Чернышом из Т-Банка — о том, как QA справляется с инцидентами и спасает критичные системы от сбоев.

Разберемся:

➡️ Что происходит, когда падает прод

➡️ Какую роль играет тестировщик в отказоустойчивости

➡️ Почему автоматизация — это не «таблетка от всего»

➡️ Может ли AI вовремя остановить фейл

➡️ И почему баг — не всегда провал, а иногда рост

🔗 Слушать подкаст на Soundstream

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

#буст

🐞 Какие баги вы считаете самыми запоминающимися

В тестировании бывают баги, которые просто фиксишь — и забываешь. А бывают те, которые надолго остаются в памяти.

Вопрос от подписчика:

«Работаю в тестировании уже несколько лет. Иногда ловлю себя на мысли, что самые запоминающиеся баги — это не самые критичные, а самые странные. Например, как-то в форме на сайте имя «Тест» вызывало падение backend-а. А какие баги были у вас?»

❓ Расскажите, с какими самыми необычными, смешными или загадочными багами вы сталкивались? Что это было и как вы их нашли?

Поделитесь историями в комментариях ⬇️

P.S. Если хотите задать вопрос, заполните нашу гугл-форму. Это займет 5 минут.

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

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

🌟 В таких ситуация главное уверенно говорить: «Да, было»

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

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

🔍 Много багов — плохой знак или хорошее покрытие

Многие команды любят цифры. Но можно ли по количеству багов судить о качестве продукта или работе тестировщика?

➡️ Когда багов много — это плохо:

— Может указывать на плохую реализацию или слабое покрытие

— Мешает команде фокусироваться: баг-трекинг превращается в свалку

— Возникает ощущение нестабильности у заказчика или менеджмента

➡️ А может, наоборот — это хорошо:

— Активная фаза тестирования, всё выкопано до релиза

— Тестировщик глубоко погружается в продукт и не «пропускает»

— Много багов ≠ плохой код, особенно на ранних этапах разработки

Реальный кейс:

На одном из проектов QA завёл 150 багов за неделю. Команда запаниковала: «У нас катастрофа?» Оказалось, что новый функционал не был покрыт даже юнитами, и тестировщик просто вытащил наружу всё, что и так было сломано.

💡 Как подойти разумно:

➖ Считайте не количество багов, а сколько из них — критичные

➖ Анализируйте источники: баг из-за продукта, окружения или требований

➖ Ведите динамику: сколько дефектов уходит в прод и с какими последствиями

А вы как считаете: 200 багов — это тревога или просто хороший день у QA? Поделитесь своим мнением в комментариях! ✏️

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

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

🧩 Pairwise Testing — меньше тестов, больше пользы

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

➡️ Pairwise Testing Explained with Tools & Examples — описывает, как работает метод, почему он эффективен и какие инструменты (PICT, Hexawise, ACTS) можно использовать

➡️ Using Pairwise Testing to determine how many tests you need — современный подход с примерами расчёта объёма тестов и использованием AI/ML, чтобы масштабировать наборы

➡️ Pairwise тестирование — на чем основана данная техника, почему она так распространена.

➡️ Попарное тестирование — подробное видео с примером ручной и автоматической генерации через PICT

➡️ Pairwise testing за 5 минут: алгоритм построения и пример — коротко и емко про методику, подходит для быстрого освоения подхода

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

#свежак

🌸 Задача на собеседовании: проверка пользовательского ввода

На фронтенде есть форма регистрации с полем «возраст». Выше — фрагмент HTML и JS.

❓ Вопрос:

Какие из вариантов тест-кейсов наиболее точно позволят проверить работу проверки возраста?

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

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

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

Senior QA Lead — от 350 000 ₽, офис/гибрид (Москва)

Тестировщик ПО/QA Engineer — офис (Новосибирск)

Automation QA Engineer (Python) — удаленно (Пенза)

Middle+ Тестировщик — до 330 000 ₽, удаленно (Москва)

AQA / Автоматизатор тестирования на Python — от 150 000 ₽, офис (Казань)

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

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

#свежак

📌 Шпаргалка по работе с ветками и сохранению изменений в Git

В ней собраны основные команды для эффективного управления ветками и фиксации правок:

➡️ Просмотр и переключение веток

➡️ Создание и удаление веток

➡️ Слияние и тегирование

➡️ Добавление изменений и коммиты

➡️ Отмена изменений

Эта памятка поможет быстро ориентироваться в ключевых операциях Git и держать историю вашего проекта в порядке.

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

#буст