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

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

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

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

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

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

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

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

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

В список включаются использованные учебники и справочные материалы по тестированию программного обеспечения, управлению качеством и автоматизации проверок. Для каждого источника необходимо указать автора или организацию, название, год публикации и адрес доступа, если материал размещён онлайн. Следует выбирать проверяемые источники и не выдавать общие сведения за внутреннюю документацию ВТБ.