Абсолютно верно! Спасибо за уточнение.) Все так и есть, ни Firebase, ни AppMetrica не могут отправить отчет непосредственно в момент креша, ибо выполнение кода прерывается ОС.
Работает это примерно так:
SDK перехватывает сигнал о сбое и максимально быстро записывает данные в локальный файл на устройстве
этот файл будет отправлен на сервер уже при следующем запуске прилы
Таким образом, если, например, пользователь после креша удалил прилу или больше в него никогда не заходил - этот креш можно вообще не увидеть в системах мониторинга (в отличие от системных логов Apple). Это поинт комбинировать сторонние SDK с Xcode Organizer, который получает данные напрямую от ОС, даже если юзер удалил приложение после вылета.
Пожалуй, это один из самых понятных текстов про System Design, что я читал. Спасибо! Было бы интересно послушать про System Design относительно мобильных приложений.)
Отдельная боль, когда какую-то важную инфу пишут по главным каналам компании. Ты приходишь к коллеге и ожидаешь, что он в курсе этой инфы. А он, в свою очередь, делает вид, что вообще впервые слышит не только об этой инфе, но и об этом канале. 🫠
В целом мысль про глубину проверок и State Coverage выглядит здраво и давно назревшей, особенно на фоне тысяч «зеленых» тестов, которые по факту проверяют доступность сервера, а не саму систему.
Но есть ощущение, что вы чутка недооцениваете человеческий фактор. Любая шкала из 6-ти уровней довольно быстро рискует превратиться в KPI: «срочно всем довести тесты до 4 уровня». А дальше - формальное усложнение assertions без реального понимания, зачем именно этот тест вообще существует. В итоге можно получить тесты с высокой глубиной, но все теми же слепыми зонами в тесовых сценариях.
Отдельно интересно будет посмотреть во второй части, как вы решаете вопрос актуальности проверяемых полей. Схема может быть на 12 полей, но бизнес-ценность у них разная, и равновесное State Coverage тут может вводить в заблуждение не хуже pass rate.
Тем не менее, сама постановка проблемы - весьма сильная. Буду следить за продолжением. :)
Интересный обзор базовых метрик. Хотелось бы только предостеречь насчет Test Case Pass Rate. Без контекста актуальности самих кейсов эта метрика может давать ложное чувство защищенности.
Для мобильной разработки, на мой взгляд, критичнее всего следить за Defect Leakage, т.к. цена ошибки в сторе выше, чем в вебе. А вот таймеры в TMS лучше использовать осторожно, чтобы не превратить тестирование в гонку на скорость в ущерб качеству.
Если ты та самая Лена, то ты вдвойне права. 😁
Абсолютно верно! Спасибо за уточнение.) Все так и есть, ни Firebase, ни AppMetrica не могут отправить отчет непосредственно в момент креша, ибо выполнение кода прерывается ОС.
Работает это примерно так:
SDK перехватывает сигнал о сбое и максимально быстро записывает данные в локальный файл на устройстве
этот файл будет отправлен на сервер уже при следующем запуске прилы
Таким образом, если, например, пользователь после креша удалил прилу или больше в него никогда не заходил - этот креш можно вообще не увидеть в системах мониторинга (в отличие от системных логов Apple). Это поинт комбинировать сторонние SDK с Xcode Organizer, который получает данные напрямую от ОС, даже если юзер удалил приложение после вылета.
Пожалуй, это один из самых понятных текстов про System Design, что я читал. Спасибо!
Было бы интересно послушать про System Design относительно мобильных приложений.)
Отдельная боль, когда какую-то важную инфу пишут по главным каналам компании. Ты приходишь к коллеге и ожидаешь, что он в курсе этой инфы. А он, в свою очередь, делает вид, что вообще впервые слышит не только об этой инфе, но и об этом канале. 🫠
В целом мысль про глубину проверок и State Coverage выглядит здраво и давно назревшей, особенно на фоне тысяч «зеленых» тестов, которые по факту проверяют доступность сервера, а не саму систему.
Но есть ощущение, что вы чутка недооцениваете человеческий фактор. Любая шкала из 6-ти уровней довольно быстро рискует превратиться в KPI: «срочно всем довести тесты до 4 уровня». А дальше - формальное усложнение assertions без реального понимания, зачем именно этот тест вообще существует. В итоге можно получить тесты с высокой глубиной, но все теми же слепыми зонами в тесовых сценариях.
Отдельно интересно будет посмотреть во второй части, как вы решаете вопрос актуальности проверяемых полей. Схема может быть на 12 полей, но бизнес-ценность у них разная, и равновесное State Coverage тут может вводить в заблуждение не хуже pass rate.
Тем не менее, сама постановка проблемы - весьма сильная. Буду следить за продолжением. :)
СТО, который свято верит в решения AI без доли критического мышления - горе в компании.
Спасибо за статью!
Интересный обзор базовых метрик. Хотелось бы только предостеречь насчет Test Case Pass Rate. Без контекста актуальности самих кейсов эта метрика может давать ложное чувство защищенности. Для мобильной разработки, на мой взгляд, критичнее всего следить за Defect Leakage, т.к. цена ошибки в сторе выше, чем в вебе. А вот таймеры в TMS лучше использовать осторожно, чтобы не превратить тестирование в гонку на скорость в ущерб качеству.
@antoniozvonarev а какой был смысл нагло копипастить описание книг отсюда?
https://qarocks.ru/testing-dot-com-overview/
Когда-нибудь настанет момент, когда Савина перестанут рекомендовать как лучшую первую книгу для тестировщиков и дадут ей заслуженно уйти на покой...