🎓Почему QA должен понимать архитектуру продукта

Многие думают задача QA нажимать кнопки и смотреть, что получается.

Но это не тестирование.
Это клик-клик.

😳 Что происходит, когда QA не понимает архитектуру

Пришёл баг: данные не сохраняются.

QA проверил UI, все выглядит ок.
Написал "не воспроизводится".

А баг был в очереди между сервисами.
UI показал успех. А сообщение до consumer не дошло.

Без понимания архитектуры этот баг невидим.

📍 Что даёт понимание архитектуры

1. Знаешь где искать

Монолит - смотришь в одно место.
Микросервисы - понимаешь через какие сервисы прошёл запрос.
Очереди - знаешь, что проверить кроме UI.

2. Задаёшь правильные вопросы

Не "почему не работает кнопка".
А "через какой сервис идёт этот запрос и есть ли там retry логика".

Разница огромная.

3. Быстрее локализуешь баг

Знаешь архитектуру - знаешь где сломалось.
Не знаешь - ходишь по кругу и ждёшь разработчика.

4. Тебя воспринимают как эксперта

QA, который понимает как устроен продукт изнутри - это другой уровень разговора с командой.

Не "вот баг".
А "вот баг, он скорее всего здесь, вот почему".

⚠️ Что надо понимать - минимум

🔸из каких сервисов состоит продукт
🔸как они общаются между собой
🔸где хранятся данные,
есть ли очереди и асинхронщина
🔸где логи и как их читать

Не надо быть разработчиком.
Надо понимать карту.

🎯 Главная мысль

Чем лучше QA понимает как устроен продук, тем глубже он тестирует.

Баги на поверхности найдёт любой.
Баги внутри - только тот, кто знает, где смотреть.

👇 А вы разбираетесь в архитектуре своего продукта?
Или пока только UI? Пишите в комменты 🙂

📓 Заметки тестировщика