По каким критериям оцениваешь проект как более сложный
Что проверяют
Есть ли у вас своя шкала, или «сложный проект» означает «мне было тяжело». Для тестировщика это вопрос про планирование: от оценки сложности зависят срок регресса, глубина тест-дизайна и решение, что автоматизировать в первую очередь.
Как отвечать
Назовите несколько независимых осей и покажите, что считаете по ним, а не по ощущениям.
- Размер и связность: сколько внешних интеграций, есть ли асинхронность, очереди, фоновые задания. Сценарий, проходящий через три сервиса и очередь, стоит дороже любой формы с валидацией.
- Тестируемость: есть ли спецификация, по которой определяется ожидаемый результат, можно ли подготовить данные, поднимается ли стенд целиком, видно ли происходящее в логах и трассировке.
- Матрица конфигураций: устройства, браузеры, версии, роли, тарифы, локали. Она растёт произведением, а не суммой.
- Цена ошибки: деньги, персональные данные, медицина, отчётность перед регулятором. Это задаёт глубину проверок и объём документирования.
- Состояние процесса: стабильность требований, частота релизов, наличие живого регрессионного набора.
Сведите это в одну фразу: сложность это объём того, что нужно проверить, делённый на то, насколько легко это проверить. Дальше подкрепите примером из своего опыта.
Где спотыкаются
Меряют сложность числом тест-кейсов. Тысяча однотипных проверок одной формы проще десятка сценариев распределённой транзакции, где состояние надо ловить в трёх местах сразу.
Второе: путают сложный с незнакомым. Новый лично для вас стек это ваша кривая обучения, а не свойство проекта. Интервьюер отличает одно от другого и ждёт, что вы отличаете тоже.
Третье: забывают про тестируемость и данные. Система без тестового контура, с оплатой через боевой шлюз и без способа привести пользователя в нужное состояние сложнее вдвое при той же функциональности, и именно это чаще всего срывает сроки.