Сначала определите, что именно нужно проверить

Для исследования программы недостаточно папки с названием «финальная версия». Необходимо связать проверяемый результат с требованиями, условиями запуска и происхождением файлов. Полезный первый документ — короткая записка: какая функция вызывает вопрос, когда наблюдалась проблема и какой результат ожидался. Формулировка «расчёт скидки отличается от согласованного примера» предметнее, чем «программа сделана некачественно».

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

Соберите три связанные части

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

Вторая часть — исходные материалы: код, файлы проекта, зафиксированные зависимости, настройки сборки и инструкция запуска. Например, документация Microsoft показывает, что сборка .NET использует проект и зависимости, а результат может включать несколько типов файлов. Поэтому один исполняемый файл и один файл с исходным кодом не всегда образуют достаточный комплект. Microsoft: dotnet build.

Если передаётся Git-репозиторий, отдельно уточните охват истории. Архив bundle предназначен для объектов и ссылок Git, но не сохраняет всё локальное состояние рабочей папки. Незакоммиченные изменения и дополнительные материалы нужно учитывать отдельно. Git: git-bundle.

Третья часть — основания проверки: техническое задание, согласованные изменения, тестовые примеры, протоколы сдачи и сообщения о недостатках. Для каждого спорного требования полезно указать документ и конкретный пункт. Не смешивайте действовавшие условия с предложениями, которые обсуждались, но не были согласованы.

Чек-лист передачи

  • Назовите проверяемую функцию и ожидаемый результат, приложите конкретный входной пример.
  • Перечислите файлы, каталоги, версии компонентов и объём каждого передаваемого объекта.
  • Укажите, откуда получена копия, кто её подготовил и когда выполнялось копирование.
  • Приложите требования и историю их изменения с понятной последовательностью.
  • Опишите операционную систему, базу данных, зависимости, настройки и используемые интеграции.
  • Сохраните журналы за нужный период вместе с часовым поясом и описанием источника.
  • Отметьте отсутствующие исходники, внешние сервисы и другие ограничения комплекта.
  • Согласуйте отдельный безопасный канал для необходимых доступов; не помещайте пароли в общую опись.

Условный пример: ошибка расчёта доставки

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

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

Как подготовить копию и не потерять контекст

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

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