Comments 18
А бета-версия для ios-пользователей отсутствует?
UFO just landed and posted this here
Недавно появилась мысль включать запись микрофона на тестовых билдах и отдавать тестировщикам. В идеале при этом записывать экран.
Так, при прослушивании «подопытных» можно выявить проблемы UX, отвалы на разных стадиях игры и просто неочевидности.
Я бы хотел протестить эту методику самостоятельно, но пока что у меня нет собственного публичного проекта, готового для тестирования.
Как вы относитесь к этой идее? Если будете проверять, было бы очень интересно узнать о результатах.
Так, при прослушивании «подопытных» можно выявить проблемы UX, отвалы на разных стадиях игры и просто неочевидности.
Я бы хотел протестить эту методику самостоятельно, но пока что у меня нет собственного публичного проекта, готового для тестирования.
Как вы относитесь к этой идее? Если будете проверять, было бы очень интересно узнать о результатах.
Не считаю что это корректно, даже с точки зрения законности и этичности такого тестирования. Скрытно включать микрофон — наказуемо, а говорить тестировщику что мы будем его записывать — никто на такое не пойдет. Пока что такие варианты не рассматриваются.
Не скрытно же. Тестеры будут знать об этом. Интересует именно тот вариант, когда в ежедневном отчёте детали забываются, тонкости опускаются, а неочевидности умалчиваются.
Необъективное тестирование будет. Будет сильно съедаться заряд батареи, очень сильно понизится производительность (за счет записи экрана), не говоря о том, что даже при согласии человека на такое тестирование в микрофон может проскочить то, что он не захочет отправлять (может, он дома находится, или еще где, что уже относится к частной жизни). Да и далеко не каждый комментирует процесс тестирования вслух, это как раз исключение из общего правила (ну либо когда приложение настолько плохое, что без матов тестить не получается, но это тоже скорее исключение). Имхо, очень сомнительный вариант. Сбор обратной связи в виде просто вручную отправленных тестерами ошибок — этого более, чем достаточно, особенно если система обратной связи встроена прямо в приложение («потрясите телефон, чтобы отправить баг», и им подобные).
Для этого достаточно дать игру летсплейщикам и посмотреть прохождение. Как правило, их реакция на игру — это реакция «среднего игрока».
Вижу что вы очень серьезно относитесь к качеству и тестированию. По моему опыту ручное тестирование может выявить дай бог 10% багов.
Интересно, проводите ли вы только ручное тестирование, или же еще пользуетесь автоматизированным? (Unit тесты, игровые боты и т.д.). Например, мне, в свое время, очень помог игровой бот, который выявлял проблемы с уровнями, которые были только на определенных устройствах.
Успехов с проектом!
Интересно, проводите ли вы только ручное тестирование, или же еще пользуетесь автоматизированным? (Unit тесты, игровые боты и т.д.). Например, мне, в свое время, очень помог игровой бот, который выявлял проблемы с уровнями, которые были только на определенных устройствах.
Успехов с проектом!
Сейчас ограничиваемся ручным тестированием и синтетикой от Firebase. После того как будет полностью готов баланс будем тестировать полной автоматизацией, под которую нужно писать сценарии. Пока что на это, увы, просто не хватает рук.
Я первое время тоже шел по пути «не хватает рук», но потом понял, что тестировать Unit-тестами всякую логику для meta-игры гораздо проще. Не каждый раз запускать игру и проверять. С геймплеем, конечно, все посложнее будет. Но это точно никак меня не замедлило, скорее наоборот.
Спасибо за совет! Может у вас есть практические идеи, как это можно организовать максимально эффективно? Был бы очень признателен.
В целом, вся бизнес-логика мета-игры должна быть отвязана от Unity-классов. Тогда написать Unit тесты не составит проблем. Чтобы начать unit-тестить можно попробовать туторы от Unity.
Идея в том, чтобы Unity был только прослойкой для вызова соответствующих методов. Тогда после написания бизнес-правил и unit-тестов, все что останется — привязать соответствующие вызовы из UI.
Если тесты написаны правильно, то все должно работать как часы. И проблемы могут быть только на стороне UI или взаимодействия с сервером.
Плюс ко всему можно прикрутить проверку тестов к вашему билд-пайплайну. Собирается билд, сразу запускается проверка тестов. Если все ок — можете быть спокойны, что хотя бы протестированная часть игры будет работать правильно.
Помимо Unit-тестов можно так же сделать интеграционные тесты. Например, я тестировал интграцию с facebook, получив руками токен, и запуская тесты, которые дергали разные API методы FB и проверяли, что наш код работает ок.
Такие штуки могут так же позволить отловить проблемы, когда инеграция со сторонним сервисом отваливается.
Но в принципе, unit-тесты самый простой и быстрый способ.
Идея в том, чтобы Unity был только прослойкой для вызова соответствующих методов. Тогда после написания бизнес-правил и unit-тестов, все что останется — привязать соответствующие вызовы из UI.
Если тесты написаны правильно, то все должно работать как часы. И проблемы могут быть только на стороне UI или взаимодействия с сервером.
Плюс ко всему можно прикрутить проверку тестов к вашему билд-пайплайну. Собирается билд, сразу запускается проверка тестов. Если все ок — можете быть спокойны, что хотя бы протестированная часть игры будет работать правильно.
Помимо Unit-тестов можно так же сделать интеграционные тесты. Например, я тестировал интграцию с facebook, получив руками токен, и запуская тесты, которые дергали разные API методы FB и проверяли, что наш код работает ок.
Такие штуки могут так же позволить отловить проблемы, когда инеграция со сторонним сервисом отваливается.
Но в принципе, unit-тесты самый простой и быстрый способ.
Sign up to leave a comment.
С чего начать молодым разработчикам мобильных игр из России [Часть 3]