SDET интервью ч.2: вопросы по системному дизайну тестов Меня спросили: "Как бы вы построили тест-фреймворк с нуля для микросервисного приложения?" Вот что я ответил — и почему начал с вопросов, а не с ответа. Системный дизайн на SDET-интервью — самый сложный этап. Нет единственно правильного ответа. Интервьюер оценивает ход мышления.

Вопрос 1: Спроектируйте тест-фреймворк для e-commerce

Это не вопрос про Playwright. Это вопрос про то, как вы думаете.

Мой шаблон ответа: — Начинаю с уточнений: «Сколько человек в команде QA? Монолит или микросервисы? Как часто релизы?» — Потом называю trade-offs: «Если команда 2 человека — простой Playwright + fixtures. Если 15+ — нужен общий тест-дата-менеджмент и изоляция между тестами» — Заканчиваю эволюцией: «Начал бы с минимума, добавил бы репортинг через месяц, шардинг — когда прогон превысит 10 минут»

Вопрос 2: Как управлять тестовыми данными?

Три подхода с компромиссами: — Фиксированные данные в БД → быстро, но тесты зависят друг от друга — Создание данных через API перед каждым тестом → изолированно, но медленнее — Снапшоты БД → детерминированно, но сложно поддерживать

Нет «правильного» ответа — есть обоснованный выбор под контекст.

Вопрос 3: Как распараллелить 2000 тестов?

Интервьюеры ждут не «включите sharding в Playwright», а понимание проблем: race conditions при общих данных, изоляция окружений, стоимость раннеров.

Главный инсайт: Компромисс важнее идеального решения. «Я выбрал A вместо B, потому что X» ценнее, чем «правильный инструмент». Интервьюеры нанимают людей, которые умеют принимать взвешенные решения в условиях неопределённости.

Какой вопрос на системный дизайн застал вас врасплох на интервью? Делитесь — разберём вместе в комментариях.

#sdet #интервью #architecture #карьера #тестирование #testing #interview #career @haradkou_sdet