На этой стадии наборы вышеописанных тестов запускаются в соответствии с расписанием. Основными активностями тестировщика тут будут:
• выполнение тестов вручную или с помощью специальных инструментов;
• сравнение фактических и ожидаемых результатов;
• анализ обнаруженных отклонений для установления вероятных причин их возникновения (анализировать баги мы будем в последующих главах);
• составление отчетов о дефектах на основе получаемых результатов;
• протоколирование результатов выполнения тестов (например, пройден, не пройден, блокировка);
• повторение тестов, в результате которых были обнаружены отклонения в рамках запланированного тестирования (например, выполнение исправленного теста) и/или регрессионного тестирования.
Как ты понимаешь, выполнение тестирования – самый длительный процесс: именно на этом этапе тестировщик выполняет все тест-кейсы, которые спроектировал ранее. Кроме того, он еще описывает найденные дефекты, ставя задачу разработчику по его устранению в системе баг-трекинга.
Тем не менее существуют диаметрально противоположные взгляды на использование систем баг-трекинга: от полного неприятия до полного восторга. Первые считают большой глупостью фиксировать дефект в какой-то системе, не исправляя его сразу так, как это сделал бы любой разработчик, найдя ошибку в своем коде. Другие говорят, что, определяя порядок и скорость исправления дефектов, мы тем самым экономим время команды разработки и упорядочиваем процесс создания продукта. Здравые мысли и аргументы есть у одних и у других, поэтому можно разобрать и тот и другой подход и решить для себя, какой из них будет наиболее оправдан в конкретных обстоятельствах.
Сторонники теории «исправь сразу или забудь навсегда» аргументируют свою позицию следующим.
1. Разработчик по прошествии времени забывает код, который вызвал ошибку, и от него требуются серьезные усилия по ее исправлению.
2. Тестировщик может неправильно идентифицировать дефект (об этом пойдет речь в следующей главе), и его исправление, отложенное на потом, может привести к непредсказуемым последствиям.
3. Многие менеджеры не могут справиться с искушением начать оценивать работу тестировщиков, используя количественные метрики (например, количество найденных багов в течение рабочего дня и прочую чушь). Такая оценка сразу приводит к тому, что тестировщиков перестают занимать дефекты, их предотвращение и улучшение качества продукта. Они начинают фокусироваться на получении бонусов за большое количество часто несуществующих в природе багов.
Случай № 1. Не слишком умный менеджер ввел правило оценивать тестировщиков по количеству найденных ими дефектов. А его коллега всячески поощрял разработчиков, когда они исправляли обнаруженные тестировщиками дефекты. Вскоре тестировщики договорились с разработчиками, что последние специально будут делать ошибки в коде, чтобы тестировщики фиксировали их в баг-трекинговой системе, и все могли получать бонусы. Стоит ли говорить, что никого уже не волновал создаваемый продукт и его качество?
Случай № 2. Еще один менеджер предложил систему финансового стимулирования тех тестировщиков, кто нашел и завел в систему баг-трекинга больше всех дефектов. Через некоторое время количество записей о найденных дефектах резко возросло, и каждая запись указывала на несоответствие требованиям. Казалось бы, так и должно быть, однако оказалось, что эти несоответствия были не дефектами, а… улучшениями или дубликатами с разным описанием.
Случай № 3. Не лучше оказался подход и третьего менеджера. Он ввел KPI для тестировщиков, по которому они должны были ежедневно находить и заносить в систему баг-трекинга минимум 10 дефектов. Очень скоро тестировщики поняли, что к чему, и стали придерживать «лишние» дефекты. И даже если в один день тестировщики находили 20 багов, они «репортили» (заводили в системе баг-трекинга) только по 10, чтобы на следующий день… ничего не делать.
Сторонники этого подхода предлагают сосредоточиться на предотвращении дефектов, а не фиксации багов для исправления их в будущем (например, с помощью методологии разработки через приемочное тестирование (acceptance test driven development, ATDD)). ATDD развивает идеи разработки через тестирование (test driven development, TDD). Общий смысл этой методологии таков: прежде чем что-то делать, надо придумать критерии выполненной работы и критерии того, что работа выполнена правильно. Эти критерии позволяют на самом раннем этапе понять, что именно требуется сделать, как это сделать и что именно считать результатом.
Чтобы эти критерии были понятны конечному заказчику, они описываются на понятном ему языке в виде готовых сценариев использования разрабатываемого функционала. Если сценарий исполняется и ожидаемый результат получен, работу можно считать выполненной правильно. Набор подобных сценариев называется приемочными тестами. Они фокусируются на поведении системы с точки зрения человека, то есть самое важное в оценке – возможность получить ожидаемый пользователем результат.
Цель приемочного тестирования – показать, как изменяется тестируемая система в конкретном случае. Для этого в сценарии необходимо описать изначальное состояние системы, затем внешнее или внутреннее действие, которое эту систему меняет, и ожидаемый пользователем результат такого воздействия, то есть новое состояние системы. При этом систему мы видим как «черный ящик»: мы не знаем, как она устроена внутри и с чем взаимодействует снаружи, а критерием успешности считаем переход системы в новое состояние.
Для разработки приемочных тестов используется метод Given – When – Then (GWT).
• Given описывает что «дано», то есть изначальное состояние системы.
• When описывает воздействие (обычно пользователя) на систему изнутри или извне, которое должно привести к результату.
• Then определяет конечное состояние системы, то есть результат этого действия, что и является критерием приемки.
Тебе не кажется все это уже знакомым? Присмотрись! У тебя есть (Given) рабочий из космической стратегии, когда (When) ты даешь ему приказ мутировать, указав место здания, кликнув на карте, он (Then) начинает движение к этому месту и, достигнув его, начинает мутировать в выбранное тобой здание. Ты можешь использовать табличное описание следующего вида.
Также можно использовать диаграмму перехода состояний для проектирования приемочных тестов.
Метод Given – When – Then позволяет описать все случаи поведения системы. Для этого нужно:
1. определить все состояния, которые могут быть заданы, то есть все Given;
2. определить все виды воздействия, то есть все When;
3. определить все Then, что именно должно произойти;
4. комбинаторно перемножить списки.
Если все сделано правильно, ты получишь полный набор тестов для проверки системы.
На каждом из этих этапов требуется участие человека, который лучше всех представляет, что и как в итоге должно работать (в нашем случае, например, гейм-дизайнера).
Обрати внимание: проектируя приемочные тесты, ты фактически описываешь функционал системы, то есть создаешь функциональные требования к системе с точки зрения пользователя.
Эта методология крайне полезна во всех случаях. Без требований тестировщик, используя этот метод, может «восстановить» спецификацию, проектируя тесты на основе своего богатого игрового опыта, который поможет определить, что игрок будет ожидать от системы. А если разработчики используют методологию для определения критериев приемки до начала разработки, она позволяет существенно сократить количество дефектов, четко определяя с самого начала, что будет считаться правильным.
Несмотря на все свои достоинства, эта методология не лишена недостатков. Первый и самый большой из них – большой набор тестов, получаемый на выходе, и довольно большой процент избыточности (часть тестов будет дублировать друг друга). С другой стороны, подход дает уверенность в том, что ни один из сценариев не будет пропущен. Кроме того, можно расставить приоритеты сгенерированным тест-кейсам и тем самым определить порядок их выполнения.
Второй недостаток – достаточно сложный процесс внедрения методологии и подключение к ее использованию разных команд.
Кроме того, противники этого подхода отмечают невозможность написания сложных автоматизированных тестов. Однако это не может рассматриваться в качестве аргумента в нашем случае. В тестировании игр мало проверок поддаются автоматизации и при этом автоматизация не применяется в сложных сценариях, потому что требует существенных ресурсов, которые зачастую лучше направить на разработку самой игры.
Большинство команд, занимающихся тестированием игр, особенно те, кто работают на аутсорсе[22], в настоящее время используют традиционные методы, подразумевающие совместную итеративную работу тестировщиков и разработчиков с использованием баг-трекинговых систем. Формально ни одна из перечисленных систем не является специфическим ПО для проведения тестирования. Это системы совместного доступа для управления проектами и задачами.
3.4. Завершение тестирования
После того как выполнение тестирования завершено, отчет о дефектах и протоколы тестирования (если необходимо) подготовлены, нужно правильно завершить все процессы, извлекая максимальную пользу из проекта на будущее. Выше говорилось о том, что для завершения тестирования устанавливаются некоторые критерии, по выполнении которых работа считается завершенной. На самом деле процесс завершения начинается гораздо раньше.
Активности по завершении тестирования принято недооценивать. И действительно, зачем что-то специально готовить? Все тесты выполнены. Баги найдены или не найдены. Работа завершена. Всем спасибо, все свободны.
На самом деле процесс завершения тестирования такой же важный, как и все до него. Он состоит из следующих групп активностей.
1. Проверка завершения тестирования. Необходимо получить подтверждение того, что все работы по тестированию действительно завершены.
2. Передача «наследия». Другими словами, любые ценные продукты тестирования должны быть переданы заинтересованным лицам: дефекты в полном объеме ответственным за их исправление лицам, наборы регрессионных тестов – команде поддержки, тестовое окружение и документация – команде тестирования на стадии поддержки. Кроме того, вся документация должна быть сохранена и проверена для последующего использования и находиться в структурированном и понятном виде.
3. Ретроспектива и рефлексия. Организация встреч для улучшения процессов тестирования: насколько точен был план тестирования и какие изменения могли бы быть внесены, насколько точны были оценки рисков, выбор программно-аппаратной части для тестирования, насколько эффективен был анализ дефектов, насколько соответствовали требованиям проекта квалификация членов команды и т. д. Результатом таких встреч должен стать документ, который часто называют постмортем (Postmortem).
4. Формализация. Разработка, подписание и передача всех необходимых документов.
Примеры критериев завершения тестирования были упомянуты в самом начале этой главы, и на самом первом этапе завершения тестирования тебе следует убедиться в том, что все, о чем ты договорился с заказчиком, выполнено.
После того как подтверждение получено, нужно подготовить список материалов и артефактов тестирования, которые надо передать команде поддержки, и тех материалов, которые необходимо сохранить для использования в будущем. Почему это важно? Потому что ядро тест-кейсов не меняется при тестировании игр одного жанра. Если ты тестировал Duke Nukem, то большое количество тест-кейсов подойдет и для тестирования последнего Doom: движение персонажа, подбор оружия, стрельба, переключение оружия, его перезарядка, нанесение урона, поведение мобов и т. д. Все это будет требовать проверки в любом FPS без исключений. Так зачем каждый раз изобретать велосипед, если можно использовать лучшие практики?
По окончании тестовых активностей (а часто и по завершении разных его этапов) создаются различные документы.
3.4.1. Отчетные документы
1. Отчет о результатах тестирования (Test Result Report)
Это периодический отчет (ежедневный, еженедельный, ежемесячный и т. д.), в котором документируется подробная информация о выполнении и результатах тестирования. В нем также содержится подробная информация об оставшейся работе, чтобы показать, сколько еще необходимо сделать.
2. Отчет о выполнении теста (Test Execution Report)
Cодержит детали выполнения и результат выполнения теста. Обычно его готовят для отправки вышестоящему руководству, чтобы показать состояние выполнения теста и ход тестирования. Он дает лучшее понимание выполненной работы.
3. Отчет о ходе тестирования (Test Progress Report)
Документ, подводящий итог задачам и результатам, составляется с определенной периодичностью, чтобы сравнить прогресс тестирования с базовой версией (например, с исходным планом тестирования) и сообщить о рисках и альтернативах, требующих решения руководства.
4. Аналитический отчет о тестировании (Test Evaluation Report)
Документ, создаваемый в конце процесса тестирования и подводящий итог тестовым активностям и результатам. Также в нем содержится оценка процесса тестирования и полученный опыт.
5. Итоговый (сводный) отчет о тестировании (Test Summary Report)
Содержит подробную информацию о тестировании, проведенном на протяжении жизненного цикла разработки ПО. Элементы в итоговом отчете по тестированию различаются в разных компаниях и для разных проектов. Информация о проведенных работах по тестированию основывается на целевой аудитории отчета. Это могут быть клиенты, менеджмент, бизнес-аналитики, разработчики, члены команды тестирования, члены организации и т. д.
Кроме этих документов, в разных компаниях могут быть приняты и другие виды отчетности, например отчеты о прохождении «вех» проекта (MS Report), отчет, который позволяет создавать различное ПО: системы управления тестированием или баг-трекеры.
Ты не сможешь улучшить свои рабочие навыки, не получив мнения своих коллег и руководителя, поэтому на этапе завершения очень важны ретроспективные встречи и рефлексии. На них команда обычно обсуждает вопросы, связанные с улучшением процессов, и оценивает проделанную работу.
И, наконец, на этом же этапе готовятся формальные документы, которые необходимо передать заинтересованным лицам. К таким документам относят прежде всего отчет о тестировании (Test Result Report, TRR), где дается оценка тестируемому продукту и проекту. Первый вопрос, на который нужно дать ответ себе, – для кого создается отчет?
Исходя из определенной целевой аудитории, нужно определить, какую информацию необходимо включить в отчет. Можно выделить несколько групп заинтересованных лиц.
1. Разработчики. Их приоритеты – количество и критичность выявленных багов и общее состояние продукта. Информация необходима для планирования процесса разработки.
2. Менеджеры продукта. Этих ребят интересует прежде всего состояние проекта. Лишние технические подробности им не нужны. Фокус отчета – на сроках выполнения и на общую статистику. На основании полученной информации менеджер проекта должен сделать вывод о том, продвигается ли проект согласно плану и достаточно ли для выполнения задач выделенных ресурсов.
3. Маркетинг и поддержка. Маркетологи и специалисты службы поддержки хотят получить информацию об общем состоянии продукта, его готовности к релизу и потенциальных проблемах, которые могут вызвать недовольство пользователей. Информация нужна в том числе и для понимания потенциальных репутационных рисков.
4. Бизнес-пользователи. Как правило, это люди, которые принимают решения о завершении тестирования. Они же определяют качество проделанной работы. Для них в первую очередь важен конечный результат, наглядное представление информации (графики, диаграммы), экспертное мнение о возможности релиза игры без погружения в детали.
Для какой бы целевой аудитории ни составлялся отчет, в нем должны содержаться обязательные следующие разделы.
1. Краткое описание. В краткой форме отражает основные достижения, проблемы, выводы и рекомендации. В идеале прочтения краткого описания должно быть достаточно для формирования полноценного представления о происходящем, чтобы не читать весь отчет.
2. Состав команды – список участников проектной команды, задействованных в обеспечении качества, с указанием их должностей и ролей.
3. Срок, за который составляется отчет.
4. Описание процессов тестирования, то есть какие работы были выполнены за отчетный период.
5. Расписание тестовых работ всей команды тестировщиков и/или личные расписания конкретных членов команды.
6. Статистика по дефектам. Это таблица, в которой представлены данные по обнаруженным за все время существования проекта дефектам. Как правило, в этот же раздел добавляется график, отражающий такие статистические данные.
7. Критичные и блокирующие проблемы, а также принятые меры по их устранению.
8. Результаты регрессионного тестирования (опционально).
9. Выводы и рекомендации по принятию тех или иных управленческих решений (изменению тест-плана, запросу или освобождению ресурсов и т. д.).
Отчет должен быть реально полезным для того, кому он предназначается. Поэтому, как в любом другом отчетном документе, в нем должна прослеживаться универсальная логика.
1. Выводы нужно делать, помня о целях, отраженных в плане тестирования.
2. Выводы должны быть краткими и информативными для целевой аудитории отчета.
3. Если делаются выводы, нужно добавить рекомендации.
4. Рекомендации должны быть краткими, выполнимыми и содержащими алгоритм действий и целей, к которым эти действия должны привести.
5. Рекомендации также необходимо обосновывать.
6. Обоснование строится на объективных фактах, а не на предположениях и интуиции.
Кроме этого, на этапе завершения тестирования тебе может пригодиться умение пользоваться некоторым дополнительным ПО.