Баги в браузерных играх. Всё сломалось: легендарные баги в видеоиграх. Туры по туристическим районам, Tours Through the Tourist District

Описав методику систематического поиска багов по Джеймсу Уиттакеру (James A. Whittaker)

Методика туров

Приложение - незнакомый город.
Тестировщик - турист.

У туриста мало времени, поэтому он выполняет конкретную задачу, ни на что другое не отвлекаясь. Он бегает по казино, или осматривает достопримечательности, или посещает деловой семинар. Что угодно, но что-то одно.

Как пользоваться методикой

Выбрать тур из списка ниже.
Изучить его цели.
Поставить таймер на 2 часа (час, полчаса).
Провести исследование системы строго по целям тура. Ни на что не отвлекаясь, только “миссия” тура.
При необходимости повторить.

В каждом туре есть описание автора (низкий поклон Джеймсу за разрешение перевода и публикации) в вольном переводе + собственные примеры. Для примеров взят сайт Дадаты - https://dadata.ru .

Отправляемся в путь!

Туры по деловому центру, Tours of the Business District

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

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

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

Туры по историческим районам, Tours Through the Historical District

Исторические районы - части города, содержащие старые здания и достопримечательности. В Бостоне они разбросаны по всему городу и соединены только пешеходными тропами. В Кёльне есть «старый город» - одна часть города, которая не тронута современной экспансией.

В ПО исторические районы могут быть также слабо соединены, как в Бостоне или сосредоточены в одном месте, как в Кёльне. Исторические районы в ПО представляют собой:

• унаследованный код (legacy code);
• функции, созданные в предыдущих версиях;
• исправления багов.

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

Туры по историческим районам проверяют старую функциональность и исправления ошибок.

Туры по развлекательным районам, Tours Through the Entertainment District

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

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

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

Туры по туристическим районам, Tours Through the Tourist District

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

Туры по туристическим районам имеют несколько разновидностей. Это и короткие забеги для покупки сувениров, аналог кратких тест-кейсов для тестирования специфичных функций. Это и длинные поездки для посещения списка мест, которые хочется увидеть. Эти туры не о том, как заставить приложение работать, они о том, как посетить функциональность быстро… только чтобы сказать “мы тут были”!

Туры по отельным районам, Tours Through the Hotel District

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

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

Туры по захудалым районам, Tours Through the Seedy District

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

Как найти баги в играх?

Ответ мастера:

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

Чтобы найти баги в игре, начните с базового теста. Он отобразит работоспособность игрового движка. Его, в принципе, нужно производить на самых ранних стадиях разработки игры. Суть проверки – найти ошибки, которые приводят к «выбрасыванию из игры». Такого типа ошибки следует находить в первую очередь, потому что именно они отбивают всю охоту играть дальше.

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

Теперь протестируйте гейплей для обнаружения багов в игре. Если игра первый тест прошла и работоспособность движка вас устраивает, то можно внимательно изучить разработку принципов и баланса игры. Например, если ваша игра похожая на Dead Space, то обязательно оттестируйте все виды оружия и «фишки» разработчиков. Когда какие-то из них дублируют друг друга или вообще лишние, то их нужно пересмотреть или доработать. Особое внимание нужно уделить проходимости игры, чтобы ее можно было пройти даже на самых последних уровнях.

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

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

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

Шаги

Выявление глюков

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

• Прочитайте краткий обзор игры. Если он достаточно подробный, то это может вам помочь.
• Спросите друга, который играет в эту же игру. Возможно, они или она знает ответ на ваш вопрос.
• Зайдите в интернет и проверьте форумы игры. Посмотрите, если кто-то еще сообщил об этом глюке. Или, сделайте поиск “Х глюк” в поисковой системе, если вы думаете, что это известный баг.

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

   • На YouTube, очень часто, имеются видео о глюках в популярных играх.
   • Проверяйте дату сообщений о глюках. В то время, когда глюки могут просуществовать некоторое время, в реальных играх, после нескольких месяцев, они будут исправлены.
   • А также, прочитайте о последствиях использования глюка – в некоторых случаях, вы можете испортить вашу игру или потерять вещи.
   • Существуют некоторые веб-сайты, посвященные поиску игровых глюков. Некоторые из них включают забавные глюки, с которыми можно повеселиться, но не больше.

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

   Типичные зоны и действия глюков

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

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

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

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

   2. Проверьте большие объекты. Камни и другие крупные декорации, очень часто, являются лучшим местом для поиска глюков. Иногда, разработчики игры ленятся и не устанавливают нужные барьеры.

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

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

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

      • Большинство глюков появляются на территориях, которые не были предназначены для игры.

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

      • Если смерть в игре вам не страшна, то возможно, вы найдете несколько забавных глюков!

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

   Повторный поиск глюка

   И так, вы решили, что найденный глюк был веселым и, теперь, желаете снова им воспользоваться…

   • Wii никогда не получает обновления, так что, если вы ищите неменяющийся глюк, то играйте на Wii. Тем не менее, большинство выступов в играх Wii - это пейзажи, и вы не сможете на них взобраться.
   • Научитесь прыгать точнее. Приземление на нужную цель – это ценное умение. Повторяющиеся прыжки (в стиле зайца), иногда, могут привести вас к одному из глюков.
   • Если препятствие недоступно, то попробуйте подняться по выступу, вместо попыток взобраться по центру.
   • Попробуйте подвинуть другого персонажа или животного на какой-нибудь объект и, потом, пройдите через этого человека или зверя. Используйте персонажа или животного для того, чтобы взобраться на что-нибудь, и для других целей.
   • Большинство объектов – это пейзажи. Если вы попробуете спрыгнуть с крыши здания на другую сторону, то скорее всего, вы начнете через него падать.
   • Используйте специальные прыжки, когда пытаетесь прыгнуть дальше, чем обычно. Если вы пытаетесь осуществить прыжок с разбегом на какое-нибудь место, то, после каждого прыжка, позвольте ему перезарядиться и проверяйте – помогает ли вам это.

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Успехов вам в поисках:)

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

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

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

Опыт оказался весьма позитивным, как для проекта, так и для тестировщиков. Для тестирования использовалось 2 сценария, оно проходило в выходные, и в понедельник я уже имел 84 бага (3 категории A, 15 - B, 62 - С и 4 - D), оформленных согласно требованиям. После исправления всех этих багов продукт был зарелизен.

Кстати, когда оформлял задание для фрилансеров, не смог найти в интернете подходящее описание категорий ошибок, поэтому составил сам. Возможно, кому-то оно будет полезно:

• Категория А (I). Наличие ошибок данной категории блокирует для пользователя доступ к основной функциональности продукта. Это могут быть ошибки связанные с регистрацией, авторизацией и / или ошибки, возникновение которых не дает пользователю продвинуться дальше по курсу независимо от его текущего состояния.
• Категория B (II). Ограничивают доступ к некоторой функциональности, не влияющей на завершение прохождения продукта или не дают пользователю продвинуться по курсу, в зависимости от предыдущих предпринятых им шагов, заставляя его начать какую-то часть курса проходить заново.
• Категория C (III). Ошибки данной категории напрямую не влияют на процесс использования продукта, но ухудшают целостность его восприятия или впечатления от процесса. Сюда входят ошибки верстки, неверное отображение и расположение графических элементов, замедленная реакция контроллов и т.п.
• Категория D (IV). Ошибки этой категории по сути не являются ошибками. Категория введена для того, чтобы ошибке можно было присвоить ее, в случае, если она связана с функциональностью, визуализацией и прочими свойствами продукта, представление о реализации которых у тестера отличается от того, что предполагалось реализовать.

Спасибо за внимание!