Это хорошо!

жесть текста, устал читать

20 литров пива за пятницу-субботу, да это рекорд!

Мы не пускаем игроков без гугл сервисов 😅 или ставят сами, или не играют. Сильно мало пользователей таких было, не стали с бубном танцевать

У хуавея есть свой HMS kit на основании которого ваше приложение получает функционал их пушей. А насчет оплаты - в этом случае инаппы могут помочь

Всем привет, есть тут добрые люди, которые помогут ответить на парочку вопросов начинающему тестеру?

"Тебе отдали фичу на тестирование. В попытках разобраться, как именно должна работать данная фича, ты идёшь к гейм-дизайнеру, потом к программисту. Каждый из них по разному описывает, как должна работать фича. Как начать тестирование?"

Главное — начать руками, но ни в коем случае не хоботом и не хвостом.
Начать вообще без проблем — самому попробовать.
Если есть вопросы "почему так" (а разногласия дизайнера и программиста вполне себе повод для вопроса "как реально надо"?) — идти к тому кто назначен решающим лицом в этом вопросе. Неизвестно кто решает — спрашивать тим лида / менеджера, "кто здесь главный".

окей, спасибо

"Разработчики с опозданием сдают тебе фичу на тест. Время на тестирование ужимается в 2 раза из-за необходимости сдать фичу в заранее обговоренный срок.
Твои действия?" а вот такой вопрос еще

Вначале вопрос насколько необходимо и с какими рисками это связано (если риски слишком велики, вроде возможных летальных исходов или катастроф, то обосновывается задержка).
Если ну вот надо, а смертельных рисков нет, делается приоретизация тестирования по каким-то критериям (самые важные сценарии, например, или отказ от каких-то тестовых действий которые были бы сделаны если бы было полное время {в моей практике часто могли пожертвовать сценариями автоматизации — когда обычно делали, но если не было времени, то нет}).

большое спасибо)

У вас автоматизация одновременно велась с мануальным тестированием? Или все же с опазданием?

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

По идеалам-принципам аджайла это стоит обсудить и с клиентами и с командой и с продакт овнером, и с представителями заказчика или около заказчика если они есть — какие риски, как лучше.

Авторы вопроса скорее всего хотят попроще, про приоретизацию, но на практике разное бывает.

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

Иногда вспомогательные инструменты нужны по ходу тестирования, для выявления тестовых данных на которых есть проблемы.

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

Это не совсем то, что в моем представлении было. Но я понял, спасибо. Разрабатывали свой фреймворк для автотестов и вот очень редко когда спринт в спринт успевали покрыть автотестами критические сценарии. Потому немного странно для меня увидеть ваш ответ про отставку тестирования автоматизации. Наверное я не так немного понял что вы имели в виду.

> и вот очень редко когда спринт в спринт успевали покрыть автотестами критические сценарии

Но бывает и так что этого хотят, и оно включается в "definition of done". Тоже с таким встречался.

Сколько же тогда спринт длиться?

Две недели стандарт. Чтобы в это уложиться команды прибегают к разным вариантам — отдавать в тестирование раньше а на конец спринта брать документирование или техдолг или ещё что.

Дело не в том что я это одобряю, а в том что я сталкивался с тем что такого хотели на практике. Иногда ещё и перфоманса могли хотеть.

Ну тогда ясно.