Какие баги есть в игре. Как найти баг в коде

Вы уже освоили основные техники тест-дизайна? Отлично! Значит, Вы – квалифицированный тестировщик.

Как научиться находить баги, которые не находят другие тестировщики, несмотря на то, что они знают те же самые техники?

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

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

Нужны дополнительные профессиональные навыки.

Этот тренинг нацелен на формирование у тестировщика специальных навыков:

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

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

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

Почему в продуктив попадают баги, для которых тестировщик “не придумал” подходящего теста? Техники не виноваты. Просто неверно выбрана модель или техника применялась не там и не так.

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

Но там не написано главного – как понять, что вы нашли баг? Как его узнать? Как понять, правильно или неправильно работает программа? Говоря “профессиональным” языком – тема оракулов не раскрыта.

Наконец, как понять, правильно или неправильно вы применяете ту или иную технику? Тема оценки полноты покрытия не раскрыта тоже.

На этом тренинге мы будем учиться:

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

Кроме того, мы освоим профессиональную работу с уже обнаруженными багами:

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

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

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

Игры, упражнения, соревнования, и конечно – реальное тестирование, всё это будет в программе тренинга.

После него вы вернётесь на своё рабочее место “намагниченным” и “заряженным” на поиск багов. И они это почувствуют, не сомневайтесь:)

Программа тренинга

День первый

1. Подготовка инфраструктуры, знакомство – 30 минут

2. Тестирование учебной программы (упражнение и разбор), обсуждение на тему «Что важнее – техники или навыки?» – 60+15 минут

3. Тестирование новой программы, искусство задавания вопросов (упражнение и разбор) – 60 минут

4. Что делать, когда ты нашел баг? Глобализация и локализация (демонстрация и обсуждение) – 45 минут

5. Искусство описания багов (упражнение и разбор) – 60 минут

6. Регрессионное тестирование и перепроверка багов – как и зачем много раз выполнять одни и те же тесты? – 45 минут

7. Моделирование: умение смотреть на программу под разными углами (упражнение и разбор) – 45 минут

8. Тестирование юзабилити: поселите у себя в голове персонажей (упражнение) – 30 минут

День второй

1. Стратегия тестирования (обсуждение) – 45 минут

2. Сравнение двух программ: какая лучше? (упражнение и обсуждение) – 60 минут

3. HICCUPPSF: эвристики построения оракулов (демонстрация, упражнение и разбор) – 15+60 минут

4. Построение тестов для сложной функциональности (упражнение и разбор) – 60 минут

5. Тест-кейсы, чеклисты, тестирование методом свободного поиска – в каком соотношении смешивать? (обсуждение) – 30 минут

6. Тестирование методом свободного поиска (упражнение и разбор) – 60 минут

7. Регрессионное тестирование и перепроверка багов – как и зачем много раз выполнять одни и те же тесты? (обсуждение) – 30 минут

8. Автоматизация тестирования (демонстрация и обсуждение) – 45 минут

9. Завершение курса, подведение итогов – 30 минут

В этом тренинге по согласованию с Майклом Болтоном используется методика и упражнения из всемирно известного тренинга Rapid Software Testing. Для подготовки к тренингу тренер Алексей Баранцев трижды провел совместные с Майклом тренинги в качестве ассистента и второго тренера.

Описав методику систематического поиска багов по Джеймсу Уиттакеру (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-версий или еще более поздних. В таком тестировании нет особых приоритетов. Главная цель – это найти баги и различные погрешности. Если вы тестер, то вы должны перепробовать в игре все возможные и невозможные тактики к прохождению игры, использовать максимальное количество ходов, в общем, проявить фантазию. Используйте все возможности игры, непрерывно меняя стиль. Ведь нужно выяснить, к каким действиям игрока программа не приспособлена.

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

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

Инструкция

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

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

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

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

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

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

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

Инструкция

Для просмотра ошибок системы откройте: «Пуск» - «Панель управления» - «Администрирование» - «Просмотр событий». У вас будет возможность просмотреть разделы: «Приложение», «Безопасность» и «Система», в которых будут записаны все сообщения об ошибках.

Если при попытке открыть какой-либо из журналов появляется сообщение о невозможности просмотра, на компьютере, скорее всего, отключена служба «Журнал событий». Чтобы запустить ее, откройте: «Панель управления» - «Администрирование» - «Службы». Дважды кликните мышкой службу «Журнал событий», в открывшемся окне выберите тип запуска – «Автоматически», нажмите кнопку «Применить». После этого нажмите ставшую активной кнопку «Старт».

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

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

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

Не забывайте время от времени дефрагментировать диск, на котором установлена операционная система. Высокая степень дефрагментации данных существенно замедляет работу компьютера. Для дефрагментации откройте: «Пуск» - «Все программы» - «Стандартные» - «Служебные» - «Дефрагментация диска».

Как найти баг в коде

Как часто вы тратите часы чтобы понять почему же эта эта вредная навигация сползла, а это изображение отображаясь искажает весь текст невероятным способом? Этот способ позволяет найти причину практически не думая за 5 минут. Наверное почти все пользовались этим методом поиска багов в вёрстке.

Зачем

Очень много времени в верстке уходит на решение багов, и поиски их причин. Если вы чувствуете, что можете потратить более 20 минут на поиски причины - лучше смело использовать этот метод, он редко отнимает более 5-10 минут. Впрочем, менее 5 минут, он тоже редко отнимает. И это его единственный недостаток.

Когда

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

Идея

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

Принцип очень простой, чтобы найти, например, точку на отрезке:

1. Делим отрезок пополам, определяем в какой половине содержится наша точка
2. Повторяем процедуру для полученной половины отрезка с точкой

И так, пока не получим нужную точность.

А так это выглядит в задаче про поимку льва в пустыне:

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

Алгоритм в приложении к вёрстке мало отличается от классики. Львом будет кусочек кода делающий глюк. Пустыней - весь код.

>Суперпупермегаалгоритм

1. Удаляем половину или просто большой кусок HTML (CSS)
   • Если глюк остался виден, продолжаем процедуру для оставшегося кода
   • Если глюк исчез, возвращаем удалённый код и повторяем процедуру для него (удалив другую половину)

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

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

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

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

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

В конце

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