Как оценить время тестирования приложения на Android и iOS по описанным кейсам?
Что проверяют
Умеете ли вы превратить список кейсов в обоснованную оценку с допущениями, а не назвать число на глаз. Следом обычно спрашивают, что станет с оценкой, если найдётся много багов или в матрицу добавят ещё одну версию ОС.
Как отвечать
Покажите декомпозицию и арифметику.
- классы кейсов: разбейте кейсы на простые, средние и сложные и возьмите время на каждый класс из прошлых прогонов, если история есть в TMS. Если нет, пройдите по два-три кейса каждого класса и замерьте;
- матрица платформ: не умножайте всё на два. Проверки бэкенда и бизнес-логики часто достаточно пройти один раз, а на обеих платформах гоняют UI, жесты, разрешения, пуши, работу в фоне и платформенные сценарии вроде системной навигации назад на Android. Отдельно учтите, сколько устройств и версий ОС в матрице;
- подготовка: установка сборок через TestFlight и Firebase App Distribution, тестовые аккаунты и данные, стенды, ферма устройств;
- баги и перепроверки: заведение дефектов, ожидание фикса и повторный прогон. Закладывайте хотя бы один цикл ретеста и регрессию затронутых областей;
- неопределённость: для крупных блоков удобна трёхточечная оценка PERT,
(O + 4M + P) / 6, где O оптимистичная, M наиболее вероятная, P пессимистичная.
Итог подавайте диапазоном с перечнем допущений: сколько устройств, какое покрытие автотестами, стабильна ли сборка, как быстро чинят баги. Тогда при изменении условий пересчёт понятен всем и не выглядит как сорванный срок.
Где спотыкаются
Считают только чистое выполнение шагов. Подготовка окружения, оформление багов и ретест легко съедают столько же времени, сколько сам прогон.
Берут коэффициент на риски с потолка. Запас должен опираться на историю команды или хотя бы на названные риски: сырая сборка, новые устройства, незнакомый модуль.
Дают одну цифру без условий. Если через день в матрицу добавят планшеты или старую версию iOS, оценку нечем защитить, потому что допущения не были озвучены.