Текст книги "Тестирование видеоигр, или Легкий способ попасть в геймдев"

Глава 03. Чтобы все хорошо сделать, нужно все хорошо организовать

Хочешь ходить по воде – научись сначала плавать.

Dragon Age 2

• Как устроена работа тестировщика?

• Зачем нужно планировать работу?

• Как предвидеть риски?

• Зачем нужно проектировать тесты?

• Зачем нужно устанавливать сроки начала и окончания тестирования?

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

• Какие документы готовит тестировщик?

• Что такое чек-лист, тест-кейс и тестовый набор?

• Когда и как нужно завершать тестирование?

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

Этот алгоритм состоит из четырех основных этапов.

1. Планирование

2. Проектирование

3. Реализация

4. Завершение

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

Фундаментальный процесс тестирования

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

Максим Филиппов, QA-менеджер Saber Interactive

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

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

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

3. Выполнить тестирование оптимальным способом. Не всегда стоит нестись сломя голову и просто проверять все свои гипотезы на фиче. Самая частая ошибка, которую я встречал в работе: QA получает задачу, что он должен протестировать N сущностей и получить N логов о работе сущностей. QA тестирует N сущностей и получает 0 логов. Потому что стоило бы после проверки первой сущности проверить, возможно ли получить логи вообще: баги могут быть везде.

Легко сделать неправильно, сложно сделать хорошо. Но хорошо сделать приятнее!

3.1. Планирование тестирования

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

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

В зависимости от ситуации и проекта возможны разные подходы к разработке плана тестирования. Существуют стандарты, подробно описывающие план тестирования и его содержание, – международный стандарт ISO/IEC/IEEE29119–3:2013 и российский ГОСТ Р 56922–2016. Рекомендую тебе ознакомиться с ними более подробно, лишним это точно не будет. Хотя нужно сказать, что в подавляющем большинстве случаев тебе не придется писать многостраничные планы, соблюдая все требования стандартов. Достаточно хорошо проработанный план может занять всего 2–3 страницы и при этом быть отличным руководством для работы.

Хороший план тестирования должен включать в себя ответы на следующие вопросы.

1. Что именно нужно тестировать? (Нужно описать объект тестирования, то есть сам игровой продукт. Это не только поможет быстрее адаптировать нового члена команды, но и во многом заменит отсутствующую документацию.)

2. Что будет тестироваться? (Тот функционал игры, который ты собираешься протестировать с максимальным покрытием.)

3. Как именно будет проводиться тестирование? (Нужно описать виды тестирования и типы проверок в рамках избранной стратегии тестирования и метрики для осуществления эффективного мониторинга.)

4. Когда именно будете проверять? (Это фактически информация о сроках и этапах тестирования.)

Кроме этого, в плане обязательно нужно отразить информацию о:

1. критериях начала и окончания тестирования;

2. программно-аппаратной части, используемой для тестирования (тестовой платформе);

3. потенциальных рисках продукта и проекта и плане управления ими.

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

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

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

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

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

Функциональное тестирование – это проверка соответствия реализованного игрового функционала формальным требованиям и спецификациям, а если их нет – требованиям и ожиданиям пользователя. Это проверка того, ЧТО можно делать в игре.

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

• Основные виды тестирования производительности:

· нагрузочное тестирование (Performance and Load Testing)

· тестирование стабильности или надежности (Stability/Reliability Testing)

• Тестирование установки (Installation Testing)

• Тестирование удобства пользования (Usability Testing)

• Тестирование на отказ и восстановление (Failover and Recovery Testing)

• Конфигурационное тестирование (Configuration Testing)

• Тестирование безопасности (Security and Access Control Testing)

Следующий шаг – определиться со стратегией тестирования, выбор которой зависит от разных обстоятельств и условий. Опыт показывает, что в случаях тестирования игр в большинстве случаев выбирается аналитический подход. В одних случаях главным становится анализ некоторого фактора (например, требования или риска). В других – моделирование различных процессов, например игровой функции (движение персонажа) или нефункциональной характеристики (выдерживание игровым сервером определенной нагрузки). Стратегий довольно много. Также много об этом написано в разной литературе (например, в силлабусе «QA-Manager» ISTQB).

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

Матрица трассируемости – это, по сути, таблица, в которой отображается связь тестируемых сущностей или проектных требований и спроектированных для такой проверки тест-кейсов. На пересечении соответствующих строки и столбца устанавливается отметка, означающая, что функциональность или выполнение требования покрывается тест-кейсом. Обычно матрица используется, когда имеются четко сформулированные требования, и проверка выполняется с целью тестирования выполнения программным продуктом этих требований. Но в случае с тестированием игр в качестве требований могут использоваться ожидания пользователя (и, естественно, твои как опытного пользователя и знатока игр) от игрового функционала, то есть так называемые «пользовательские истории» (user stories). Они могут быть объединены в укрупненные группы на основании определенной логики. Например, могут проводиться объединенные проверки функционирования оружия персонажа, состоящие из нескольких тест-кейсов (см. таблицу). Как правило, эти «пользовательские истории» используются в качестве атрибута «ожидаемый результат» проектируемого тест-кейса. Но об этом позже.

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

1. Остался ли в игре непокрытый тест-кейсами функционал или области?

2. Не будет ли проводиться избыточного тестирования, если по одному требованию / «пользовательской истории» есть несколько пересечений?

Она позволяет:

• визуализировать актуальное состояние реализации проекта;

• разбивать требования на более мелкие (атомизировать требования) и структурировать их;

• отслеживать, есть ли требования, на которые еще не запланирована разработка;

• отслеживать, реализовано ли требование в данный момент;

• отслеживать, покрыто ли требование тест-кейсом;

• наглядно отображать приоритизацию требований.

Кроме того, матрица трассируемости в чуть более сложном виде позволяет проследить связь между задачами разработчика, требованием / «пользовательской историей», приоритетом его реализации в проекте, критериями приемки и тест-кейсом для проверки его функционала. Это существенно упрощает управление проектом и экономит огромное количество ресурсов.

При разработке матрицы трассируемости можно выделить следующие этапы.

1. В начале требования дробятся на более мелкие и/или преобразуют в конкретные задачи для выполнения командой тестирования (декомпозируют). Также команда QA устанавливает очередность проведения этих проверок в зависимости от ситуации (приоритизирует). Результатом этапа становится структурированный и приоритизированный список всех требований по данной функциональности – список «пользовательских историй».

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

3. Третий этап – разработка тест-кейсов. Она проводится непосредственно перед тестированием.

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

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

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

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

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

В плане тестирования отражаются еще два важных критерия – начало и окончание тестирования.

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

Ты скажешь: «А что тут сложного? Берем проект и начинаем работать!» Хотелось бы, чтобы все в жизни было так просто, но как говорил Ежи Лец: «В действительности все совершенно иначе, чем на самом деле». Представь, что в палату заходит хирург и между ним и медсестрой в присутствии пациента происходит следующий диалог.

Хирург: Ну что? Мне все ясно! Будем оперировать.

Медсестра: Начинаем готовить пациента к операции?

Хирург: А чего тут готовить? Давайте скальпель, здесь все и сделаем.

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

Ниже приведены критерии начала тестирования.

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

2. Наличие спецификаций/требований к продукту, «пользовательских историй» или моделей, если используется стратегия тестирования на основе моделей.

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

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

С окончанием тестовых активностей тоже должна быть ясность. Ниже приведены его критерии.

1. Все запланированные тесты выполнены.

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

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

4. Превышение бюджета.

5. Истечение срока, отведенного на тестирование.

6. Решение заинтересованных лиц о выводе продукта на рынок.

7. Закрытие проекта.

Представь, что ты решил сделать ремонт в квартире. Что тебе для этого понадобится? Деньги для покупки материалов? Инструменты? Время для проведения ремонта? Помощники? А что случится, если чего-то из списка выше нет? Или есть, но недостаточно? Добьешься ли ты цели при отсутствии или недостатке ресурсов? Вряд ли.

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

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

• конкретных исполнителей задач;

• длительности задачи с учетом ограниченной доступности ресурсов;

• потребности в ресурсах в тот или иной период исполнения проекта;

• календарный график с учетом ограничений (недостаточности) ресурсов.

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

1. трудовых ресурсов – это команда тестировщиков и другие специалисты, участвующие в проекте;

2. материальных ресурсов – это оборудование, программы, мебель, коммунальные услуги и т. д.;

3. финансовых ресурсов – это те денежные средства, на которые приобретаются почти все остальные виды ресурсов;

4. информационных ресурсов – вся документация, требования и т. д., а также информация, получаемая из других источников, в том числе на различных планерках;

5. временных ресурсов.

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

Воспроизводимые ресурсы могут быть внутренними и внешними.

На ресурсы можно смотреть по-разному

Поговорим о разных ресурсах подробнее.

Трудовые ресурсы

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

1. Количественной. Сколько специалистов нужно привлечь для реализации проекта?

2. Качественной. Какими знаниями и навыками должны обладать эти специалисты?

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

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

Зависимость производительности команды от времени формирования

1. Формирование

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

Производительность команды на этом этапе довольно низкая.

2. «Штормовая»

Это этап появления первых конфликтов, которые, если ими не управлять, станут для группы последними.

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

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

3. Нормирование

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

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

4. Деятельность

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

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

Производительность команды на этом этапе на пике.

5. Дезинтеграция

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

Производительность команды на этом этапе – высокая с тенденцией к снижению.

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

Материальные ресурсы

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

• Аппаратное обеспечение и комплектующие

• Программное обеспечение

• Средства связи

• Рабочее место сотрудника

• Объекты бытового назначения и т. д.

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

Инструменты бывают разные. Например, шуруп можно вкрутить отверткой, а можно электрическим шуруповертом – и это будет намного быстрее. Поэтому тебе необходимо понимать, какой «инструмент» нужен в каждом конкретном процессе проекта.

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

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

При планировании себестоимости[20]20
  Себестоимость проекта – стоимостная оценка всех затрат на реализацию проекта.


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

Временные ресурсы

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

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

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

Ниже приведены методы определения времени, необходимого для выполнения задачи.

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

2. Метод оценки по трем точкам (дается оценка реализации задачи с точки зрения времени по трем сценариям – пессимистичный (П), оптимистичный (О) и средний (С)). Оценка по всем сценариям дается с использованием экспертного метода (п. 1) и выражается в часах или днях. Затем полученные значения подставляются в формулу (П+О+4С)/6. Такая формула позволяет с одной стороны учесть возможные позитивные и негативные сценарии, а с другой – сгладить их влияние и получить более реальное значение оценки.

3. Оценка по аналогиям (в данном случае оценка проводится путем сравнения задачи с аналогичной из прошлого опыта команды или руководителя тестирования).

4. Метод триангуляции (часто используется в моделях гибкой разработки, таких как Scrum). Этот метод похож на предыдущий (п. 3), но сочетает в себе два подхода: метод аналогий и экспертную оценку. Задачи разбиваются на три типа:

• мелкая;

• средняя;

• крупная.

Каждой из них присваивается некоторое количество баллов. Например, мелкая – 1 балл, средняя – 3 балла, крупная – 5 баллов. При этом 1 балл равен некоторому количеству времени. Затем команда берет на себя обязательство по выполнению задач на некоторое количество баллов в течение одной итерации и в соответствии с этим строится диаграмма сгорания (Burndown Chart).

Информационные ресурсы

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

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

В рамках проекта тестировщик взаимодействует (получает и передает устную и письменную информацию) с разными специалистами.

• Разработчики (программисты, художники, гейм-дизайнеры, звукоинженеры, переводчики и проч.)

• Менеджеры проекта и продюсеры

• Руководители проектных групп (лиды)

• Коллеги, внешние эксперты

• Другие заинтересованные лица

Вся получаемая и передаваемая информация обладает важными свойствами.

1. Актуальность. Она может быть оценена по степени необходимости и важности информации для решения конкретной задачи в конкретный момент времени.

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

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

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

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

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

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

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

5. Достоверность. Информация может считаться достоверной, если она отражает реальную ситуацию. Достоверность информации очень сильно влияет на качество принимаемых решений. Примеры недостоверной информации – дезинформация (преднамеренное искажение) и искажение в результате воздействия «помех».

В требованиях есть упоминание о том, что персонаж, принимающий участие в одной из военных операций Второй мировой войны, вооружен автоматом АК-47. Это требование не может быть достоверным, поскольку это оружие было принято на вооружение только в 1949 году, то есть через несколько лет после окончания войны.