• анализа и декомпозиций бизнес-требований;
• описания бизнес-процессов;
• изучения стандартов и регламентов;
• анализа собственных реализованных проектов, проектов конкурентов.
Данные об этих требованиях могут быть получены от:
• бизнес-аналитиков;
• конечных пользователей;
• косвенных пользователей;
• менеджеров проекта;
• руководителей структурных подразделений заказчика.
Сбор и анализ этих требований входит в круг обязанностей тестировщика, в задачи которого также входит следующее.
• Определение соответствия требований критериям качества
• Анализ требований в целях проектирования тест-кейсов
Продуктовые требования бывают функциональными и нефункциональными. Функциональные требования описывают, ЧТО система должна делать, нефункциональные – КАК должна делать. Например, «Персонаж обладает возможностью прыгать (функциональное требование) не выше 2 метров и не дальше 6 метров (нефункциональные требования)».
В игровой разработке довольно много документов, содержащих различные требования к разрабатываемому игровому продукту. Особенно тщательной проверки требуют следующие.
1. Краткий ГДД (англ. Game Design Overview) – это документ, в котором кратко описаны основные цели игры и ее функционал. Он не перегружен деталями и всегда полезен, поскольку помогает всем заинтересованным лицам лучше представить полную картину.
2. Детальный ГДД (англ. Detailed Design Document) – этот документ во всех деталях описывает все игровые механики и интерфейс. На его основе создаются технические задания для разработчиков.
3. Техническое задание (англ. Terms of Reference) – это документ, описывающий структуру продукта с технической точки зрения и исключающий двусмысленное толкование исполнителями.
4. Сценарий (англ. Script). В этом документе, который может быть и частью ГДД, прописываются в том числе диалоги неигровых персонажей (от англ. non-player character, NPC). Важно проверять диалоги: есть вероятность того, что некоторые реплики могут противоречить правилам игры и требованиям локализации.
Статистика говорит о том, что порядка 75 % дефектов в разрабатываемом игровом продукте обычно возникают из-за дефектов в требованиях. Поэтому проверить нужно все документы, лежащие в основе разработки.
Если с самого начала тестировщик не смог получить документацию, необходимо использовать различные методы и подходы для получения детальной информации относительно требований к продукту.
1. Интервью. В нем, как правило, участвуют два человека: представитель заказчика и представитель исполнителя.
Плюсы этого метода: не требуется специальных технологий или специальной подготовки. Оно может быть проведено лично или посредством мессенджера.
Минусы: нужно время для обработки результатов беседы, чтобы представить результаты в письменной форме. Интервьюер может неправильно воспринять и обработать информацию и, как следствие, могут быть получены неверные данные.
2. Собрание (митинг). В нем участвуют несколько человек, которые могут задавать вопросы и участвовать в дискуссии.
Плюсы: все заинтересованные лица получают информацию одновременно. Информация уточняется и обрабатывается разными людьми, что существенно снижает риск неправильной интерпретации.
Минусы: заинтересованные лица не всегда могут собраться все вместе, и встречи могут часто переноситься.
3. Анкетирование. Проводится письменно.
Плюсы: опрашивается одновременно большое количество людей и получается довольно полная информация.
Минусы: если вопросы плохо сформулированы или выбрана неправильная целевая аудитория, то можно получить неправильную информацию.
4. Наблюдение. Этот метод основан на убеждении, что люди часто говорят неправду, преувеличивают или преуменьшают влияние различных факторов на проект, не обладают достаточными компетенциями по конкретным вопросам и т. д. В этом смысле наблюдение очень объективно и позволяет получать ценную информацию.
Плюсы: можно получить критически важную информацию, недоступную раньше. С ее учетом подход к решению задачи может быть полностью пересмотрен.
Минусы: достаточно сложен в организации (с технической, юридической и проч. точек зрения). Если процесс наблюдения организован неправильно (наблюдение проводится не там и не теми методами), есть риск, что полученная информация будет неполной или неправильной.
5. Прототипирование. Прототип выступает в двух ролях: он является источником новой информации и одновременно материальным объектом, который гораздо легче воспринимается.
Плюсы: прототип более информативен, чем любое описание.
Минусы: метод отнимает довольно много времени. Кроме того, при прототипировании можно избрать неправильный путь.
6. Моделирование. Похож на предыдущий, но гораздо более «продвинут», чем прототип.
Плюсы: в процессе моделирования можно выявить какие-то особенности объекта, которые нельзя выявить иначе.
Минусы: сложно в разработке и требует дополнительные ресурсы. Кроме того, если используются неправильные данные, модель будет неправильная и даст нам неправильную информацию.
7. Фокус-группы. Очное взаимодействие с потенциальными пользователями.
Плюсы: информация получается от реальных пользователей.
Минусы: требуется организация специально подобранной группы людей, в том числе юридическая (подписание NDA[37]).
8. Анализ документации. Самый распространенный метод получения информации; фактически это осмысленное чтение.
Плюсы: не требует специальных инструментов и навыков.
Минусы: новая информация может вызывать непонимание и вопросы. Если специалист не может получить ответы от более опытных коллег, есть большой риск того, что информация будет воспринята или интерпретирована неверно.
9. Запись полученной разными способами информации. Предполагает осмысление полученных данных (любым из упомянутых методов) через их обработку посредством записывания. Фактически это не метод сбора информации, но он используется как вспомогательный для ее осмысления.
Плюсы: позволяет использовать время для обдумывания и осмысления полученных данных.
Минусы: частая ошибка – «домысливание» и добавление собственной информации к ранее полученной, из-за чего полученные данные могут быть искажены.
Каждый из описанных выше методов может быть использован в конкретной ситуации. Их сочетание позволяет получить уточненную информацию, связанную с требованиями к продукту со стороны заинтересованных лиц.
При тестировании требований нужно помнить, что все заинтересованные лица должны понимать их абсолютно одинаково. Для тестирования требований стоит выделить опытных специалистов из числа разработчиков и тестировщиков, которые знают и понимают, как тестируются требования. Это значительно повысит шансы на то, что тестирование будет проведено как положено.
В требованиях не должно быть:
• непонятности;
• частой изменяемости;
• изменений, которые вносятся в последний момент;
• неверных или спорных трактовок.
Таким образом, чтобы избежать проблем, связанных с дефектами в требованиях, они должны обладать следующими характеристиками.
1. Понятность (требования должны быть понятными для всех заинтересованных лиц).
2. Корректность и согласованность (требование должно четко указывать на то, что должно выполнять приложение).
3. Завершенность (требование должно содержать всю информацию, которая нужна разработчикам).
4. Проверяемость (должны быть указаны способы однозначной проверки выполняемости требований).
5. Осуществимость (определяется балансом между ценностью и требуемыми ресурсами).
6. Модифицируемость (набор требований должен быть таким, чтобы его можно было легко модифицировать, при этом не изменяя требования в других местах).
7. Упорядоченность по важности и срочности.
Основные принципы тестирования требований
• Тестирование требований должно проводиться до начала разработки продукта.
• Проводить тестирование требований могут как аналитики, так и тестировщики.
• Дефекты документации ничем не отличаются от любых других дефектов.
• Если проверка требований ведется параллельно с разработкой, необходимо предупредить команду разработки о найденных дефектах, чтобы они могли вовремя исправить ошибку.
Критерии, по которым проводится тестирование документации
1. Четкость и полнота
Тестирование требований начинается с прочтения документа. Это сложно назвать тестированием в полном смысле слова, но именно во время этого этапа становятся понятными недостатки требований и выявляются разные недочеты. Если с первых строк сценария у тебя возникает масса вопросов, ответов на которые в документе нет, то требования надо переделать. После прочтения документа вопросов быть не должно! В документации должна содержаться предельно четкая и ясная информация о том, как должны работать все механики в игре и что необходимо сделать игроку, чтобы получить результат.
В требованиях написано: «В поле ˮUsernameˮ могут использоваться буквы, цифры и некоторые специальные знаки». Разработчик вынужден был уточнять, о каких буквах (латинские, кириллические), каких цифрах (римские, арабские, целые) и каких символах (@#$%) шла речь в техническом задании. После реализации функционала очередь уточнять пришла для тестировщика, потому что он не мог понять, какими критериями руководствоваться при проверке.
Далее проводится углубленное исследование требований.