Как найти баг в игре

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Что необходимо протестировать?

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

• Как может использоваться приложение?

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

• Как сломать программу?

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

• Кто будет использовать приложение?

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

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

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

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

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

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

Менеджер

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

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

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

Хипстер

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

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

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

Осторожный

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

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

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

Проказник

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

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

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

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

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

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

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

Взрослый

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

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

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

В заключение

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

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

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