🔒Открыть пост
и посмотреть медиа
и посмотреть медиа
Немного размышлений про архитектуру приложений и участие тестировщика в ней.
Иногда создается ощущение, что архитектура системы - это что-то далекое от тестирования. Мол, это зона ответственности разработчиков, архитекторов и тимлидов, а задача тестировщика, просто проверять результат. Но по факту я считаю, что тестировщики тоже могут принимать участие в проработке архитектуры.
Тестировщик часто первый, кто сталкивается с побочными эффектами кривой архитектуры. Именно тестировщик видит, что, например, микросервис живет своей жизнью, API отвечает нестабильно, данные разваливаются из-за кривых связей, запросы идут слишком долго, а изменения в одном месте ломают сразу три других. И на самом деле это уже не прям баги, а проблемы самого архитектурного решения системы.
Например, когда тестировщик фиксирует повторяющиеся проблемы между сервисами, то это может уже служить сигналом, что что-то пошло не так с интеграцией. Или другой пример, связанный с нестабильность данных, когда в одной таблице лежит одно, в другой другое, а на UI отображается вообще третье. В данном случае тестировщик может видеть цепочку процесса и понять, что данная проблема системная, потому что кто-то не подумал про единый источник данных и решил плодить таблицы. И таких ситуаций может быть достаточно много и они должны в будущем учитываться при построении архитектуры новой системы/модуля/микросервиса или изменении текущей.
Поэтому опыт тестировщика тоже может быть полезен архитектору для правильного построения архитектуры решения, потому что если тестировщик молчит, архитектура никогда не станет лучше, ее просто продолжат усложнять до тех пор, пока она не начнет ломаться сама по себе после каждого деплоя и превращаться в монстра франкенштейна, которую потом уже будет невозможно нормально поддерживать.
Все мои проекты:
TG канал по тестированию AI | Курс по оценке и тестированию AI | Курс по тест-менеджменту |
Youtube channel | Практика по тестированию | Платформа TestGrow | База знаний