Как искать баги в играх

Что такое баги в игре и как их находить при тестировании

Что такое баги в игре и как они классифицируются

Как классифицируют игровые баги:

Функциональный баг. Когда не работоспособны различные функции в игре. Например, когда при смене локации или каких-то настроек выбрасывает из игры.

Логический баг. Он же баг баланса. Когда выставленный баланс и игровая логика просто не дают возможность пройти игру полностью. Например, реальный наносимый урон не соответствует заявленному, или в игре сталкивают игроков разных уровней, где явно видно превосходящее преимущество одних над другими, что фактически обеспечивает им победу.

Баг совместимости. К примеру, игра не запускается на совместимых устройствах.

Н о эт о еще не все. Это была классификация по происхождению бага. Еще они классифицируются по приоритетности и скорости их устранения. В этом случае выделяют три категории:

Баги, мешающие пользователям игры. В целом влияют на количество игроков, на различные рейтинги и т. д.

Баги, мешающие бизнесу. В этой категории подобные баги могут не мешать пользователям, но мешать компании зарабатывать деньги на игре.

От чего зависит количество багов в играх

Игровой процесс. Чем сложнее процесс и больше функциональности в игре, тем больше шансов, что при их реализации возникнут ошибки в игре.

Сетевая игра. Если игровой процесс задумывается для сетевой игры, то возника ю т дополнительные трудности в налаживании взаимодействия между игроками, плюс накладываются возможные баги при балансировке. Поэтому в сетевых играх часто даже после удачного альфа-тестирования и устранения ошибок после запуска игры в сеть появляются н ео чевидные баги и проблемы с балансом.

Сетевой режим RPG-игр. Огромный игровой мир с просто невероятным количеством возможных сценариев при взаимодействии игроков между собой.

Графическая мощь игры. Трудно абсолютно без багов адаптировать мощные игры под разные устройства.

Как искать и находить баги в играх

Как искать и находить баги в играх, советы:

Фокусировка. Важно фокусироваться именно на процессе поиска, а не на процессе игры. Можно даже держать постоянно в голове мысль: «Здесь должен быть баг!»

Нельзя ничего пропускать. Даже если заметили небольшой баг, нельзя его игнорировать и искать что-то «крупнее». Один малый баг может породить несколько больших, нужно помнить об этом.

Тестировать разные жанры. Нужно тестировать разные жанры игр или даже разные проекты, чтобы глаз не «замылился» и вы всегда были способны вовремя заметить ошибку.

Заключение

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Источник

Разновидности «игровых» багов

Было бы странно, если в такой комплексной системе как видео игры не было багов. Они есть, встречаются часто и этот бестиарий здесь крайне разнообразен. Ознакомившись с вышеприведёнными видами тестирования для игр, думаю вы догадываетесь, что и баги в видео играх встречаются далеко не только «404 not found» и «game crashed». Давайте же пробежимся по самым часто встречающимся из них в игровой индустрии!

В категорию Visual багов войдут: любые видимые артефакты (Visible Artefacts), пропущенные текстуры (missing textures), Clipping, Culling, Screen tearing, Z-fighting.

Примеры визуальных багов можете посмотреть ниже:

Вупс. Что-то пошло не так

Пропущенная текстура и хороший пример «шахматки» вместо потерянного файла

Вот так можно легко «войти» в объект с кривой коллизией (или без неё вовсе) Баг такого рода также можно описать термином occlusion, т.е. перекрытие одного объекта другим не так как задумано.

В рамках Audio bugs группы выделю достаточно базовые, но не менее надоедливые вещи: не возможность проиграть SFX/музыки/диалога, пропуск (тригера) проигрыша, плохое микширование (звук слишком тихий или громкий), искажения (distortions), дропы.

Герой не может пройти дальше из-за невидимой стены, однако дорога всё не заканчивается.

Map Holes чаще всего вызваны не плотным прилеганием плоскостей объектов (пол, стены и т.п.). Это места, где пользователь может, незапланированно для разработчиков, попасть за границы игровой зоны. Такие баги часто ещё называют Out of Bounds.

А вот так ваша игра выглядит «изнутри»

Баги Navigation Mesh часто связаны с перестройкой уровня или автоматической генерацией сетки. К примеру вы передвинули предметы, однако навигационная сетка осталась старой. Как следствие, ваши NPC могут «идти в стену» или любой другой предмет, который они не смогут обойти и встрянут там (один из случаев Stuck Points).

Здесь Nav Mesh проходит сквозь объекты в красном круге

Ошибки искусственного интеллекта (AI): NPC не двигаются, застряли, не следуют за игроком, предполагаемое взаимодействие с предметами не работает, застревание, NPC делают то, что не задумано изначально и т.п.

Раз уж у нас есть и часть движка, отвечающая за физику, то было бы странно, если бы и багов с физикой не было. Тут может быть почти что угодно: левитирующие объекты, нереалистичная физика, ускорение свыше нормы, а также взмывание предметов » в космос» из-за сложения векторов при обработке контактов. Баги такого рода вы могли видеть в мемах самых разных игр, например GTA 5 или, из актуалочки, Cyberpunk 2077. Хороший разбор многих багов из Cyberpunk 2077, включая только что описанные, можно посмотреть тут.

Баги стабильности и перформанса включают в себя фризы, краши, чёрные экраны, невозможность загрузить уровень, видимая для пользователя подгрузка хай поли моделей или вообще каких-либо объектов, просадка FPS, дооооооооолгая загрузка, а также микрофризы (подгрузки). Сюда же добавлю слишком долгую инсталляцию игры, а также невозможность запустить игру на ПК с минимально допустимыми требованиями.

Извините, я вас не узнал. У вас лицо не прогрузилось

Не редко встречаются и баги совместимости. Особенно частые примеры выглядят следующим образом: на некоторых видеокартах могут встречаться краши (к примеру на минимально возможных требованиях или новых видеокартах на рынке), контроллеры той или иной фирмы не работают, игра не запускается на какой-то определённой версии ОС, беспроводная гарнитура выдаёт звук в моно и т.п.

О проблемах онлайн игр наслышаны все. Плохое соединение, лаги, «невидимые игроки» или же «я зашёл за угол, а меня убили», ошибки подсчёта очков, невозможность реконнекта (если такая фича есть), потеря пакетов во время игры, расхождение в подсчётах информации между клиентом, дедикейтед сервером и бек эндом. Также при плохом соединении некоторые элементы интерфейса можно использовать по несколько раз, что-то может не прогрузиться и «пропасть» и т.д., но, как правило, это UI баги и сильно не влияют на user experience игрока.

С таким количеством повторений, походу это уже не баг, а фича. Пора вводить очереди как в Diablo 2

Зачем мне текст? И так же понятно куда клацать! И люди, и кони, и всё-всё тут намешано

Неужто это всё?

А с какими багами вы встречались во время игры или работы над игрой? Буду рад пообщаться с вами на эту и другие релевантные темы в комментариях!

Источник

Какие баги находят тестировщики?

Сид Мейер как-то сказал, что «Игра — это последовательность интересных выборов». А значит, перед выпуском игры в массы тестировщик должен убедиться, что все выборы в игре интересные и работают правильно. Да и вообще работают!

Игровая механика представляет собой набор правил, по которым работает игра, и математическую модель, которая стоит за этими правилами. Вместе с дизайном уровней и системой обратной связи с игроком эти три столпа составляют тот самый геймплей. Вот по нему и оценивают геймеры свои впечатления об игре.

На каждом из этих этапов встречаются баги и недоработки, потому что игра — это комплексный труд нескольких человек, а когда речь идёт про AAA-проекты — даже не одного десятка людей. И допустить ошибку в одном из компонентов игры довольно легко.

Сегодня мы затронем тему не только локализационного, но и функционального тестирования. А помогать нам будет эксперт и руководитель отдела тестирования компании Inlingo Андрей Васильев.

Чтобы успешно заводить баги, нужно их систематизировать. Разделить и властвовать.

Итак, баги в играх можно условно классифицировать по следующим категориям:

Баги, связанные с самой игрой:

» data-medium-file=»https://i0.wp.com/apptractor.ru/wp-content/uploads/2018/12/1.gif?fit=500%2C281&ssl=1″ data-large-file=»https://i0.wp.com/apptractor.ru/wp-content/uploads/2018/12/1.gif?fit=500%2C281&ssl=1″ svg+xml,%3Csvg%20xmlns=’http://www.w3.org/2000/svg’%20viewBox=’0%200%20500%20281’%3E%3C/svg%3E» alt=»Какие баги находят тестировщики?» width=»500″ height=»281″ data-recalc-dims=»1″ data-lazy-src=»https://i0.wp.com/apptractor.ru/wp-content/uploads/2018/12/1.gif?resize=500%2C281&ssl=1″ />

Потренируемся: какой это баг по классификациям? Если вы ответили: «Функциональный, низкоприоритетный, графический, затрагивающий команду разработки», то ура — вы тестировщик (нет)

Багам присваивается степень критичности: какие-то устраняются в первую очередь, а какие-то можно даже оставить в финальном релизе:

» data-medium-file=»https://i2.wp.com/apptractor.ru/wp-content/uploads/2018/12/2.gif?fit=512%2C288&ssl=1″ data-large-file=»https://i2.wp.com/apptractor.ru/wp-content/uploads/2018/12/2.gif?fit=512%2C288&ssl=1″ svg+xml,%3Csvg%20xmlns=’http://www.w3.org/2000/svg’%20viewBox=’0%200%20512%20288’%3E%3C/svg%3E» alt=»Какие баги находят тестировщики?» width=»512″ height=»288″ data-recalc-dims=»1″ data-lazy-src=»https://i2.wp.com/apptractor.ru/wp-content/uploads/2018/12/2.gif?resize=512%2C288&ssl=1″ />

Иногда разработчики специально оставляют низкоприоритетные баги в игре — для вирусного эффекта. В конце концов, это ведь уморительно, а игры должны развлекать, так почему бы и да?

Баги различают по затрагиваемой стороне. То есть кому они будут больше всего мешать использовать продукт:

От чего зависит число багов в игре?

Действительно, от чего? Почему в одних играх их просто огромное количество на альфа-тестах (привет, No Man’s Sky), а в других — практически нет? Всё довольно очевидно.

» data-medium-file=»https://i1.wp.com/apptractor.ru/wp-content/uploads/2018/12/3.gif?fit=377%2C247&ssl=1″ data-large-file=»https://i1.wp.com/apptractor.ru/wp-content/uploads/2018/12/3.gif?fit=377%2C247&ssl=1″ svg+xml,%3Csvg%20xmlns=’http://www.w3.org/2000/svg’%20viewBox=’0%200%20377%20247’%3E%3C/svg%3E» alt=»Какие баги находят тестировщики?» width=»377″ height=»247″ data-recalc-dims=»1″ data-lazy-src=»https://i1.wp.com/apptractor.ru/wp-content/uploads/2018/12/3.gif?resize=377%2C247&ssl=1″ />

Привязка выявляемого количества багов к жанрам

Хороший пример того, как игроки испытывают игру на прочность. Skyrim в этом смысле рекордсмен.

Сравнительно проще тестировать игры, где действия игрока ограничены, их реально проверить все за обозримое время теста. В основном, это казуальные игрушки:

» data-medium-file=»https://i0.wp.com/apptractor.ru/wp-content/uploads/2018/12/4.gif?fit=444%2C250&ssl=1″ data-large-file=»https://i0.wp.com/apptractor.ru/wp-content/uploads/2018/12/4.gif?fit=444%2C250&ssl=1″ svg+xml,%3Csvg%20xmlns=’http://www.w3.org/2000/svg’%20viewBox=’0%200%20444%20250’%3E%3C/svg%3E» alt=»Какие баги находят тестировщики?» width=»444″ height=»250″ data-recalc-dims=»1″ data-lazy-src=»https://i0.wp.com/apptractor.ru/wp-content/uploads/2018/12/4.gif?resize=444%2C250&ssl=1″ />

COD WWII за принципиально новый эко-транспорт

Такова классификация багов с нашей точки зрения. В ходе написания материала мы нашли интересное видео с выступлением Дмитрия Химиона про «Тестирование игровой механики в компьютерных играх». Он утверждает, что есть ещё одна классификация ошибок в игре.

Ошибки дизайна уровней

Появляются точки на локации вне досягаемости игрока. Застревания в текстурах, кстати, относят сюда же. И надо справедливости ради заметить, что застреваем мы вовсе не в текстуре, а в геометрической модели, потому как текстура — это картинка. Значит, левел дизайнер где-то ошибся и наделал лишних порогов и ступенек, а нога героя застряла и, пытаясь подчиниться законам физики, начинает вытворять невообразимое

Ошибки обратной связи

Сюда относят все ошибки, связанные с элементами контроля и управления. Они могут возникать при неверной калибровке и невозможности сменить в настройках чувствительность мыши или аналоговых стиков.

Ошибки игрового баланса

Игровой баланс — это качественная характеристика, определяющая уравновешенность игровых сущностей и показателей, а еще поддерживающая интерес к игре. Само создание игрового баланса сопряжено с постоянным тестированием, поэтому ошибкой тут может считаться только незавершенное тестирование.

А с какими багами сталкивались вы? Присылайте нам в комментарии — похохочем, что ли.

Источник

Не фича, а баг: тестировщик о классификации игровых глюков

Сид Мейер как-то сказал, что «Игра — это последовательность интересных выборов». А значит, перед выпуском игры в массы тестировщик должен убедиться, что все выборы в игре интересные и работают правильно. Да и вообще работают!

Игровая механика представляет собой набор правил, по которым работает игра, и математическую модель, которая стоит за этими правилами. Вместе с дизайном уровней и системой обратной связи с игроком эти три столпа составляют тот самый геймплей. Вот по нему и оценивают геймеры свои впечатления об игре.

На каждом из этих этапов встречаются баги и недоработки, потому что игра — это комплексный труд нескольких человек, а когда речь идёт про AAA-проекты — даже не одного десятка людей. И допустить ошибку в одном из компонентов игры довольно легко.

Сегодня мы затронем тему не только локализационного, но и функционального тестирования. А помогать нам будет наш эксперт и руководитель отдела тестирования, Андрей Васильев.

Чтобы успешно заводить баги, нужно их систематизировать. Разделить и властвовать.

Итак, баги в играх можно условно классифицировать по следующим категориям.

Багам присваивается степень критичности: какие-то устраняются в первую очередь, а какие-то можно даже оставить в финальном релизе:

Баги различают по затрагиваемой стороне. То есть кому они будут больше всего мешать использовать продукт:

Действительно, от чего? Почему в одних играх их просто огромное количество на альфа-тестах (привет, No Man’s Sky), а в других — практически нет? Всё довольно очевидно.

Сравнительно проще тестировать игры, где действия игрока ограничены, их реально проверить все за обозримое время теста. В основном, это казуальные игрушки:

Такова классификация багов с нашей точки зрения. В ходе написания материала мы нашли интересное видео с выступлением Дмитрия Химиона про «Тестирование игровой механики в компьютерных играх». Он утверждает, что есть ещё одна классификация ошибок в игре.

Появляются точки на локации вне досягаемости игрока. Застревания в текстурах, кстати, относят сюда же. И надо справедливости ради заметить, что застреваем мы вовсе не в текстуре, а в геометрической модели, потому как текстура — это картинка. Значит, левел дизайнер где-то ошибся и наделал лишних порогов и ступенек, а нога героя застряла и, пытаясь подчиниться законам физики, начинает вытворять невообразимое

Сюда относят все ошибки, связанные с элементами контроля и управления. Они могут возникать при неверной калибровке и невозможности сменить в настройках чувствительность мыши или аналоговых стиков.

Игровой баланс — это качественная характеристика, определяющая уравновешенность игровых сущностей и показателей, а еще поддерживающая интерес к игре. Само создание игрового баланса сопряжено с постоянным тестированием, поэтому ошибкой тут может считаться только незавершенное тестирование.

А с какими багами сталкивались вы? Присылайте нам в комментарии — похохочем, что ли.

Если вдруг вы разработчик и хотите, чтобы подобных ошибок в вашем проекте было поменьше, пишите нам на order@inlingogames.com — мы придумаем что-нибудь вместе.

И вообще, доверяйте свои игры профессиональным тестировщикам, да поменьше багов вам в готовых продуктах: далеко не все из них станут легендарными, вроде знаменитого «geddan».

Статья, конечно, не исчерпывающая, но будет полезна для обычного игрока, который в основном считает, что тестирование это альфа и бета, а второе проводится только в рекламных целях. Неплохо было бы еще и про требования расписать, какие бывают и откуда берутся.

Наверное я не обычный игрок, но я так не считаю.

Источник

Как находить баги в играх

тестирование как путь к совершенству

пятница, 27 апреля 2018 г.

Как искать и находить баги

Есть QA инженеры, которые находят много багов, а есть те, кто находит в разы меньше. Много лет размышляя о том, как же это так у меня получается находить в несколько раз больше багов чем у других(и как у других получается находить больше чем нашел я), я сформулировал список советов, соблюдая которые почти любой человек может находить достаточно много багов.

Советы эти очень простые и проверены многолетней практикой многими QA инженерами, с которыми я обсуждал как они ищут и находят баги:



Фокусируйтесь на поиске багов
Все время держите в голове мысль «так, где-то здесь баги и я должен их найти сейчас«. Баги там точно есть, и вы их обнаружите.

Не пропускайте ни один баг (не игнорируйте баги)
Если вы заметили, что что-то не так — сразу пишите баг-репорт. Придумали как можно сделать лучше? — задокументируйте свою идею, пока помните об этом. В результате у вас будет больше найденных багов, и ничего не будет упущено.

Устраивайте короткие сессии поиска багов
Выделяйте по 30-120 минут один раз в день или один раз в неделю — когда вы берете кофе/какао/чаек, одеваете наушники и ищете баги, ни на что не отвлекаясь (никакой почты, разговоров с коллегами, чатиков, социальных сетей — все выключаем и закрываем вкладки — и открываем приложение, которое тестируем).

Делайте такие сессии регулярно, это тоже важно. И при этом не забываем про первые два правила.

Читайте/изучайте теорию тестирования и тест дизайна
Умные люди уже давно все придумали и описали в книжках, не менее умные люди пишут на эти темы блоги, книги и делают выступления на конференциях.

Вам нужна эта информация, и более того — вы должны не просто читать об этом, а обдумать — как зарождалась каждая практика тестирования, где она применима и где она более эффективна, как применить ее на вашем проекте.

Лет десять назад, если вы начинали работать QA инженером, вы могли себе позволить первые пару месяцев не знать о теории тестирования. Сегодня это то, что вас спросят на любом собеседовании, еще до того как вы начнете что-то тестировать )).

Тестируйте разные программы
Не ограничивайтесь тестированием чего-то одного, например, тестированием того проекта, на котором сейчас работаете. Пробуйте тестировать сайты почты, пиццерий, визовых центров, онлайн-кинотеатров, мобильных приложений или чего-то, чем часто пользуетесь или что вам интересно. Изучайте как оно устроено, какие типичные проблемы встречаются на разных ресурсах, какие вообще баги встречаются и какие вы быстрее всего находите.

Общайтесь с другими QA
Общайтесь с другими QA инженерами, пусть они рассказывают вам свои истории поиска бага в три часа ночи, или как что-нибудь выкатили в продакшн без тестирования. Или истории о том, какой фреймворк они написали на своем проекте и какие баги этот фреймворк позволяет находить. При этом можно даже не взаимодействовать с людьми — смотрите youtube видео с выступлениями других людей, посещайте конференции/митапы/сходки/тематические вечера, подпишитесь на QA чатики и блоги — там очень много подобного материала, каждый день что-нибудь новенькое появляется.

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

Размышляйте
Размышляйте о том, почему люди не могут писать код без багов, о том, почему не получается найти все баги, и почему даже какие-то баги в продакшене — это нормально и не критично (но это не точно). Размышляйте о разных вопросах, связанных с багами — формулируйте собственную философию о таких вопросах, ищите ответы, подкрепляйте ответы реальными историями из жизни. Если ваш мозг постоянно возвращается к таким мыслям, со временем вы меняете свое мышление и начинаете находить все больше и больше багов, и делаете все более и более крутые тесты и проверки.

Делайте что-то новое
Отмечайте хорошо проверенные вами области проекта, и фокусируйтесь на поэтапном тестировании тех областей, которые вы еще не проверяли. Переодически переключайтесь между областями проекта и методами проведения тестов. Уже пол года занимаетесь функциональным тестированием? — найдите возможность на 2-3 недели позаниматься нагрузочным тестированием или тест дизайном (не проверками, а планированием), или например напишите какие-нибудь автотесты для самых критичных, еще не покрытых, областей, просто чтобы переключиться и дать вашему сознанию посмотреть на ваши обычные задачи под другим углом.

Автоматизируйте
Вот серьезно, есть люди (и среди них иногда есть хорошие QA), которые каждый день делают одни и те же тесты руками (совсем грустный кейс — проверка логина/регистрации, каждый день, руками). Если вы узнаете себя в этом описании или вы уже давно подумываете что-то автоматизировать из вашей ежедневной работы — сделайте это, отвлекитесь от всех задач и заскриптуйте (даже если это будет очень топорный и простой скрипт).

Ваш мозг не любит повторяющиеся действия, он на них отключается. А он вам нужен, чтобы найти баг! Используйте свой мозг, следите, чтобы он постоянно был в активном состоянии поиска несоответствий с вашими ожиданиями.

Повторяющиеся проверки перебрасывайте на автоматические скрипты, и давайте вашему мозгу и вашей интуиции работать с чем-то свежим и новым, тут же найдутся новые баги, вот увидите.

Общайтесь с разработчиками и пользователями
Придумайте способ получать возможность общения с вашими разработчиками и пользователями вашего продукта. Читайте их отзывы, спрашивайте о проблемах у команды поддержки пользователей, запишитесь волонтером по обработке пользовательских баг-репортов или пару часов в неделю работайте в команде поддержки пользователей (или просто попросите добавить вас в их чатик).

Иногда самые важные проблемы вы находите именно в момент общения с другими людьми. А те особенности реализации, новые фичи и тот технический долг, о котором вам расскажет программист — отличная почва для размышлений о том, где еще прячутся баги.

Рассказы пользователей о том, как они используют систему — тоже отличный повод пересмотреть свой тест план / чек листы и убедиться, что вы проверяете основные сценарии реальных пользователей. Ведь тут самое важное! А баги могут найтись везде 🙂

PS: QA Battle — для тех, кто любит искать баги и хочет потренироваться находить как можно больше багов. Мы сейчас работаем над серией обучающих простых уроков с примерами того, где могут прятаться реальные баги. Тренируясь на таких задачках, вы прокачиваете свой скилл и ваш мозг уже интуитивно работает более эффективно когда вы тестируете реальные продукты.

Перед тем как начать поиск, вспомним что такое баги. Баги и дефекты обнаруживаются тестировщиком при сравнении ожидаемого и реального результата работы программы. Багом может быть любая ошибка, которая вызывает неправильную или непредсказуемую работу приложения.

Что должен знать тестировщик?

В процессе тестирования специалисту приходится работать с большими объемами информации. QA-инженер старается удержать в голове различные варианты проверок. Структурно их можно заключить в следующие вопросы:

Ответом на этот вопрос должна быть четко сформулированная цель и назначение программы. В случае если тестировщик знаком с продуктом поверхностно, процент пропущенных дефектов сильно возрастет. Определите области, которые будут протестированы, а также основные пользовательские сценарии.

Это взаимосвязь глобальной цели приложения и его более мелких задач. После того как мы удостоверились, что основная функциональность работает, переходим к менее стандартным сценариям.

Провести тестирование программы с негативной точки зрения. Сюда входит ввод неверных данных и вызов исключительных ситуаций. Сценарии в этом случае направлены на проверку устойчивости системы.

В этом случае речь идет о пользователях, для которых предназначена разработка. Зачастую тестировщики проверяют продукт, ничего не зная о тех людях, которые будут использовать приложение.

Как взаимодействуют с приложением разные пользователи?

Попробуйте описать портреты разных пользователей и их взаимодействие с приложением в зависимости от определенных параметров. Такими параметрами могут быть сфера занятости, интересы, особенности поведения, черты характера и привычки.

Сценарии тестирования, построенные на основе этих данных, помогут оптимизировать продукт под потребности потенциальных пользователей.

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

Приведем пример из шести универсальных персонажей, которые могут использовать приложение.

Менеджер

Менеджер – занятой человек, он работает с приложением между встречами. Он нетерпелив и иногда не сосредоточен, так как все делает в спешке.

Для менеджера будут приоритетными горячие клавиши, максимально быстрое заполнение полей, отсутствие ошибок при быстром завершении, автосохранение, скорость загрузки.

Ищем баги в процессе заполнения форм, скорости их отправки, адресов, по которым идет отправка, проверяем точно ли описаны этапы заполнения и требования к итоговому варианту.

Хипстер

Хипстер любит исследовать новые функциональные возможности и области приложения, которые находятся за пределами главного экрана. Он заядлый исследователь.

Хипстера будут интересовать новые функции, недавно добавленные в приложение, непопулярные области приложения, нестандартный ввод данных, доступ к приложению из необычных браузеров, операционных систем, устройств.

Баги стоит искать в кроссплатформенности, адаптивности, проверке введенных данных, взаимодействии старой и новой функциональности приложения.

Осторожный

Осторожный пользователь предпочитает рутинные операции, которые должны хорошо работать. Его процессы будут повторяться в каждой сессии.

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

Поиск багов стоит начать с наиболее используемых функций, затем следует проверить ограничения по количеству символов в полях форм, убедиться в работоспособности всех элементов интерфейса, а также в том, что при долгой загрузке приложение остается работоспособным.

Проказник

Проказник любит ломать вещи. Он знает о проблемах безопасности и любит исследовать, чтобы убедиться в том, что приложение может защитить его данные.

Его заинтересуют SQL и JavaScript-инъекции, манипулирование URL-адресами, получение доступа к личной информации, нарушение ограничений на поля ввода и генерация сообщений об ошибках.

Ищем баги в доступе к секретной информации, проверяем работоспособность всех уведомлений об ошибках и ограничений.

Путешественник

Путешественник сейчас на другом конце света. Он использует приложение редко и в основном в нерабочее время.

Путешественник будет получать доступ к приложению из разных мест и часовых поясов. Он попытается использовать различные браузеры и устройства, а также медленный и ненадежный интернет.

Проверяем наличие дефектов в кроссплатформенности и адаптивности, возможности использования различных раскладок клавиатуры, ограничений на ввод символов иностранных языков, а также стабильности работы приложения при плохом подключении к сети.

Взрослый

Взрослый относится к старшему поколению и имеет небольшие знания в области вычислительной техники. Имеет определенные трудности с пониманием работы приложения.

Взрослый пользователь будет медленно прокручивать экран и подолгу оставаться на одной странице, часто использовать кнопки «Назад» и «Отменить».

Здесь необходимо искать баги в настройках шрифта, яркости и других элементах интерфейса. Проверяем, срабатывают ли окна онлайн-помощи, работает ли приложение с устаревшими технологиями, включая старые версии браузеров и операционных систем.

В заключение

Как мы видим, даже тестировщик без опыта работы сможет справиться с поиском некоторых багов. Попробуйте протестировать знакомый сайт или приложение, а если понравится – обязательно подавайте заявку на курсы по тестированию.

Изучайте теорию, практикуйтесь в тест-дизайне. Чтобы стать QA-инженером, важно желание разбираться в том, как этот продукт работает сейчас и как он должен работать в принципе.

Если же вы уверены в своих силах, перед собеседованием на должность тестировщика обязательно подготовьтесь к задачкам на логику.

Сид Мейер как-то сказал, что «Игра — это последовательность интересных выборов». А значит, перед выпуском игры в массы тестировщик должен убедиться, что все выборы в игре интересные и работают правильно. Да и вообще работают!

Игровая механика представляет собой набор правил, по которым работает игра, и математическую модель, которая стоит за этими правилами. Вместе с дизайном уровней и системой обратной связи с игроком эти три столпа составляют тот самый геймплей. Вот по нему и оценивают геймеры свои впечатления об игре.

На каждом из этих этапов встречаются баги и недоработки, потому что игра — это комплексный труд нескольких человек, а когда речь идёт про AAA-проекты — даже не одного десятка людей. И допустить ошибку в одном из компонентов игры довольно легко.

Сегодня мы затронем тему не только локализационного, но и функционального тестирования. А помогать нам будет эксперт и руководитель отдела тестирования компании Inlingo Андрей Васильев.

Чтобы успешно заводить баги, нужно их систематизировать. Разделить и властвовать.

Итак, баги в играх можно условно классифицировать по следующим категориям:

Баги, связанные с самой игрой:

Потренируемся: какой это баг по классификациям? Если вы ответили: «Функциональный, низкоприоритетный, графический, затрагивающий команду разработки», то ура — вы тестировщик (нет)

Багам присваивается степень критичности: какие-то устраняются в первую очередь, а какие-то можно даже оставить в финальном релизе:

Иногда разработчики специально оставляют низкоприоритетные баги в игре — для вирусного эффекта. В конце концов, это ведь уморительно, а игры должны развлекать, так почему бы и да?

Баги различают по затрагиваемой стороне. То есть кому они будут больше всего мешать использовать продукт:

От чего зависит число багов в игре?

Действительно, от чего? Почему в одних играх их просто огромное количество на альфа-тестах (привет, No Man’s Sky), а в других — практически нет? Всё довольно очевидно.

Привязка выявляемого количества багов к жанрам

Хороший пример того, как игроки испытывают игру на прочность. Skyrim в этом смысле рекордсмен.

Сравнительно проще тестировать игры, где действия игрока ограничены, их реально проверить все за обозримое время теста. В основном, это казуальные игрушки:

COD WWII за принципиально новый эко-транспорт

Такова классификация багов с нашей точки зрения. В ходе написания материала мы нашли интересное видео с выступлением Дмитрия Химиона про «Тестирование игровой механики в компьютерных играх». Он утверждает, что есть ещё одна классификация ошибок в игре.

Ошибки дизайна уровней

Появляются точки на локации вне досягаемости игрока. Застревания в текстурах, кстати, относят сюда же. И надо справедливости ради заметить, что застреваем мы вовсе не в текстуре, а в геометрической модели, потому как текстура — это картинка. Значит, левел дизайнер где-то ошибся и наделал лишних порогов и ступенек, а нога героя застряла и, пытаясь подчиниться законам физики, начинает вытворять невообразимое

Ошибки обратной связи

Сюда относят все ошибки, связанные с элементами контроля и управления. Они могут возникать при неверной калибровке и невозможности сменить в настройках чувствительность мыши или аналоговых стиков.

Ошибки игрового баланса

Игровой баланс — это качественная характеристика, определяющая уравновешенность игровых сущностей и показателей, а еще поддерживающая интерес к игре. Само создание игрового баланса сопряжено с постоянным тестированием, поэтому ошибкой тут может считаться только незавершенное тестирование.

А с какими багами сталкивались вы? Присылайте нам в комментарии — похохочем, что ли.

Источник