Как распределяются задачи между Android и iOS тестировщиками?
Что проверяют
Понимаете ли вы, что у двух платформ общее, а что нет, и не проверяет ли команда один и тот же бэкенд дважды. Если спрашивают про прошлый проект, хотят услышать реальную схему, а следом уточняют, как вы следили за паритетом фич на двух платформах.
Как отвечать
Опишите модель, которая была у вас, с плюсами и минусами. Типичных схем три:
- по платформам: у каждого тестировщика своя ОС. Глубокое знание платформы, но поведение фичи может разъехаться, а общий бэкенд проверяется дважды;
- по фичам: один человек ведёт фичу на обеих платформах. Паритет виден сразу, но нужно знать обе ОС и держать оба типа устройств;
- смешанная: владелец фичи один раз проверяет общую логику и API, а платформенные особенности добирает тестировщик платформы.
Что специфично и должно быть в чек-листах отдельно:
- сборки: TestFlight для iOS, внутреннее тестирование в Google Play или Firebase App Distribution для Android;
- платформенные различия: разрешения, пуши (APNs и FCM), системная кнопка «Назад» и жесты, Universal Links и App Links, фрагментация Android по версиям и производителям;
- релиз: ревью в App Store, поэтапная раскатка в обоих магазинах, из-за которой на проде живут две версии сразу;
- автотесты: XCUITest и Espresso нативно, либо Appium или Maestro одним сценарием на обе платформы.
Общие тест-кейсы удобно держать в одной TMS (TestRail, Qase, Allure TestOps) с пометкой платформы, а баг, найденный на одной ОС, сразу проверять на второй.
Если вы были единственным тестировщиком на обе платформы, так и скажите и объясните, как расставляли приоритет устройств по аналитике. Нужны примеры из своей работы, а не общая схема.
Где спотыкаются
Отвечают «делим поровну» без критерия. Интервьюер ждёт логики: по платформе, по фиче или по риску.
Не проверяют найденный баг на второй платформе, и там он доезжает до релиза.
Недооценивают iOS со словами «там устройств мало». Разные версии ОС, размеры экранов и поведение приложения в фоне дают свои дефекты.