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

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

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

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

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

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

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

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

3. Баг локализованной игры. В основном это не переведенный на нужный язык текст или орфографические и/или синтаксические ошибки при переводе слов и т. д.; в общем, проблемы с переводом.

4. Баг производительности. Игровые проблемы с FPS, не связанные с пользователем, — игра работает медленно и лагает на производительных устройствах.

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

6. Технический баг. Нестабильный интернет, отчего игра плохо работает. Или, например, не хочет запускаться в 3G—сети.

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

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

1. Баги максимального приоритета. Это те, которые требуют немедленного устранения; часто связаны с тем, что пользователи просто не могут играть, и, соответственно, игра не может приносить деньги.

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

3. Баги низкого приоритета. Это те, которые мало заметны или не заметны всем игрокам. Часто их происхождение связано с какими-то уникальными условиями в игре, и главное — они вообще не мешают игровому процессу. В некоторых случаях такие баги не исправляют специально для тех игроков, которые любят находить всякие такие интересные моменты. И от этого только увеличивается популярность игры.

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

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

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

3. Баги для разработчиков. Этот не баги, которые не мешают пользователям и в принципе не мешают зарабатывать деньги. Они связаны с тем, что геймплей в игре реализован не так, как изначально задумывался. А как задумывалось — знают только разработчики игры.

Что такое баги в игре — разобрались, и как их классифицируют — тоже. Остается вопрос: а как вообще появляются эти «недостатки» и от чего зависит их количество в проектах?

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

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

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

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

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

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

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

5. Раннее тестирование. Один баг часто порождает целую цепочку багов, поэтому необходимо качественное тестирование на ранних этапах разработки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

7. Думайте. Как ни странно, но мысли по типу: «Почему игры пишутся с багами?», «Почему баги в играх — это то, что считается нормой?», «Что вообще такое баги в играх?» и т. д. помогают развивать собственную философию в этом вопросе. А со временем вы сами будете находить подтверждение своим мыслям и догадкам. И у вас появятся собственный алгоритм и методики поиска.

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

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

Заключение

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

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

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

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

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

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

Visual Artefacts — любые визуальные баги, не подпадающие под другие виды.

Missing Textures — пропущенные/исчезнувшие текстуры. Обычно на их месте стараются ставить «заглушку» в виде яркой текстуры по умолчанию в виде шахматной доски. Это не обязательно, но благодаря такому подходу, пропущенные текстуры видны не вооруженным взглядом.

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

Screen Tearing или «разрыв экрана» — это визуальный артефакт, при котором отображается информация из нескольких кадров на одном изображении.

Culling и Clipping — баги, относящиеся к работе рендера и графического пайплайна. Часто —  пересечение двух объектов, при котором один закрывает геометрию другого, скрывая ее от взгляда. Если немного углубиться, то Culling — это отсечение того, что заведомо невидимо. В таком случае игра даже не будет пытаться отрисовать данный сегмент. Culling бывает разным и вот его примеры: rustrum culling — отсечение по пирамиде видимости, backface culling — отсечение «задних» граней, occlusion culling — отсечение граней факту их  перекрытия другой геометрией, depth culling — перекрытие одной геометрии другой, которая уже была нарисована, но на основе depth buffer. А вот когда рисуется достаточно большой полигон и от него отрезается всё то, что заведомо находится за пределами экрана — это уже Clipping.
Также отдельно стоит выделить похожий, но в сути другой баг — проблемы коллизий. В видеоиграх отсечение может быть связано с набором алгоритмов, которые реагируют на взаимодействие двух смежных или перекрывающихся геометрий (collision detection). А для выявления таких багов существуют специальные режимы просмотра (view modes), но об этом я расскажу в следующей статье.

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

Баги левел дизайна — невидимые стены (invisible walls), пропасти в карте (map holes), застревания (stuck spots) и т.д. Также к багам левел дизайна я бы отнёс баги связанные с нав мешем (Navigation Mesh). Ниже приведу несколько примеров багов левел дизайна:

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

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

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

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

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

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

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

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

Под баги локализации и compliance, из нетривиального, можно отнести локализацию рекламы, размещение разных материалов на одних и тех же местах в разных регионах и странах (к примеру в этой стране запрещено к показу одно, а в другой — не запрещено или же возрастной ценз, под которые подпадает игра, может не разрешить что-либо показывать в том или ином регионе). Манипуляции с датой на вашем устройстве и сбой работы клиента с сервером я бы тоже отнёс сюда. Ну и «классические» баги локализации и интернационализации никто не отменял. Больше про них и о подходах к их правильному и полному тестированию можете прочитать в моей статье.

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

Конечно же нет. Это далеко не все разновидности игровых багов, но, пожалуй, самые часто встречаемые. Здесь я не затрагивал баги несоответствия, такие как «элемент записан в blueprints по одному, на back-end — по другому, объект или его атрибуты (ID, описание и т.д.) забыли куда-то добавить и прочее. А не затрагивал их, т.к. это больше не про специфики игр, а в целом неисправности, которые могут быть во многих программах.

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

Как научиться искать баги — Серьезность и приоритет — Алгоритм действий — Лучшие практики — Шпаргалка

Типы багов:

• Функциональные
• Синтаксические
• Логические
• Производительности
• Ошибки вычислений
• Безопасности
• Уровня модуля
• Интеграционные баги
• Юзабилити-баги
• Потока управления
• Совместимости

Функциональные

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

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

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

Поиском багов этого типа занимается функциональное тестирование — отдельная важная сфера в QA (мини-гайд по ссылке).

Синтаксические баги

Ошибка в коде программы. Вероятно, самая частая ошибка, статистически. Случается обычно по невнимательности. Заключается, например, в неправильном/пропущенном символе, неправильно прописанной команде, или пропущенной скобке. 

Логические ошибки

Коварная ошибка, труднее выявляемая. Приложение выдает неправильный вывод, или вообще падает. 

Логические дефекты это например бесконечные циклы или некорректные переходы, допущенные разработчиком по неопытности или незнанию синтаксиса, вызывающие сложно определяемые ошибки в user flow (“маршруте пользователя по приложению” в процессе пользования им).

Бесконечные циклы — больное место тестировщика, так же как утечки памяти, проблемы с типами данных во многих языках, с компилятором в С++ или сборщиком мусора в Java. Несоблюдение хороших практик в программировании и недостаток опыта у разработчиков добавляют задач QA-отделу.

Еще примеры: переменной присвоено некорректное значение; деление чисел вместо умножения, и т.п.

Подробнее о логических ошибках.

Проблемы производительности

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

Ошибки вычислений

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

• Когда в приложении применен некорректный, неподходящий алгоритм
• Несоответствие типа данных

Уязвимости в безопасности

Дефекты в системе безопасности, видимо, наиболее опасные из тех, с которыми сталкивается junior QA. Они “компроментируют” весь проект, всю компанию, и разумеется, QA-команду, если она их пропустила. 

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

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

Баги уровня модуля

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

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

Интеграционные баги

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

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

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

Юзабилити-баги

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

Баги потока управления (Control Flow)

Ошибки Control Flow (потока управления, путей выполнения программы) мешают ей корректно переходить к выполнению следующих задач, то есть корректно “передавать управление”, что стопорит весь workflow компании. Обычно это “мертвый код” (отсутствует вход), или “бесконечный цикл” (отсутствует выход). 

Пример: в опроснике пользователь нажимает “Сохранить”, предполагается переход к концу опросника/теста, а перехода к следующей странице не происходит. 

Проблемы совместимости (Compatibility issues)

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

Итак, уже примерно знаем, ЧТО искать, постараемся понять, КАК искать.

Как научиться искать баги

“Быстрая проверка” на реальных устройствах и в браузерах

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

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

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

Даже если таким образом будет найдено сравнительно мало багов, логично предположить, что все-таки есть проблемы в основной части функциональности. Отсутствие багов при “экспресс-анализе” (“quick attack”) обычно показывает, что основная часть функциональности более-менее в порядке.

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

Внимание тестовому окружению

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

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

Например, тестировщик нашел и отрепортил баг, а когда разработчик проверил его, в коде проблем не нашел, потому что проблема была с окружением. От этого возникает задержка.

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

Тщательное исследование

Перед началом тестирования нужно внимательно изучить приложение или тестируемый модуль.

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

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

Принцип Парето

Согласно этому принципу, 20% усилий дают 80% результата. 

А 80% усилий дают лишь 20% результата. 

Применительно к QA-индустрии, принцип Парето гласит, что 80% багов сосредоточены в 20% модулей. (Необязательно такое точное соотношение, но в целом). По принципу Парето, большинство багов затаились в одном-двух модулях (или даже еще меньшей части кода).

Если всерьез взяться за эти модули и вычистить из них баги, можно считать работу на 80% сделанной.

Подробно о принципе Парето в тестировании.

Четкие цели

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

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

Серьезность и приоритет

По серьезности (Severity)

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

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

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

• Средней серьезности. “Минор”. Когда не очень важная функция не ведет себя соответственно требованиям. Например, ссылка в “Условиях использования” продукта ведет в никуда.

(Перечисленные выше баги коротко обозначаются S1, S2, S3, S4 по серьезности.)

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

По приоритету

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

Приоритеты выставляются менеджером проекта:

Высокий приоритет. Это ошибки, которые должны быть устранены до релиза, согласно критериям завершения тестирования (exit-criteria). Например, это ошибка, несмотря на корректность всех введенных данных мешающая переходу со страницы входа на главную.

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

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

(Перечисленные выше баги обозначаются P1, P2, P3 от высокого к низкому.)

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

Подробнее о серьезности и приоритете, а также о глобальном приоритете и частоте багов.

Стандартный порядок действий при обнаружении бага

1. Проверить дополнительные (связанные) вещи

Обычно баги “по одному не ходят”, то есть где-то поблизости есть аналогичные, или связанные с уже найденными. 

1. Зафиксировать текущее состояние приложения

Состояние приложения и состояние окружения. Это поможет примерно определить причину бага — внутренняя или внешняя, и воспроизвести баг.

1. Проверить, может баг уже есть в репортах

Чтобы не делать уже сделанную кем-то работу.

1. Репорт

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

Статусы багов (в жизненном цикле)

• Открыт (добавлен в репорт)
• В работе (принят к исправлению)
• Исправлен (и передан на перепроверку)
• Закрыт (уже не воспроизводится)

также дополнительно:

• Отклонен (ошибка в репорте)
• Отсрочен (как неприоритетный)
• Переоткрыт (после двух предыдущих статусов)

Подробнее о системах контроля багов — здесь

Лучшие практики

• Сначала хорошо исследовать и понять приложение (модуль)
• Создать специальные тест-кейсы, а именно функциональные тест-кейсы, посвященные критически важным функциям
• Подготовить достаточно тестовых данных
• Запустить тесты снова, в другом тестовом окружении
• Сравнивать полученные результаты с ожидаемыми
• Проанализировать тестовый сет, используя старые тестовые данные
• Выполнить стандартные тест-кейсы, которые ранее показывали себя надежными. Например, если тестировалось поле ввода для стандартного текста, ввести HTML-теги и проверить, что получится
• После завершения большей части тестов, если есть усталость, отдохнуть, занявшись обезьяньим тестированием (monkey testing)

Тестирование на реальных девайсах и в реальных окружениях

Тестирование в реальных окружениях является хорошей практикой в QA, а в тестировании мобильных приложений — обязательной практикой. Реальное окружение быстрее “апгрейдит” тестировщика. Но оно требует закупки/аренды довольно-таки внушительного парка устройств. Вообще, тестирование всех возможных комбинаций браузер/ОС/девайс — отдельная головная боль. Здесь помогают облачные платформы.

***

Шпаргалка QA Trainee/Junior

Что делает тестировщик, когда находит баг

• Проверяет связанные или аналогичные вещи
• Фиксирует текущее состояние приложения и тестового окружения
• Проверяет, нет ли этого бага в репорте
• Пишет репорт

***

Пять технических и пять нетехнических навыков хорошего QA

 Регрессионное тестирование: подборка инструментов

Эмуляторы и симуляторы: в чем разница

Войти на сайт

или

Забыли пароль?
Еще не зарегистрированы?