Хороший план тестирования должен включать в себя ответы на следующие вопросы.
1. Что именно нужно тестировать? (Нужно описать объект тестирования, то есть сам игровой продукт. Это не только поможет быстрее адаптировать нового члена команды, но и во многом заменит отсутствующую документацию.)
2. Что будет тестироваться? (Тот функционал игры, который ты собираешься протестировать с максимальным покрытием.)
3. Как именно будет проводиться тестирование? (Нужно описать виды тестирования и типы проверок в рамках избранной стратегии тестирования и метрики для осуществления эффективного мониторинга.)
4. Когда именно будете проверять? (Это фактически информация о сроках и этапах тестирования.)
Кроме этого, в плане обязательно нужно отразить информацию о:
1. критериях начала и окончания тестирования;
2. программно-аппаратной части, используемой для тестирования (тестовой платформе);
3. потенциальных рисках продукта и проекта и плане управления ими.
Ну, и, конечно, тест-план должен учитывать и быть основанным на документе более высокого порядка – проектном расписании. Если изменения вносятся в него, то должен поменяться и тест-план.
В самом начале я говорил о том, что один из лучших источников информации о фактическом результате, содержащих подробное описание игрового процесса, игровых механик, баланса и проч., – написанные требования.
Плохая новость: этот документ, как и сам план тестирования, могут очень быстро устаревать из-за стремительного «творчества» гейм-дизайнеров или из-за того, что не все команды могут выделить ресурсы для поддержания документации в актуальном состоянии. И их использование в работе тестировщиков теряет всякий смысл.
И все же игровой продукт и игровой процесс должны быть описаны как можно подробнее. Чтобы понять, как устроена игра, поможет собственный игровой опыт, информация из открытых источников об играх-аналогах и опыт коллег. Нужно понимать, что от того, насколько точно и подробно ты можешь описать игру, зависит то, насколько полным окажется тестовое покрытие, поскольку все из твоего описания функционала игры будет использовано в «ожидаемых результатах» тест-кейсов, проектируемых на следующем этапе.
Далее. При планировании работ тебе нужно определить, что конкретно нужно делать для проверки различных областей тестируемого продукта и какие конкретно тесты использовать при проведении функционального и нефункционального тестирования.
Функциональное тестирование – это проверка соответствия реализованного игрового функционала формальным требованиям и спецификациям, а если их нет – требованиям и ожиданиям пользователя. Это проверка того, ЧТО можно делать в игре.
Нефункциональное тестирование – это проверка того, КАК работает продукт, то есть определение характеристик ПО, которые могут быть измерены различными величинами. К нефункциональному тестированию традиционно относят следующее.
• Основные виды тестирования производительности:
· нагрузочное тестирование (Performance and Load Testing)
· тестирование стабильности или надежности (Stability/Reliability Testing)
• Тестирование установки (Installation Testing)
• Тестирование удобства пользования (Usability Testing)
• Тестирование на отказ и восстановление (Failover and Recovery Testing)
• Конфигурационное тестирование (Configuration Testing)
• Тестирование безопасности (Security and Access Control Testing)
Следующий шаг – определиться со стратегией тестирования, выбор которой зависит от разных обстоятельств и условий. Опыт показывает, что в случаях тестирования игр в большинстве случаев выбирается аналитический подход. В одних случаях главным становится анализ некоторого фактора (например, требования или риска). В других – моделирование различных процессов, например игровой функции (движение персонажа) или нефункциональной характеристики (выдерживание игровым сервером определенной нагрузки). Стратегий довольно много. Также много об этом написано в разной литературе (например, в силлабусе «QA-Manager» ISTQB).