QA

Классы эквивалентности и граничные условия. Это наиболее популярные техники, которые могут применяться одновременно.
Перед тем, как начну подробнее рассказывать про техники, хочу подчеркнуть один очень важный момент. Полностью проверить каждый чих в игре - невозможно. Точнее возможно, но это может занять не один год, а нам ведь нужно уже "вчера" выпустить игру в стор. Правильно? Вот тут нам и приходит на помощь классы эквивалентности и граничные. Они помогают тестеру и инди-разработчику минимизировать количество тестов, чтобы уложиться в адекватные сроки и не пропустить серьезных багов.
Я думаю, что с граничными условиями всё понятно, их я затрагивал в предудщих статьях. А вот, как пользоваться техникой классов эквивалентности, сейчас расскажу:
* определи объект, который хочешь протестировать;
* подумай или посмотри (если тесты у тебя уже есть), какие тесты применимы к этому объекту;
* посмотри, какие из этой массы тестов эквивалентны, т.е. проверяют одно и тоже и скомпонуй их;

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

Пример. Допустим, мы тестим шутер от первого лица. Нам нужно протестировать взаимодействие пули с врагами. Обычно в шутерах тело врага разделено на зоны (голова, туловище, ноги) при попадании в которые наносится разный урон. Это тоже нужно учесть при тесте и желательно уточнить у разработки где находятся эти зоны.
Итак, врагов у нас целая орда. Какие наши действия? Нет, шмалять во всех мы не будем, хоть это и весело.
1) Для начала поделим врагов на классы, как это сделал гейм-дизайнер. Например: Бандит, Мародер, Джаггернаут, Снайпер.
2) Затем найдем одного представителя из каждого класса, и вот теперь уже шмальнем по нему.
2.1) Выстрелим сперва в самый низ ботинка (нижняя граница зоны ног);
2.2) Затем, выстрелим ему прям в ладошку. Можно еще в пряжку ремня (Стык зон туловища и ног);
2.3) Еще дышит? Выстрелим наглецу в шею (Стык зон туловища и головы);
2.4) Ну и контрольный, в самую макушку (Верхняя граница головы);
3) Записать результаты тестирования.

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

Следующая техника - это предугадывание ошибок или тестирование на основе опыта.

Тут всё строится на выявлении особенностей игры и составлении списка потенциальных багов. Например:
1) Многие тестировщики знают, что при подборе аптечек есть вероятность столкнутся с ошибками в игровой логике. Т.е. мы подобрали аптечку, у нас фактически увеличились очки жизни, но на панели здоровья количество очков осталось прежним, или на панели изменилось, а в информации о персонаже нет (если мы тестируем РПГ, к примеру).
2) Анализ спецификации (требований). Т.е. тестировщик, читая требования и основываясь на своем опыте, может предположить, в каких местах разработка вероятнее всего допустит ошибку.
3) Чтение исходного кода. Если комментарии написаны невнятно, или код написан кривовато, то с большой вероятностью, в этом месте вылезут баги. (Этот пункт инди-разработчики делают на автомате. Написал строчку / цикл - проверил).
4) Наблюдение "симптомов" ошибки. Т.е. если моб респаунится в тексутре, то это уже сам по себе баг, т.к. игрок не сможет его убить, но если он респнется в текстуре много раз, то это может привести к снижению производительности игры (к примеру если у нас ММО)

Итак! Предугадывать ошибки можно двумя способами:

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

* Предугадывание ошибок методом "туров". Когда проверки ошибок выстраиваются определенным образом в виде "тура". Под туром понимается упорядоченный список объектов или их состояний, который нужно проверить, исходя из имеющейся информации. Для аналогии можно привести незнакомый город, в который вы прибыли туристом и хотите посетить только достопримечательности, а не блуждать по всем закоулкам.
Спроектировать набор хороших туров не просто. Нужно уметь анализировать игру и требования к ней. Однако в совокупности с опытом тестера, этот метод становится очень эффективным оружием в борьбе с багами. 

Эй, если ты поехал в Москву и посетил только Кремль, это не значит, что в городе нет больше ничего интересного! Туры бывают разные, вот их классификация. Подробнее о ней можно прочитать в книге Джеймса Витаккера "Exploratory Software Testing" (если ты тоже читаешь книжки про тестирование, можешь написать их название в комментариях):

1) Туры по деловому центу. Под деловым центром понимаются те функции, ради которых пользователи приобретают или захотят приобрести твою игру. Туры по деловому центру, в свою очередь разделяются на:
1.1) Туры по путеводителю (Он же руководство пользователя). При тестировании методом этого тура нужно четко следовать руководству пользователя, не отклоняясь от него.

1.2) Денежный тур. В данном методе тестируются основные фичи и внутриигровые объекты, которые активно рекламируются и за которые игрок готов выложить деньги.
1.3) Внеурочный тур. Если игрок свернул/закрыл игру, это еще не означает, что оно прекратило свою работу. Игра может сохранять данные, получать обновление. Суть тура в том, чтобы проверить эти операции.
2) Туры по историческим районам. Исторические районы игры - это старый функционал, унаследованный код или исправление старых багов. Разделяются на:
2.1) Тур по нерекомендуемым местам. Это как зайти в гоп-стоп райончик. Нерекомендуемые места в игре - это места, где часто скапливаются баги. После того, как баги были исправлены, необходимо еще раз пройтись по этому месту.
  2.2) Музейный тур. Это проверка "музейного" кода. Т.е. кода, который давно не менялся. При переносе игры на новую среду, этот участок кода может не работать и ронять нашу игру.  2.3) Тур предыдущей версии. Применяется, когда вырезается какой-то функционал, меняется интерфейс или устраняется баг, который игроки использовали, как фичу.
3) Туры по развлекательным районам. Обычно туристы приходят в развлекательный район, чтобы отдохнуть, а не ради достопримечательностей. В большинстве игр имеются функции, не представляющие значения для бизнеса, но являющиеся приятным дополнением к основному функционалу. Например, функции, позволяющие настроить игру «под себя» или позволяющие «навести красоту»: персонализация, изменение стиля персонажа, иконок и пр. Таким образом, развлекательные туры проверяют второстепенные функции, и то, насколько они правильно и гармонично сочетаются с основными. Разделяются на:
3.1) Тур по тёмным переулкам. Это тур по фичас, которые не востребованы/мало востребованы игроками, т.к. приносят меньшую пользу или вызывают меньший интерес.  3.2) Тур любителя ночной жизни. В данном метода проверяются возможности работы игры без перезагрузки. А ты о чем подумал?
4) Туры по туристическим районам. Быстрый осмотр игры или основных фич. Разделяются на:
4.1) Тур супермодели. Этот тур о внешнем интерфейсе игры. На сколько он красив и привлекателен, насколько правильно используются цвета, нет ли лишних элементов интерфейса, насколько быстрая анимация, соответствует ли интерфейс стандартам и ожиданиям пользователя. Цель тура - сделать так, чтобы игра смотрелось великолепно, как супермодель на подиуме.  4.2.) Тур по шотландским пабам. Не всегда можно узнать об интересных местах из путеводителя. Иногда, для этого нужно заглянуть в паб. Форумы и блоги, в ним узнать много нового об игре. (В основном это касается крупных игр или игр с большой фан базой). Задача тура заключается не только в проверке игры, но и в том, чтобы получше с ней познакомиться, в идеале, путём общения с игроками.
5) Туры по району отелей. Проверяют второстепенный функционал игры. Разделяются на:
5.1) Тур, отмененный из-за дождя. В этом туре проверяется возможность отмены действия игрока всеми способами: кнопкой "отмена", Esc, Alt + F4, отмена каста заклинания движением персонажа вперед/назад/в стороны/прыжком, закрытием игры через диспетчер задач и т.д. При этом важно отметить, возвращается ли игра в начальное состояние, сохраняются ли данные, возможно ли повторить отмененное действие.  5.2) Тур домоседа. Проверка по принципу наименьшего сопротивления, т.е. выполнять в игре только обязательные задания, качать только обязательные характеристики и т.д.
6) Туры по неблагополучным районам (самый веселый). Проверка уязвимых мест в игре, которые часто используют недобросовестные игроки. Разделяются на:
6.1) Тур диверсанта. Тестировщик должен подорвать работу игры всеми возможными способами. Для этого нужно начать выполнить какое-то действие, определить ресурсы, необходимые игре для выполнения этого действия, удалить или ограничить доступ к этим ресурсам, повторить действие. Например, отключить интернет, ограничить размер оперативной памяти, удалить файл, который считывает игра, ограничить права на выполнение операции, запустить игру на проблемном окружении и т.д. Ограничивайся только своей фантазией!  6.2) Антисоциальный тур. В этом туре нужно делать с игрой то, что обычный пользователь не стал бы делать. Т.е. делай все то, что противоречит логике игры.  6.3) Тур невротика. Повторяй одни и те же действия в игре много и часто.

Если ты дочитал до этого моменты, то я тебя поздравляю! Теперь ты знаешь техники тест-дизайна: умеешь разбивать тесты на классы эквивалентности, проверять граничные условия и понял, как можно эффективно предугадывать ошибки. Надеюсь это поможет тебе в создании тестов, лично мне эти значения хорошо помогают в работе. В заключении, хочу перечислить характеристики, которыми должен обладать хороший, эффективный тест:
* Тест должен выявлять ошибки;
* Набор тестов не должен быть избыточным;

* Тест должен быть наилучшим в своей категории;
* Тест не должен быть слишком простым или сложным;

* Между тестами не должно быть зависимостей (серьезно, не надо).

Ну вот и все на сегодня. Спасибо что уделил мне свое время! Надеюсь тебе понравилась статья. В следующий раз мы начнем рассматривать виды тестирования. Возможно первым станет регрессионное тестирование.

До встречи!