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

Вы привели примеры достижений за гранью компетенции большей части мидлов/синьоров. Ладно, допустим мне не понравились сами примеры. Вопрос пока в другом. Лид вполне может записать достижение команды по любым метрикам на свой счет, потому что он лид и это его работа. Может ли мидл/синьор себе позволить то же самое? Или у вас есть рецепт как отделить личное достижение от достижения команды?

Допустим, мне не нравится выбранный тон дискуссии -- изначально он чересчур агрессивный с переходом на личности ("похоже, вы не поняли вопрос", да-да). Ну тут вы поделились, я поделился, ок.
Upd: на всякий, это я легонько намекаю, что все мы не без греха, а приведённые примеры не имели цели кому-то нравиться.

Метрики, относящиеся непосредственно к работе команды/юнита обычно известны и доступны членам команды (писал выше, время на регрессию, покрытие, пасс рейт -- много их может быть). Более того, часто сами линейные сотрудники могут эти метрики считать.

Что до "позволить" -- то тут либо я и правда не понимаю вопроса, либо фиг знает. В моей голове, инженер понимает, что он делает, зачем, и к какому результату это, по итогам приводит. Например, "я предложил идею перевести 30% юайных тестов на апи, заэстимейтил таску, обосновал плюсы и согласовал таску с лидами и пм, за 32 человекочаса я это сделал, ключевые метрики не пострадали, а время ночного прогона сократилось с M часов до N, что позволило нам, в итоге..." -- можно расписывать как персональное достижение, почему нет?

Рецепт так-то довольно прост: чьё решение и кто его реализовывал.

Не понимаю где вы видите переходы на личности, я пытаюсь вопрос объяснить. Инженер может на 146% понимать что делает и лично он и команда. А как это влияет на итоговый результат?  Он может не понимать, потому что не управляет процессами на более высоком уровне. Он может не работать с бизнесом (как продакты или аналитики). Он может банально не иметь доступ ко всем метрикам. Да и какие метрики то в его позиции очевидны? Покрытие тестами это чаще про юниты, этим разработчики занимаются. Время прогона тестов от инфраструктуры зависит. Количество багов с прода это вообще на уровне гороскопов.

Если ты лично предложил то, что стало достижением - значит личное. Если ты лично реализовал то, что предложил другой - командное. Если просто рядом с пацанами стоял, которые предлагали и реализовывали - ну, тоже принимал участие

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

Покрытие -- это не только про юниты. Имея тесты и тестовый объект, можно считать покрытие, относительно уровня тестов. Покрытие требований, а не строк кода, например.

Время прогона зависит не только от инфраструктуры, но и от уровня тестов, от качества тестового кода, от инструментов, от подходов, от количества тестов в прогоне...

Количество багов с прода -- это не предсказание, а ретроспектива. В десяти предыдущих релизах мы пропускали в прод, в среднем, по 10 багов высокого приоритета, после изменений мы пропускаем, в среднем, один такой баг на два релиза.

Во первых,
Вот вы сами перечислили, что там может не понимать инженер.
Соотвественно то, что он взял и начал в этом всем разбираться - одно из тех достижений, про которые вы хотели знать.

Во вторых, покрытие есть не только юнитами.
А ещё ничего не мешает инженеру работать с юнитами или следить за тем, что бы их качество и количество росло.

В третьих, очевидность метрик не зависит от позиции.
Она зависит от человека и того, какие метрики он хочет получать.

В четвёртых,
Время прогона тестов зависит не только от инфраструктуры.
Более того, ничего не мешает в эту самую инфраструктуру лезть.

Ну, продакшен баг рейт в абсолютных числах, конечно, мерить нельзя.
А вот в процентном соотношении от общего числа найденных - вполне себе.

Согласен. Мне показалось, в абсолютных числах нагляднее объяснить, в противовес идее вангования.
@azshoo отдельное мерси за коммент, кстати: я увлёкся и переступил-таки грань допустимого упрощения.

Спасибо за ответ. Приложения, которые не поддерживают x86_64 архитектуру. В эмуляторе Genymotion, например, не запускается. Нашел этот гайд: https://ubuntu.com/blog/running-android-in-the-cloud-with-amazon-ec2-a1-instances. Что скажете?

А вы собирали эмулятор под необходимые конфигурации, например, в андроид студии? Альтернативно, могу посоветовать эмуляторы под arm архитектуру, если её поддерживают ваши приложения)
Следом ещё встанет вопрос скорости и стабильности прогонов. А так же производительности и ресурсности)

https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html?m=1
Думаю, это может быть полезно, когда зададитесь вопросом о версии

Нет, я просто скачал эмулятор и воспользовался встроенными образами :) Мне не для автотестов, скорее мануальные. Был бы признателен за совет. За ссылку спасибо, изучу

в свои достижения можно смело записывать любую активность на благо проекта, которая выходит за рамки твоих прямых должностных обязанностей/твоего грейда.
ну типа, замутил базу знаний проекта - достижение;
навел порядок в бэклоге и ПМ тебя не отматерил - достижение;
придумал как сократить время регресса - достижение.

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

по части улучшения процессов конечно сложнее что то придумать, но только в том случае, если о них кто-то уже хорошо подумал за тебя. мне в таких местах поработать еще не доводилось)))
в общем, если не быть амебкой, то ачивки можно клепать будучи джуном с первых месяцев работы

но можно рассердить своих коллег мидлов/сеньоров чрезмерной активностью😂

А, тогда не замудрчйтесь. Поднимайте образ из студии и наслаждайтесь

Я про андроид студио не знал (я не тестировщик вообще, если что), сейчас уже пробую как раз. Смотрю для 9 и 11 версии только есть поддержка ARM, с 10 они решили не заморачиваться. Но мне подойдет и 9, 11

Классик Канер написал не одну работу о том что метрики по большей части отстоищное отстоище отстойного отстоя.

Время на регрессию зависит от качества того что сделали.  Практически линейно (чем больше багов, тем больше баг-репортов, фиксов и пр.)

Пасс рейт вообще ни о чём. Потому что "test cases are like briefcases" -- от того как написано пасс рейт может быть очень разным, и всего один кейз критичным до "нельзя релизить, влетим на большие деньги".

Покрытие чего? Как? Ответы на этот вопрос вовсе не тривиальны -- если вы покрываете сценарий ABC , это не значит что вы покрывает BCA или СBA, и тем более ABBCBABC.

И с совершенно всей проходящей автоматизацией и 100% пасс рейтом продукт может оказаться или заказчикам или пользователям в итоге не нужен, как Windows Phone или Windows store

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