#️⃣ #тестирование #qa #инициатива #опыт
Поговорим про ведение тест-кейсов на проекте.
Видел я немало проектов — и на многих тест-кейсы были просто головной болью.
Очень часто тестовая модель писалась «абы как»: один тест-кейс и API, и UI, и кафка, и БД сразу.
Знакомо? Я почти уверен, что у 90% у кого-то из вас на проектах такая же история 😅
Для стартапа, когда «надо было ещё вчера», это понятно: многие либо вообще отказываются от тест-кейсов, либо делают один огромный тест «на всё подряд». Но проблема в том, что так потом и продолжают.
И как только дело доходит до автоматизации — сразу вылазят все минусы.
А если тестов становится много, в такой каше очень сложно понять, куда «бьёт» новая фича и где нужно править.
В какой-то момент я решил разобраться, как организовать всё по-человечески. Взял за основу пирамиду тестирования и рекомендации коллег. В итоге получилось простое и удобное решение.
👉 Пример с текущего проекта (веб + мобилка):
Родительские сьюты в Qase.io: API, UI, E2E, Mobile, Интеграционные
Внутри API — группы по Swagger
Внутри UI — тесты по экранам
Mobile — аналогично
E2E — ключевые бизнес-процессы (смоук)
Интеграции — Kafka, БД, внешние системы
Главное правило: не мешать в одном тесте разные слои. Если чувствуешь такое желание — бей себя по рукам ✋
Что это даёт?
✅ Легко понимать, где править тесты при изменениях
✅ Модель растёт вместе с системой без хаоса
✅ Автоматизация становится проще и надёжнее:
— API-кейсы быстрые и дешёвые
— UI/Mobile разложено по экранам, меньше флака
— E2E только основные бизнес сценарии и критичные пути
— Интеграции отдельный слой
✨ Возможно, это подойдёт и к твоему проекту.
Если у вас есть вопросы — задавайте, с радостью отвечу!
🌐 Сайт | 💼 LinkedIn | 📘 Курс по Postman
