Содержание
Тестирование локации
В процессе работы над локацией наступает момент, когда работу нужно передавать в QA отдел (Quality Assurance, отдел занимающийся тестированием). Данный этап неизбежен, и к нему нужно довольно тщательно подготовить наш уровень. В свою очередь, QA ищет и пытается провоцировать различные проблемы, чтобы игрок с ними не встретился.
Если отдел тестирования уже не видит существенных и критических проблем, то данный этап работы над локацией может считаться завершенным, и можно приступать к следующему этапу.
Когда QA находит проблему в уровне, ее отдают обратно дизайнеру уровней. В некоторых случаях локация становится «шариком для пинг-понга», между QA и левел дизайнером. Дизайнер правит проблему, но не проверяет ее, тем самым она оказывается решена не до конца, и тестировщик указывает на проблему снова.
Такое необходимо избежать, нужно помнить о том, что левел дизайнер — первый тестер своей локации.
Многие проблемы может заметить только дизайнер уровней, и их нужно решать сразу и стоит исключить любые возможности возникновения. Тестирование не может охватить все кейсы, и для их исключения потребуется больше усилий, чтобы избежать постоянных правок итерациями, стоит проверять локацию перед отдачей в тестирование.
Лучше оставьте QA на обнаружение действительно важных вещей.
В примере я показал один из вариантов, в данном случае дизайнер уровней может видеть смещенный триггер, к
который в некоторых случаях может привести к критическим проблемам, таким как блокирование прохождения игры без этого триггера. Тестер не сможет заметить этот кейс, только если не будет проходить всю локацию сидя, а это «слегка» затруднительно.
Когда и как стоит тестировать локацию? Определенно, тестировать локацию после каждого малейшего изменения не имеет смысла, первые тестирования стоит проводить на первых итерациях, нужно проходить всю локацию для понимания проблем дизайна и критических проблем проходимости.
Во время внесения правок в локацию, если выделен отдельный кейс, необходимо проверить, что проблема не воспроизводится и что соседние связанные элементы не пострадали в процессе правок. Это может предотвратить генерацию новых проблем.
Если вы знаете о баге, но QA его не обнаружили, это не значит, что его нет. Стоит поправить его сразу при обнаружении, иначе проблемы могут в более поздней стадии разработки, когда решение будет дороже, займет больше времени и будет сложнее, например на этапе pre-production.
Типичный флоу тестирования
QA тестируют локацию дольше чем LD. Также передача задачи до QA и обратно занимает определенное количество времени обоих людей. Это менее выгодно, чем сделать экспресс-тестирование локации или ее части, которое займет крайне небольшое время дизайнера уровней, там самым предотвратив повторения обратной передачи задачи от тестировщиков.
Этап самотестирования или просмотра локации точно исключит видимые проблемы, которые 100% смогут заметить QA. Пусть они потратят время на более скрытые проблемы локации. Если не потратить немного времени сейчас, то мы потратим больше времени и не только своего. И наконец, лучше оставить QA на поиск действительно важных проблем.
