2. Логика и отсутствие противоречий
Функционал игрового продукта должен основываться на логике. Даже в самых элементарных ситуациях порой отсутствует логика, что сильно расстраивает игроков. Описываемый функционал не должен также вступать в противоречие с существующими правилами и традициями. Например, крестик в верхнем правом углу закрывает окно, а не сворачивает его.
В игре в жанре MMORPG появилась возможность платного изменения внешности игрового персонажа. После оплаты однократной смены внешности игрок поменял пол персонажа, цвет кожи и прическу своему персонажу и нажал кнопку «Далее». В игре предлагается подтвердить сделанный выбор, нажав на кнопку «Применить». Внезапно пользователь обнаруживает, что прическа персонажа не та, которую он хотел бы, но на экране нет кнопки «Отменить», и игрок может только применить уже сделанные изменения. Игрок решает закрыть приложение и через некоторое время переустановить его, но при входе в аккаунт он видит тот же экран с кнопкой применить. Естественно, игрок очень огорчен и пишет гневное письмо на форуме поддержки, где к нему присоединяются еще несколько таких же возмущенных пользователей.
В этом случае функциональность, описанную в требованиях, можно проверить с помощью блок-схем, изображающих работу системы. Логические пробелы в планируемом функционале будут сразу видны.
3. Актуальность
То, что документация по проекту должна быть актуальной, очевидно. Однако есть проекты, в которых документация не обновляется в течение значительного времени. Часто разработчики считают, что документ нужно обновить только в том случае, если изменения в требованиях действительно серьезные, а на всякие мелочи можно не обращать внимания. В результате требования не только утрачивают актуальность, но и происходит довольно серьезная путаница.
Заказчик попросил изменить положение кнопок на странице. Документацию решили не исправлять, поскольку изменения показались тривиальными. Менеджер проекта попросил внести изменения устно, позвонив программисту по телефону. Разработчик внес правки и описал изменения в задаче для тестировщика. Тестировщик проверил функционал, не обнаружил в нем ошибок и закрыл задачу. Но через некоторое время во время регрессионного тестирования другой тестировщик, не знавший о договоренности, решил, что это дефект, поскольку внимательно читал техническое задание, и составил отчет о дефекте. Другой разработчик, который тоже не знал о договоренностях, но читал документацию, вернул кнопки на прежние позиции.
4. Возможные сценарии
В документах необходимо подробно описывать все варианты использования системы, очевидные и неочевидные. Неочевидные варианты, как правило, связаны с попытками взлома функционала системы, рассеянностью пользователей, отсутствием навыка использования подобных систем и т. д. К очевидным (позитивным) вариантам можно отнести ввод корректной пары логин/пароль, а к неочевидным (негативным) – ввод некорректной пары логин/пароль или отсутствие этих данных.
В этом случае проверяющий должен понимать все возможные условия и действия пользователя и убедиться в том, что в требованиях есть описание каждого возможного случая.
5. Пересечения с уже существующими функциональностями
В документации необходимо подробно описать, как существующие механики пересекаются друг с другом. Это важно, потому что при реализации нового функционала в будущем можно легко упустить из виду и «потерять» возможность использовать одну из функционирующих механик.
В игре к Хэллоуину было подготовлено особое игровое событие, которое полностью изменяло главный экран, включая пользовательский интерфейс, с которого игроки выходили в бой. При реализации события была упущена из виду реферальная программа, с помощью которой игроки могли приглашать новичков в игру и получать за это игровые бонусы. Игрок договорился с другом, что он пригласит его в игру и они вечером отыграют несколько партий вместе, но, зайдя на главный экран, не смог найти нужной ему кнопки. Конечно, он отправляется на форум поддержки, где изливает свое негодование в гневных сообщениях в адрес разработчиков.
6. Интеграция
Интеграции со сторонними сервисами должно уделяться больше внимания, потому что такие проверки включают в себя работу с большим количеством документации. Вероятность ошибок в этом случае существенно выше, так как их могут допускать специалисты, разрабатывающие документацию (например, случайно используя устаревшую документацию сторонних сервисов), и консультанты со стороны этих сервисов, которые могут предоставить неправильную консультацию.
Нелишним будет вручную проверить, что сторонний сервис обрабатывает все необходимые запросы в соответствии с описанной схемой.
7. Отсутствие ошибок написания и опечаток
При чтении тестировщик может обнаружить разные опечатки, ошибки в грамматике и пунктуации. Такие ошибки могут показаться тривиальными, но это не всегда так. Иногда опечатка влечет замену одного слова другим, из-за чего текст либо полностью утрачивает смысл, либо приобретает новый (например, «ржущий» вместо «режущий»). А иногда разработчик не вникает в смысл написанного и просто копирует часть документа (например, надписи на кнопках). В таком случае ошибка из документации попадает прямо в игру.
Разработчик скопировал из документа слово «Отрыть» (предполагалось, что это «Открыть», но разработчик документации сделал в нем опечатку). В итоге в среде игроков появился новый мем, вызывающий смех и ироничное отношение к качеству продукта.
Все сказанное выше относится к любому виду документации: от гейм-дизайнерской документации до технических заданий.
Ниже приведены основные (но не все) подходы к тестированию требований.
1. Рецензирование / партнерская проверка / парное рецензирование (Peer review)
Оно может быть представлено тремя независимыми подходами.
А. Партнерская проверка созданного другим автором на предмет выявления явных ошибок, непонятных мест, спорных мест и всего того, что вызывает вопросы, БЕЗ каких-либо исправлений. После просмотра документ возвращается автору для внесения исправлений. Этот подход может быть использован и одним человеком (например, автором документа). В этом случае после создания документа должно пройти не менее 5–7 дней, после чего автор вновь просматривает свой документ для выявления всех спорных или сомнительных мест.
Б. Техническое ревью, как правило, проводится специалистами разного профиля и помогает выявить неточности и узкие места в документе, затрагивающие разные области.
В. Инспекция – наиболее формальный вид рецензирования. Она проводится по специальной процедуре, и затем в исходный документ вносятся изменения.
2. Задавание вопросов (Asking questions)
Подход подразумевает задавание вопросов для прояснения требований, подвергая изложенное в документации критическому анализу. Вопросы должны задаваться во всех непонятных, спорных и расплывчатых ситуациях. После получения ответов на вопросы документация уточняется.
3. Использование чек-листов (Check-lists)
Анализируя требования, следует задать себе вопросы: «Как я собираюсь эти требования проверять?», «Существуют ли тест-кейсы для проверки данных требований?», «Существуют ли тесты, которые способны доказать объективно, что эти требования написаны правильно?» Когда таких вопросов много, можно составить для себя чек-лист: он поможет не только протестировать требования, но и даст понимание того, насколько глубоко требования были протестированы.
4. Визуализация (Visualization)
Этот метод позволяет представить проверку требований наглядно и компактно, что немаловажно при работе с объемными материалами. Можно использовать любые известные нотации[38] типа UML[39] или любые другие системы, позволяющие представить информацию в наглядном виде. Также может быть использована одна из техник тест-дизайна – диаграмма перехода состояний, о которой мы говорили выше.
5. Моделирование и прототипирование (Modeling and Prototyping)
Это способ построения модели или симуляции системы, которую должны построить разработчики. Это очень популярный метод проверки требований среди заинтересованных сторон, поскольку он помогает легко выявлять проблемы и обнаруживать отсутствующие требования. Тестировщики могут связаться с пользователями и заинтересованными сторонами и получить их отзывы.
Также существенно повысить качество результатов проверки может следующее.
1. Участие правильных заинтересованных сторон
2. Разделение идентификации и исправления ошибок
3. Проверка с разных точек зрения
4. Повторная проверка
4.6. Автоматизация тестирования игр
В игровой индустрии довольно давно активно обсуждается вопрос автоматизации тестирования игровых продуктов. Ее сторонники предлагают автоматизировать практически все аспекты игры. Однако многие специалисты настроены скептически и считают, что в игровой индустрии автоматизация тестирования возможна только в ограниченных, конкретных сценариях.
Они приводят следующие аргументы.
Затраты на автоматизацию
Затраты на оплату труда разработчиков для создания дополнительного кода в игре, необходимого для поддержки автоматизации (а также написания скриптов и других тестовых инструментов, интерфейсов и прочего), могут в разы превысить расходы на оплату мануального тестирования. Кроме того, код, написанный для автоматизации тестирования, может содержать собственные ошибки и недоработки. Автоматизация тестирования может значительно увеличить как бюджет, так и время разработки игры. Угроза увеличения расходов и дополнительных задержек без гарантированных преимуществ делает задачу одобрения внедрения автоматизированного тестирования трудной для многих руководителей.