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

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

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

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

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

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

Инженер по тестированию — гибрид (Санкт-Петербург/Москва)

QA Engineer — гибрид (Москва)

Инженер по тестированию бэкенда (JS / TS) — 200 000 —‍ 300 000 ₽, офис/гибрид (Москва)

QA Auto (Java Mobile+Web) — от 250 000 ₽ до 300 000 ₽, удаленно

Lead QA Engineer — 310 000 —‍ 350 000 ₽, удаленно (Москва)

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

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

#свежак

⭐️ Как выбрать технику тест-дизайна под задачу

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

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

📍 Без техники легко пропустить граничные и нестандартные сценарии

📍 Без фокуса — сотни кейсов с минимумом пользы

📍 Разные типы фич требуют разных подходов — универсальной схемы нет

Что делать:

1. Выбираем технику по типу задачи

➖ Формы, поля, валидация ввода
→ Equivalence Class Partitioning (ECP) + Boundary Value Analysis (BVA)

Пример: поле «возраст 18–60»
→ классы: <18, 18–60, >60; границы: 17, 18, 60, 61

➖ Комбинации параметров (фильтры, настройки)
→ Pairwise testing, Orthogonal Array Testing

Пример: валюта, страна, тип карты — тестируем попарные комбинации, не все 100+ вариантов

➖ Бизнес-логика с условиями и правилами
→ Decision Table Testing

Пример: скидка на покупку зависит от роли + суммы — составляем таблицу условий и результатов

➖ Процессы с переходами состояний
→ State Transition Testing

Пример: заказ → оплачен → отменён → возвращён — моделируем переходы и недопустимые маршруты

➡️ Используйте технику, которая даёт наибольшее покрытие с минимальным числом кейсов

2. Учитываем риски и критичность

— Фича high-risk? → выбираем более строгие техники

— Небольшой модуль? → достаточно базовых позитив/негатив проверок

Пример: тест API платёжки ≠ тест кнопки «показать ещё» в каталоге

3. Комбинируем техники

— Сначала эквивалентные классы

— Затем границы

— И логика + состояния для сложных кейсов

➡️ Так вы покроете и валидность данных, и поведение системы

4. Документируем, как тестируем

— Обозначьте: что и как покрываете

— Это поможет при ревью и при ретесте

➡️ Даже простая пометка: Техника: BVA + EQC уже даёт понимание

💡 Советы:

— Делайте mindmap или таблицу техник под конкретную фичу

— Обсуждайте технику на grooming — разработчики часто подскажут крайние случаи

— Не бойтесь «придумывать» кейсы — бойтесь не обосновать, зачем они нужны

🐸 Библиотека фронтендера

#буст

📌 Поднять 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

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

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

#буст