Ну, так сказать, из-за особенностей ведения проекта. Просто на других работах видел Jira + TM4J и идея вести всё на одной платформе понравилась. Очень просто было собрать отчёт по покрытию фич тестами, все артефакты были слинкованы.

Ох уж эта иллюзия насчёт «просто собрать репорт по покрытию фич тестами». :)

Это из тех мифов, что можно покрыть всё тестами?

Вообще, вангую что это так же плохо работает на практике, как условный Zephyr for Jira.

Ну, не совсем.
Это скорее про то, что "посчитать покрытие" штука вообще нетривиальная.

Потому что матрица покрытия (задач\требовений\кода, whatever) в целом хорошо позволяет подсветить куски системы, где совсем всё плохо.
Типа "вот этот сервис не покрыт тестами совсем".
Это, конечно, рождает отдельные вопросы типа "а не проверяются ли эти куски в ходе выполнения других сценариев?" и "а нужно ли нам вообще покрывать это тестами?", но да ладно.

Потом ты начинаешь писать на эти куски тестов и возникает вопрос:
А что мы считаем "покрытием"?
1 тест на 1 требование \ фичу - очевидно недостаточно.
Установить какую-то универсальную цифру - не выйдет.
Остается только субъективная оценка тестировщика в духе "мы считаем, что этот кусок покрыт", которая убивает всю суть матрицы покрытия, потому что вместо объективных измеримых параметров дает субъективное представление.

Потом возникает вопрос, что делать с отслеживанием актуальности этого покрытия.
Потому что тесты на кусок функциональности вроде есть, а насколько они актуальны (и насколько их ещё можно считать достаточными для факта "покрытия") - это ещё горочка работы.

Ну и как бы получается, что вот она матрица покрытия вроде бы есть.
Но на неё сначала закопали какое-то количество времени, а результатом стал репорт, которому непонятно насколько можно доверять.

Тут, как мне кажется, такому отчёту можно доверять ровно настолько, насколько доверяешь самому тестировщику. Но вообще да, в таком изложении это весьма сомнительное удовольствие)

Ну, тогда проще подойти к тестировщику и спросить "слыш, а чо у нас там с покрытием тестами?"

Ага. И результат будет примерно таким же. Только нужно дать время на анализ покрытия.

Ну, я, честно говоря, склоняюсь к тому, что ответ тестировщика своими словами после минут 15 размышлений может дать примерно то же качество информации, что и магическая чиселка 42% coverage.

Тестирование, в принципе, весьма субъективно в некоторых моментах

Это я не к тому, что покрытие мерить не нужно и вообще всё это буллшит.
Это здорово, когда у команды тестирования есть инструмент что бы показывать бизнесу "вот это мы сейчас не тестируем вообще, вот здесь тестируем, но так себе, а вот здесь всё должно блестеть и работать".
(ну и заодно, когда у команды для самой себя есть инструмент, что бы наглядно это видеть)
Я скорее к тому, что это немножко (сильно) сложнее сделать, чем просто слинковать тесты с задачами в таск-трекере.

В прочем, довольно часто эта самая матрица покрытия - чисто бюрократический инструмент.
Я работал в компаниях, где одним из требований сертификации было "не менее одного теста на каждое требование с критичностью выше N".
И тут, как бы, уже понятно, зачем это надо. :)

Доброе утро! Подскажите инструменты, кроме стандартных
- Charles
- postman
- android studio
Которые полезны при тестировании мобильных приложений, хочу расширить кругозор функционала

Если у вас Windows то рекомендую Fiddler - намного приятнее чем Charles.
Не совсем понимаю зачем тебе Postman - наверное чтобы какие-то данные на бэке готовить.
Android Studio и XCode думаю ты уже осилил, хотя там есть куча всего интересного как например мониторинг используемых ресурсов и т.п.
Также, наверное твои разрабы используют Crashlytics, да и в целом познакомься с Firebase лишним не будет.
Много лет назад использовал Net Limiter и Clumsy для эмуляции всяких ситуаций с интернетом - может сейчас что по лучше есть.
Если прям упороться, но это уже больше наверное для автоматизации, то можно глянуть ещё за stf, если я название на путаю (на GitHub лежит)

Я так понимаю этот софт для эмуляции скорости инета для андройда только работать будет ?

На любой.
У нас это был дешёвый моноблок, который раздавал WiFi, который мы использовали для тестирования приложений

Просто я так понял тротлить iOS дело не благодарное и сложное

А ты не конкретно iOS тротлишь - ты шатаешь сеть куда он подключен. Типа все входящие и исходящие потоки... Для этого и нужен моноблок - он как "умный" роутер.
Но ты не зацыкливвйся, думаю сейчас что-то получше есть. Просто это было 6+ лет назад 😅

Все равно спасибо)