Тестирование видеоигр, или Легкий способ попасть в геймдев

Этот принцип логически вытекает из предыдущего. Тебе физически не хватит времени провести тестирование, которое полностью покроет весь функционал игры и все ее части во всех возможных вариантах и случаях ее использования. Такое тестирование возможно только в очень незначительном количестве тривиальных случаев. Поэтому вместо того чтобы пытаться объять необъятное, стоит научиться использовать различные подходы и методологии, чтобы, распределив силы и расставив приоритеты, сосредоточиться на максимально возможной в плане эффективности проверке. В некоторых случаях (например, когда мало времени) тестирование, основанное на анализе рисков, будет наиболее эффективным и предпочтительным.

3. Раннее тестирование сохраняет время и деньги

Большинство проектных менеджеров подтвердят, что ресурсов всегда не хватает. Не хватает квалифицированных сотрудников, необходимого аппаратного обеспечения, денег и времени, чтобы с минимумом проблем завершить проект. Они также подтвердят, что ошибка, сделанная на раннем этапе разработки, может привести к серьезным последствиям на более поздних этапах. А учитывая то, что ресурсов и так не хватает, последствия ранних ошибок могут стать катастрофическими. Одна из главных задач и одно из самых ценных умений тестировщика – понимание и обнаружение первопричин дефекта, то есть самых ранних действий, которые и привели к возникновению в игре бага. И поскольку любой проект развивается в рамках определенных стадий, то можно только представить, к каким последствиям приведет ошибка, сделанная на этапе разработки требований. Все усилия разработчиков по реализации задач, основанных на ошибочных требованиях гейм-дизайнера, будут перечеркнуты, поскольку они будут также ошибочными по определению. Есть ли выход из подобной ситуации? Конечно! Тестирование должно начинаться как можно раньше. В разработке игр – часто даже раньше разработки требований, еще на этапе концепции (идеи), а иногда и еще раньше – на этапе гипотезы, когда принимается решение о том, стоит ли вообще начинать разработку продукта на текущем этапе.

4. Кластеризация дефектов

Многие тестировщики замечают, что дефекты могут «кучковаться», как жучки, выползающие на теплый камень в солнечную погоду. Часто это объясняется тем, что определенные области игрового продукта особенно подвержены «заражению», и, обнаружив такую область, мы найдем большее количество багов, чем в других местах. Знания, где начинать поиски багов в игре, могут помочь в тех ситуациях, когда нам серьезно не хватает времени. Например, в мобильной игре мы можем начать с проверки реализации адаптации игры под разные разрешения экрана. Другой пример – проверка настроек моделей персонажей и их взаимодействия между собой.

5. Парадокс пестицида

Впервые аналогию между тестированием программного обеспечения и обработкой полей пестицидами в сельскохозяйственной практике провел Борис Бейзер еще в 1990 году. Под парадоксом он имел в виду то, что постоянное использование одного и того же набора тест-кейсов для поиска дефектов приводит к тому, что он перестает обнаруживать баги так же, как использование одних и тех же пестицидов для борьбы с вредными насекомыми. Они попросту адаптируются к яду, и он постепенно перестает на них действовать. Красивая аналогия. Но почему это происходит в действительности? Прежде всего потому, что невозможно использовать все тест-кейсы: это противоречит одному из ранее изложенных принципов тестирования. Но даже простые приложения, например «Тетрис», требуют использования довольно большого количества тест-кейсов для проверки всех возможных сценариев и комбинаций данных. Кроме того, функциональность продукта изменяется со временем, и, внося изменения в один из элементов системы, мы не можем не изменить всю систему. А раз система меняется, то следует искать новые способы обнаружения дефектов в ней. Ну и, наконец, тестировщик должен модифицировать тест-кейсы, исходя из человеческой психологии. Причем не своей, а разработчика и конечного пользователя.

Виктор Гляненко, QA-директор Saber Interactive