Протокол совместного тестирования ПК: шаблон и правила приемки

Что за проблему решает совместное тестирование

Когда ПК поставляет один подрядчик, а профильное ПО настраивает и поддерживает другой (или ИТ-служба заказчика), почти всегда всплывает одна и та же переписка: «у нас работает», «у вас не работает», «на нашем стенде все было нормально». Протокол совместного тестирования ПК нужен, чтобы закрыть этот спор еще до старта приемки.

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

Совместное тестирование снимает типовые риски: спорные дефекты (неясно, где причина - ПК, драйвер, ОС, настройки безопасности или приложение), разные стенды («не воспроизводится», потому что окружение не совпадает), субъективная приемка (нет измеримых критериев) и срыв тиража (проблему находят после массовой установки, когда исправления дороже).

В рабочем протоколе заранее фиксируют одинаковые правила для всех: окружение (модель, конфигурация, версии ОС и драйверов, сетевые условия), критерии приемки (что считается успехом), тест-кейсы (что и как запускаем), правила фиксации дефектов (как подтверждаем и кому назначаем) и итоговое правило «пускать в тираж или нет».

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

Участники, роли и ответственность в одном документе

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

Границы ответственности: кто отвечает за что

Удобно зафиксировать четыре стороны: заказчик, поставщик ПК, интегратор и вендор профильного ПО. В протоколе достаточно коротко описать, кто:

• готовит тестовые данные и учетные записи, дает доступ к сети и политике ИБ (заказчик)
• отвечает за комплектацию, BIOS/прошивки, драйверы и замену компонентов при аппаратном дефекте (поставщик ПК)
• настраивает ОС, доменные политики, интеграции, параметры совместимости (интегратор)
• подтверждает требования к версиям ПО, лицензиям и совместимости, исправляет дефекты приложения (вендор ПО)

Роли внутри заказчика

В одном документе укажите ответственных по именам и контактам: владелец бизнеса (принимает решение, «достаточно ли работает»), ИТ (развертывание и доступы), служба ИБ (разрешения, политики, исключения), ключевые пользователи (проверяют реальные сценарии).

Заранее задайте ритм синхронизаций: например, короткий ежедневный статус на 10-15 минут и итоговый созвон после прогона. Так проще быстро закрывать блокеры.

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

И обязательно правило одной версии: где лежит актуальный документ (общий репозиторий/папка) и кто единственный имеет право править. Остальные вносят изменения через комментарии или заявки, чтобы не возникло двух «правильных» протоколов.

Шаблон раздела «Окружение»: что фиксировать

Раздел «Окружение» нужен, чтобы результаты можно было повторить. Если через неделю «что-то стало тормозить», вы открываете протокол и видите, на каком железе, с какими настройками и версиями это проверяли.

Начните с идентификации компьютера: модель и серийный номер (или инвентарный), конфигурация (процессор, объем RAM, тип и объем накопителя, графика), а также порты и подключенная периферия (монитор, сканер, токен, принтер). В офисных сценариях часто критичны именно драйверы периферии, а не «мощность» ПК.

Дальше зафиксируйте программную базу: версия ОС и сборка, язык, установленные обновления, версии драйверов, прошивки (BIOS/UEFI), важные политики и настройки (например, BitLocker, контроль учетных записей, запрет установки софта). Если тест идет на рабочих станциях GSE (например, L200 или M200), отдельно отметьте заводской образ и то, что было изменено после поставки.

Коротко опишите сеть и ограничения: домен или рабочая группа, прокси, VPN, Wi-Fi или провод, фильтрация, ограничения по правам и доступам. Это часто объясняет различия между тестовым стендом и рабочим местом пользователя.

Чтобы не расползаться в деталях, удобно держать «пять строк окружения»:

• Железо и периферия (модель, конфигурация, подключения)
• ОС, драйверы, прошивки, политики и базовые настройки
• Сеть (домен, прокси/VPN, тип подключения, ограничения)
• ПО заказчика (версии, модули, плагины, лицензия, тестовые данные)
• Средства теста (учетные записи, права, журналы, где смотреть логи)

В конце добавьте границы стенда: что вы имитируете (например, «плохой канал») и что сможете честно проверить только в продуктиве (например, доступ к реальным интеграциям).

Критерии приемки: как сделать их измеримыми

Чтобы тестирование не превратилось в спор «нормально работает или нет», критерии приемки нужно записать цифрами и наблюдаемыми фактами. Тогда протокол становится не мнением, а проверкой по понятным точкам.

Как формулировать критерии

Хороший критерий отвечает на три вопроса: что проверяем, как измеряем, какой порог считаем «проходит». Удобно привязывать критерии к типовым задачам профильного ПО (тем, что делают каждый день), а не к редким сценариям.

Рабочая структура, которая обычно закрывает основные риски:

• Функциональность: 5-10 ключевых сценариев с ожидаемым результатом (например, «создать документ, подписать ЭЦП, отправить в систему, получить статус») без ошибок и ручных обходов.
• Производительность: измеряемые времена (запуск приложения, открытие типового файла, выполнение операции) и допустимые пики CPU/RAM. Важно указать, чем и в каких условиях меряете.
• Стабильность: период прогона (например, 1 рабочая смена или N часов) и правило «0 критических падений/зависаний». Если допускаете некритичные сбои, запишите предел.
• Совместимость: конкретная периферия и режимы (принтер/сканер, токен ЭЦП, два монитора, нужные шрифты/раскладки) с подтверждением фактом печати/сканирования/подписи.
• ИБ и политики: какие учетные записи используются, какие права у пользователя, включено ли журналирование, соблюдены ли требования по шифрованию, не запрашивает ли ПО лишние привилегии.

Добавьте «критерии недопуска», чтобы решение было однозначным:

• блокирующий дефект в ключевом сценарии профильного ПО
• повторяемое падение приложения или ОС
• невозможность работы с ЭЦП или обязательной периферией
• нарушение требований ИБ (лишние права, нет журналов, запретные настройки)
• деградация производительности ниже согласованного порога

Пример формулировки: «ПК принимается, если все ключевые сценарии выполнены, критических сбоев нет за период прогона, периферия работает, а метрики времени и нагрузки не превышают согласованные пороги».

Тест-кейсы: простой формат, который реально исполнять

Тест-кейсы не должны быть «книжкой на 80 страниц». Их задача - одинаково проверить профильное ПО на согласованных конфигурациях и получить повторяемый результат, который можно приложить к протоколу.

Сценарии лучше брать из реальной работы: пользовательские инструкции, регламенты отдела, типовые заявки в поддержку, самые частые операции за день. Если есть очередь инцидентов, добавьте 3-5 самых болезненных кейсов, которые уже случались.

Удобный формат одного тест-кейса укладывается в полстраницы: цель, шаги, ожидаемый результат, тестовые данные (логин, роль, пример документа), приоритет (критично, важно, желательно).

Минимальный набор, который часто закрывает 80% рисков:

• установка и обновление (включая требуемые компоненты и права)
• запуск и вход под типовыми ролями
• 2-3 основные операции по процессу (создать, провести, согласовать)
• печать или формирование отчета (если используется)
• экспорт или обмен данными (файл, интеграция, выгрузка)

Добавьте 2-3 негативных кейса, чтобы поймать «тихие» ошибки: вход без нужных прав, недоступная сеть/ресурс, попытка сохранить некорректные поля, работа без подключения к принтеру. Например: бухгалтер входит под ролью «просмотр», пробует провести документ и получает понятное сообщение, а не зависание.

После исправлений нужен регресс: повторяем все критичные кейсы и те, что затрагивает правка. Чтобы не потеряться, ведите матрицу покрытия: какие функции проверены на каких конфигурациях (модель ПК, ОС, версия ПО, периферия). Она быстро показывает «белые пятна».

Пошаговый порядок проведения совместного прогона

Совместный прогон работает, когда у него есть один понятный маршрут и одинаковые правила для всех. Ниже порядок, который удобно повторять и на одном ПК, и на партии. Он упрощает согласование и снижает риск споров.

1) Подготовка стенда

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

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

2) Прогон: от простого к важному

Перед полноценной проверкой сделайте короткий дымовой тест: ПК загружается, пользователь входит в систему, ПО запускается и проходит одна ключевая цепочка действий. Например: открыть базу, создать документ, сохранить, распечатать в PDF.

Затем выполняют основной прогон по приоритетам: сначала критичные сценарии, потом важные, затем второстепенные. Для каждого теста фиксируют время выполнения, условия (учетная запись, сеть, подключенные устройства) и фактический результат.

Практичный ритм:

1. Дымовой тест (10-20 минут).
2. Критичные тест-кейсы (пока не пройдут или не станет понятен блокер).
3. Важные тест-кейсы с замером времени и наблюдением за нагрузкой.
4. Тесты с периферией (сканер, токен, принтер), если это часть процесса.
5. Повтор ключевых кейсов после исправлений.

3) Сбор артефактов и итог

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

Если тест идет на ПК, поставленных через GSE.kz как производителя и интегратора, заранее договоритесь, где хранятся логи и кто отвечает за повторный прогон. Это снимает половину организационных задержек.

Фиксация багов: как избежать споров «это не у нас»

Споры начинаются, когда дефект описан словами вроде «не работает» и без контекста. Поэтому закрепите один формат записи дефекта и правило: без минимального набора данных баг не принимается в работу.

Единый шаблон записи дефекта

Один и тот же шаблон нужен всем: ИТ заказчика, вендору ПО и поставщику ПК. Достаточно такого минимума:

• заголовок (что ломается и где)
• шаги воспроизведения (1-5 действий)
• фактический результат и ожидаемый результат
• окружение (модель ПК, ОС и сборка, драйверы, версии ПО)
• доказательства (скриншот или видео, плюс логи при наличии)

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

Воспроизведение, сроки и статусы

Чтобы не было «у нас повторяется, у вас нет», заранее договоритесь о проверке. Например: баг считается подтвержденным, если воспроизводится 2 раза из 3 на том же стенде и хотя бы 1 раз на втором стенде с тем же образом ОС.

На время теста задайте короткие сроки реакции и повторного прогона после исправления (конкретные числа согласуйте под ваш процесс).

Статусы ограничьте простым набором:

• Новый
• Подтвержден
• В работе
• Исправлен (ждет ретеста)
• Не воспроизводится или Отклонен (с причиной)

Отдельно договоритесь о «компоненте» дефекта: ПК, драйвер, ОС, профильное ПО. Это не поиск виноватого, а быстрый маршрут к тому, кто может исправить.

Правило «пускать в тираж или нет»: формулировки и пороги

Чтобы не спорить «на глаз», правило выпуска в тираж фиксируют прямо в протоколе: какие дефекты допустимы, какие блокируют, и что делать, если результат «почти подходит».

Пороги по дефектам (простая шкала)

Отдельно запишите правило по регрессии: если исправление одного дефекта ломает уже пройденный тест-кейс, решение автоматически возвращается в «не в тираж» до повторного прогона затронутых проверок.

Формулировки решений (как писать в документе)

Для «в тираж» обычно достаточно трех условий: 0 Critical, 0 High, а все Medium/Low либо закрыты, либо приняты заказчиком с описанным влиянием.

Для «не в тираж» указывают причину, план действий и дату повторной проверки: что правим (ПО/драйвер/образ ОС/настройки BIOS), кто делает, на каком стенде повторяем, какие тест-кейсы прогоняем заново.

Компромиссы тоже оформляйте честно: временный обходной путь (инструкция на 3-5 шагов), ограничение функционала (например, «без режима X до патча») или отсрочка тиража с пилотом на небольшой группе пользователей.

Решение обычно подписывают владелец профильного ПО/бизнес-заказчик, ИТ со стороны заказчика и исполнитель (например, интегратор или производитель). В приложениях держите: список тест-кейсов с результатами, журнал дефектов, версии образов/драйверов и итоговую матрицу «риск/влияние/обходной путь».

Частые ошибки и как их предотвратить

Самая частая причина срывов приемки - когда у сторон разные стенды. У заказчика одна сборка ОС, доменные политики и ограничения безопасности, а у поставщика - «чистая» система с другими драйверами и сетевыми условиями. В результате тест проходит «у нас», но падает «у вас». Решение простое: зафиксировать окружение в протоколе и запретить «тихие» изменения во время прогона.

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

Еще одна ошибка - расплывчатые критерии приемки. Формулировки вроде «работает быстро» почти гарантируют спор. Лучше задавать условия и цифры: время запуска, допустимая загрузка CPU в типовой операции, требования к шуму/нагреву, поведение при работе через VPN.

Отдельно путают дефекты и инциденты. Баг в приложении, сбой сервера, нестабильный Wi-Fi и неверная политика домена должны фиксироваться по-разному, иначе начинается «это не наша зона».

Чтобы снизить риск, держите перед глазами короткий набор правил:

• согласуйте «эталон» стенда (версия ОС, драйверы, политики, сеть, периферия) и заморозьте его на время теста
• подготовьте тестовые учетные записи с нужными ролями и тестовые данные заранее
• привяжите критерии приемки к метрикам и сценариям, а не к ощущениям
• разделяйте записи: «дефект ПК/драйвера», «дефект ПО», «инфраструктура/доступы»
• любое исправление закрывается регрессией: повторите ключевые тест-кейсы, даже если правка кажется маленькой

И организационное: у решения должен быть владелец. Бывает, что тесты прошли, но «никто не готов подписать». Назначьте подписанта и резервного подписанта до старта.

Пример из практики: при проверке рабочих станций под профильное ПО в офисе заказчика выяснилось, что жалоба «тормозит интерфейс» была вызвана доменной политикой, ограничившей доступ к локальному кешу. Пока это не отделили от дефекта ПК, приемка стояла на месте.

Короткий чек-лист перед началом и перед финальным решением

Совместный прогон чаще разваливается не из-за «сложных багов», а из-за мелочей: разные версии, разные ожидания и разные способы фиксировать результат. Два коротких чек-листа помогают держать всех в одном поле.

Перед началом совместного теста

• описано окружение: модель ПК, версия ОС и драйверов, доменная политика, параметры сети, антивирус, список периферии (принтеры, сканеры, токены)
• профильное ПО ставится одинаково: один пакет, одна конфигурация, понятные права доступа
• критерии приемки сформулированы числами: время запуска, время открытия типового файла, стабильность (без падений), допустимая нагрузка
• список тестов отражает реальные действия пользователей: 15-20 самых частых операций без экзотики
• есть единый журнал дефектов: где заводим, какие логи/скриншоты нужны, кто подтверждает воспроизведение

Перед финальным решением «в тираж или нет»

• все дефекты имеют статус и владельца, нет «зависших» спорных пунктов
• задан порог: что блокирует, что можно принять с ограничениями, что уходит в план исправлений
• проведен регресс: перепроверены сценарии, которые могли сломаться после исправлений
• есть план пилота и ответственные за ввод: кто готовит образ, кто обучает, кто принимает на поддержку

Если тестируете партию ПК (например, рабочие станции GSE) под конкретный набор ПО заказчика, эти чек-листы экономят дни переписок и делают итоговое решение прозрачным.

Пример: приемка ПК под профильное ПО в офисе заказчика

Сценарий: компания закупает партию ПК для отдела, где каждый день работают в профильном ПО (учет, отчеты, подписание документов ЭЦП). Перед тиражированием берут 1-2 пилотных ПК и проводят совместный прогон в офисе заказчика вместе с ИТ, безопасностью и представителем подразделения. Это может быть рабочая станция из линейки GSE (например, L200) или другой согласованный вариант.

Окружение фиксируют так, чтобы его можно было повторить: версия ОС и обновлений, членство в домене и политики, учетные записи и права, криптопровайдер и сертификаты ЭЦП, драйверы (видео, чипсет, принтер, сканер), модели принтера/сканера, сетевые папки, доступ к тестовой базе и к боевой (если разрешено), версии профильного ПО и модулей.

Пример набора тест-кейсов, который реально выполнить за 30-60 минут:

• вход в домен, запуск профильного ПО, вход под рабочей учеткой (время старта фиксируется)
• поиск записи/клиента по нескольким полям, проверка фильтров и сортировки
• формирование отчета за период и сравнение результата с эталоном
• печать документа на сетевой принтер и проверка корректности шрифтов/полей
• подписание документа ЭЦП и проверка статуса подписи

Часто добавляют экспорт в PDF/Excel и сканирование с привязкой файла в карточку.

Три типовых дефекта и как понять, кто исправляет: (1) не виден токен или ошибка подписи - чаще зона ИБ/криптопровайдера и настроек ЭЦП; (2) «криво» печатает или не сканирует - драйверы и служба печати, обычно ИТ или поставщик оборудования; (3) падение или неверный отчет - владелец профильного ПО, иногда нужен патч или настройка базы.

Итоговый протокол обычно заканчивается таблицей дефектов и решением: «пускать в тираж», если критических дефектов 0, а средние имеют обходной путь и сроки исправления согласованы. Дальше - донастройка образа, пилот на 5-10 рабочих местах, повторный прогон ключевых тестов и передача в поддержку с контактами ответственных.

Что делать дальше: как запустить процесс без лишней бюрократии

Начните с минимального набора вводных: какое профильное ПО критично, кто реальные пользователи (бухгалтерия, инженеры, колл-центр), какая периферия нужна (сканеры, токены, принтеры), и что диктует сеть и ИБ (домены, прокси, запреты на USB, требования к журналированию).

Дальше зафиксируйте владельцев по каждому блоку. Это снижает риск, что тест остановится из-за ситуации «никто не отвечает»:

• заказчик: кто выдает доступы (AD/VPN/учетки), кто подтверждает требования ИБ, кто принимает итоговое решение
• ИТ-партнер/поставщик: кто ставит ОС и драйверы, кто устанавливает профильное ПО, кто ведет протокол и собирает логи
• представитель пользователей: кто выполняет тест-кейсы и подтверждает удобство работы

Шаблон протокола подготовьте заранее и проверьте на коротком стартовом созвоне на 30 минут: договоритесь о версии ПО, где хранятся результаты (один файл/таблица), как быстро отвечают на вопросы и какой порог по дефектам считается «проходим».

Запускайте не сразу тираж, а пилот на небольшой группе: 2-5 рабочих мест и один типовой сценарий. Например, для офиса: вход в домен, запуск профильной программы, печать, работа с ЭЦП, простая нагрузка (параллельно браузер, почта, видеозвонок). Если пилот прошел, расширяйте проверку на типовые роли и разные отделы.

Если проекту нужна «одна точка ответственности» за железо, интеграцию и поддержку, это имеет смысл обсудить с GSE.kz: компания поставляет рабочие станции и серверы, выполняет системную интеграцию и обеспечивает круглосуточную техническую поддержку по стране. Такой формат особенно полезен там, где важно быстро закрывать вопросы совместимости и повторяемости стенда.