проект развивается в рамках определенных стадий, то можно только представить, к каким последствиям приведет ошибка, сделанная на этапе разработки требований. Все усилия разработчиков по реализации задач, основанных на ошибочных требованиях гейм-дизайнера, будут перечеркнуты, поскольку они будут также ошибочными по определению. Есть ли выход из подобной ситуации? Конечно! Тестирование должно начинаться как можно раньше. В разработке игр – часто даже раньше разработки требований, еще на этапе концепции (идеи), а иногда и еще раньше – на этапе гипотезы, когда принимается решение о том, стоит ли вообще начинать разработку продукта на текущем этапе.
4. Кластеризация дефектов
Многие тестировщики замечают, что дефекты могут «кучковаться», как жучки, выползающие на теплый камень в солнечную погоду. Часто это объясняется тем, что определенные области игрового продукта особенно подвержены «заражению», и, обнаружив такую область, мы найдем большее количество багов, чем в других местах. Знания, где начинать поиски багов в игре, могут помочь в тех ситуациях, когда нам серьезно не хватает времени. Например, в мобильной игре мы можем начать с проверки реализации адаптации игры под разные разрешения экрана. Другой пример – проверка настроек моделей персонажей и их взаимодействия между собой.
5. Парадокс пестицида
Впервые аналогию между тестированием программного обеспечения и обработкой полей пестицидами в сельскохозяйственной практике провел Борис Бейзер еще в 1990 году. Под парадоксом он имел в виду то, что постоянное использование одного и того же набора тест-кейсов для поиска дефектов приводит к тому, что он перестает обнаруживать баги так же, как использование одних и тех же пестицидов для борьбы с вредными насекомыми. Они попросту адаптируются к яду, и он постепенно перестает на них действовать. Красивая аналогия. Но почему это происходит в действительности? Прежде всего потому, что невозможно использовать все тест-кейсы: это противоречит одному из ранее изложенных принципов тестирования. Но даже простые приложения, например «Тетрис», требуют использования довольно большого количества тест-кейсов для проверки всех возможных сценариев и комбинаций данных. Кроме того, функциональность продукта изменяется со временем, и, внося изменения в один из элементов системы, мы не можем не изменить всю систему. А раз система меняется, то следует искать новые способы обнаружения дефектов в ней. Ну и, наконец, тестировщик должен модифицировать тест-кейсы, исходя из человеческой психологии. Причем не своей, а разработчика и конечного пользователя.
Виктор Гляненко, QA-директор Saber Interactive
Один из ярких примеров эффекта пестицида на практике я встретил в начале своего пути тестировщика. При работе над своим первым проектом – шутером – команда QA была поделена по игровым уровням, которые ежедневно проверялись с точки зрения прохождения. В какой-то момент уровень
