Это не отдельный этап проекта, а постоянная работа руководителя тестирования (лид, тест-менеджер) для отслеживания хода выполнения проекта по тестированию со сравнением ситуации на проекте с планом. Контроль прогресса обычно проводится на контрольных точках проекта, которые называются вехами (milestones)[23]. При этом мониторинг осуществляется в постоянном режиме с использованием специальных метрик. Метрики – это показатели, которые позволяют менеджеру делать выводы о ходе выполнения проекта и его состоянии.
3.5.1. Метрики тестирования
Пропуск дефектов
а. Количество пропущенных дефектов (Bugs Leakage). Используется для анализа причин ненахождения дефектов.
б. Процент (%) дефектов, найденных не тестировщиками (Bugs Reported Not by Testers). Используется для анализа того, почему другие участники процесса разработки находят пропущенные тестировщиками дефекты. Это может быть признаком недостаточной квалификации специалистов по тестированию.
в. Пропуск дефектов по категориям (Bugs Leakage by Category). Необходима для анализа, в каких областях нужно развивать компетенции тестировщиков. В качестве категории могут выступать функциональные области, уровни тестирования и т. д.
Тестовое покрытие
а. Покрытие требований тестами (Requirements Coverage). Используется для анализа и отслеживания полноты тестового покрытия. В этом случае обязательно установление критерия «Требование к тестам» – например, хотя бы один тест на требование. Для вычисления этой метрики можно использовать матрицу трассируемости.
В этой области может быть использовано достаточно большое количество специфических метрик, связанных с покрытием конкретных функциональных и нефункциональных областей игрового продукта: покрытие требований нагрузки, производительности и т. д.
Следование плану работ
а. Срывы сроков по задачам (Schedule Slippage). Используется для выявления среднего срока срывов начала выполнения задач и включения его в план управления рисками.
б. Отклонение от плана работ (Schedule Variance). Позволяет рассчитать величину отклонения реального выполнения работ на проекте от плана. Используется для контроля выполнения проекта.
в. Превышение трудозатрат (Estimation Changes). Используется для проверки корректности проводимых плановых оценок трудозатрат по проекту.
Дефекты в продукте по категориям
а. В этой группе представлено несколько метрик для мониторинга количества дефектов в продукте по разным категориям: критичность, функциональная область, тип тестов и т. д.
Результаты тестирования
а. Пройденные/непройденные тест-кейсы (Passed/Failed Test Cases). Показывает процент работающей функциональности, качество и стабильность продукта.
б. Запущено тестов (Executed Test Cases). Показывает процент оставшихся работ по тестированию проекта.
Работа с дефектами
а. Процент исправленных дефектов (Bugs Fix Ratio). Используется для определения процента исправленных дефектов.
б. Процент неисправленных дефектов (Bugs Reject Ratio). Используется вместе с предыдущей метрикой для определения причин НЕисправления дефектов и оценки квалификации специалистов по тестированию.
в. Причина отклонения дефектов (Rejection Causes). Применяется для анализа причин отклонения и обучения тестировщиков. Здесь в баг-трекер необходимо добавить выпадающий список причин, по которым отклоняются дефекты: не воспроизводится, неправильное понимание ожидаемого результата, ошибка в требованиях и т. д.
Нужно добавить, что тестировщику вряд ли придется использовать метрики для мониторинга проекта: это работа лида или тест-менеджера. Однако эта информация будет тебе очень полезна для развития карьеры в тестировании.
3.5.2. Оценка проекта на вехах (контрольных точках)
Для принятия решения о приеме результатов какой-либо работы до ее начала должны были быть установлены критерии приемки, подробно описывающие ожидаемый результат, и характеристики объекта приемки с точки зрения соответствия требованиям. Критерии приемки могут касаться количественных и качественных характеристик полученного результата работ. Для облегчения процедуры приемки также устанавливаются правила тестирования объекта для подтверждения его соответствия установленным критериям качества.
Полученный результат работы должен отвечать критериям приемки, установленным до начала работы
Проверки по критериям могут быть отнесены к трем базовым группам.
1. Проверка готовности (Readiness check). Объект оценивается с точки зрения формальных признаков готовности.
2. Проверка на соответствие минимальным критериям (Must-meet criterion). Проверка того, что объект отвечает минимальным требованиям (например, системным).
3. Проверка на соответствие желаемым критериям (Should-meet criterion). Проверка того, что объект отвечает желаемым (рекомендуемым) требованиям.
Если результат работ какого-либо из этапов разработки отвечает приемочным критериям, и это подтверждается результатами проверки (тестов), то веха считается пройденной и проект получает гринлайт[24] для продолжения.
Мы достаточно подробно рассмотрели рабочий процесс тестирования и все его стадии. Теперь ты имеешь базовое представление о том, чем занимается тестировщик, и готов двигаться дальше. Но сначала я предлагаю тебе проверить свои знания.
Ответь на вопросы теста. Ответы ты найдешь в конце книги.
1. К каким ключевым шагам фундаментального процесса тестирования принадлежат следующие задачи и активности и в какой последовательности они выполняются?
• Сравнение фактических и ожидаемых результатов
• Определение необходимых тестовых данных для поддержки тестовых условий
• Создание сводного отчета по тестированию
• Определение целей тестирования
• Анализ требований
2. Одно из полей формы содержит текстовое поле, которое принимает целые числовые значения в диапазоне 10≤ × ≤50. Какие граничные значения будут справедливы для проверки этого условия?
3. Что из перечисленного должно быть сделано на этапе завершения тестирования?
• Создание наборов тестов.
• Написание итогового отчета для заинтересованных сторон.
• Передача тестируемой программы организации обслуживания.
• Определение необходимой инфраструктуры и инструментов.
4. В результате проведения тестовых работ команда тестировщиков подготовила отчет для менеджмента, в котором подробно описала все найденные дефекты, условия и частоту их проявления, технические характеристики системы. Менеджер не смог разобраться в ситуации и верно оценить ход проведения работ по тестированию. В чем была допущена основная ошибка при написании отчета?
5. Какая информация из отчета о дефекте наиболее эффективна при определении срочности и усилий по исправлению этого дефекта?
A. Дата создания отчета
B. Подробное описание дефекта
C. Ожидаемый и фактический результат
D. Приоритет дефекта
E. Имя тестировщика, обнаружившего дефект
F. Рекомендации по исправлению дефекта
Глава 04. Когда не знаешь, с чего начать, начинай с сути
Война. Война никогда не меняется.
• Кто разрабатывает игры и зачем это знать тестировщику?
• Какие бывают игры?
• Как исследовать объект тестирования?
• Как тестировать ключевые функциональные области?
• Как тестировать ключевые нефункциональные области?
• Как тестировать требования?
Любому тестировщику было бы здорово иметь хотя бы общее представление о том, как и кем создаются игры, – хотя бы для того, чтобы понимать, кому из разработчиков нужно адресовать отчет о дефектах. Выше говорилось о важнейших игровых подсистемах. Попробуем поближе рассмотреть, что в них происходит и кто главный в их разработке. Конечно, над разными проектами работают разные команды и специалисты. Здесь я привожу список специалистов стандартной команды игровой разработки.
Итак, давай начнем с гейм-дизайнера. Конечно, у меня нет задачи рассказать в книге о тестировании все о гейм-дизайне (здесь я делаю вид, что будто бы действительно знаю об этом все ☺), но базовые вещи небходимы для любого игрового тестировщика. Если же ты захочешь узнать о работе гейм-дизайнера больше, то в списке рекомендуемой литературы в конце будут ссылки на некоторые полезные книги по этой теме.
Работа гейм-дизайнера похожа на работу режиссера фильма. И так же, как в кинематографе, игры содержат некие наборы решений, характерных для конкретных жанров, которые определены:
• предпочтениями пользователей (фэнтезийный сеттинг, разные типы оружия и т. д.);
• жанровыми особенностями (наличие оружия и огромного количества врагов обязательно для FPS, диалоги с NPC – для RPG, препятствий – для платформеров и т. д.);
• сюжетными линиями (характерные для разных жанров);
• целями, которые нужно достигнуть в игре;
• характеристиками игровых персонажей (пираты, викинги, первобытные люди, бандиты, маги, военные и т. д.);
• временем действия (Средневековье, настоящее время и т. д.);
• техническими ограничениями аппаратной части игровой платформы;
• и т. д.
Чтобы лучше ориентироваться в той области, в которой творит гейм-дизайнер, нужно пристальнее посмотреть на игры с точки зрения принадлежности к разным жанрам.