Joint PC Testing Protocol: Template and Acceptance Rules

What problem joint testing solves

When one contractor supplies PCs and another (or the customer’s IT) configures and supports the profile software, the same discussion almost always appears: “it works for us”, “it doesn’t work for you”, “it was fine on our bench”. A joint PC testing protocol is used to end that dispute before acceptance starts.

The problem is rarely the bugs themselves and more often that the parties check different things. One side has a test Windows image, the other has domain policies. One has fresh drivers, the other has limited user rights. Without a common document, acceptance becomes a discussion without facts: what was considered normal, who tested what and how, and on which exact hardware set.

Joint testing removes typical risks: disputed defects (unclear whether the cause is the PC, a driver, the OS, security settings or the application), differing benches (“not reproducible” because environments don’t match), subjective acceptance (no measurable criteria) and failed rollouts (problems found after mass installation when fixes are costly).

A working protocol records the same rules for everyone in advance: environment (model, configuration, OS and driver versions, network conditions), acceptance criteria (what counts as success), test cases (what and how to run), defect reporting rules (how to confirm and whom to assign) and the final rule “rollout or not”.

This approach is especially useful where the cost of error is high and auditing is required: government, banks, education, healthcare, large offices. For them it’s important that acceptance be transparent and repeatable, whether you’re testing local PCs or, for example, workstations and servers in the same project.

Participants, roles and responsibilities in one document

To prevent the joint check from turning into an argument, agree on roles and responsibilities in advance and record them in the protocol. The same failure can be “hardware”, an OS setting, a driver, a security policy or an application bug. If you don’t define who does what, time will be spent on coordination.

Responsibility boundaries: who is responsible for what

It’s convenient to record four parties: the customer, the PC supplier, the integrator and the profile software vendor. In the protocol briefly state who:

• prepares test data and accounts, grants network access and security policies (customer)
• is responsible for kit composition, BIOS/firmware, drivers and component replacement for hardware defects (PC supplier)
• configures the OS, domain policies, integrations and compatibility settings (integrator)
• confirms software version, licensing and compatibility requirements and fixes application defects (software vendor)

Roles within the customer

List named contacts and responsibilities in one document: business owner (decides whether the solution “works enough”), IT (deployment and access), security (permissions, policies, exceptions), and key users (who validate real scenarios).

Set a synchronization rhythm in advance: for example, a short daily 10–15 minute status and a final call after the run. This makes closing blockers faster.

The outcome should clarify which artifacts are considered official: the final protocol, defect registry, and then an acceptance certificate or a reasoned rejection.

Also set a one-version rule: where the current document is stored (shared repository/folder) and who is the only person allowed to edit. Others should request changes by comments or tickets so there aren’t two “correct” protocols.

Environment section template: what to record

The Environment section ensures results can be reproduced. If performance degrades a week later, you open the protocol and see the hardware, settings and versions used for verification.

Start by identifying the computer: model and serial (or inventory) number, configuration (CPU, RAM, storage type and size, graphics), and ports and connected peripherals (monitor, scanner, ЕЦП token, printer). In office scenarios peripheral drivers are often the critical factor rather than raw PC power.

Then record the software base: OS version and build, language, installed updates, driver and firmware versions (BIOS/UEFI), important policies and settings (for example BitLocker, UAC, blocked software installs). If testing GSE workstations (for example, L200 or M200), note the factory image and any changes made after delivery.

Briefly describe network and restrictions: domain or workgroup, proxy, VPN, wired or Wi‑Fi, filtering and access limitations. This often explains differences between a test bench and a user’s workplace.

To avoid too many details, keep a “five-line environment”:

• Hardware and peripherals (model, configuration, connections)
• OS, drivers, firmware, policies and basic settings
• Network (domain, proxy/VPN, connection type, restrictions)
• Customer software (versions, modules, plugins, license, test data)
• Test tools (accounts, rights, logs, where to check logs)

At the end add the bench boundaries: what you simulate (for example, “poor network channel”) and what you can only honestly verify in production (for example, access to real integrations).

Acceptance criteria: how to make them measurable

So testing does not turn into a debate about “works or not”, acceptance criteria should be written as numbers and observable facts. Then the protocol becomes a checklist rather than an opinion.

How to formulate criteria

A good criterion answers three questions: what we check, how we measure it, and what threshold counts as pass. It’s useful to tie criteria to the profile software’s common tasks (what users do every day) rather than rare scenarios.

A working structure that covers main risks:

• Functionality: 5–10 key scenarios with expected outcomes (for example, “create a document, sign with ЕЦП, submit to the system, receive status”) without errors or manual workarounds.
• Performance: measurable times (app launch, opening a typical file, performing an operation) and acceptable CPU/RAM peaks. Specify tools and conditions for measurement.
• Stability: run period (for example, one work shift or N hours) and rule “0 critical crashes/hangs”. If noncritical failures are allowed, record the limit.
• Compatibility: specific peripherals and modes (printer/scanner, ЕЦП token, dual monitors, required fonts/layouts) with verification steps like printing/scanning/signing.
• Security and policies: which accounts are used, user rights, logging enabled, encryption requirements met, and the app does not request excessive privileges.

Add “non-acceptance” criteria so the decision is unambiguous:

• blocking defect in a key profile scenario
• repeatable application or OS crash
• inability to use ЕЦП or required peripherals
• violation of security requirements (excessive privileges, missing logs, forbidden settings)
• performance degradation beyond agreed threshold

Example formulation: “The PC is accepted if all key scenarios pass, there are no critical failures during the run period, peripherals work, and timing and load metrics do not exceed agreed thresholds.”

Test cases: a simple format that can actually be executed

Test cases should not be an 80‑page manual. Their job is to verify the profile software on the agreed configurations and produce repeatable results to attach to the protocol.

Take scenarios from real work: user guides, department regulations, typical support tickets, the most frequent daily operations. If there’s an incident queue, add the 3–5 most painful cases that have occurred.

A compact test case fits on half a page: purpose, steps, expected result, test data (login, role, example document), and priority (critical, important, desirable).

A minimal set that covers about 80% of risks:

• installation and updates (including required components and rights)
• launch and login under typical roles
• 2–3 main process operations (create, post, approve)
• printing or report generation (if used)
• export or data exchange (file, integration, export)

Add 2–3 negative cases to catch “silent” errors: login without required rights, unavailable network/resource, attempt to save invalid fields, operation without a connected printer. Example: an accountant logs in with “view” role, attempts to post a document and gets a clear error message rather than a hang.

After fixes, run regression: repeat all critical cases and those affected by the change. Maintain a coverage matrix: which functions were tested on which configurations (PC model, OS, software version, peripherals). It quickly shows coverage gaps.

Step-by-step order for a joint run

A joint run works when there is one clear route and the same rules for everyone. Below is an order that is easy to repeat for a single PC or a batch. It simplifies agreement and reduces dispute risk.

1) Bench preparation

Bring the machine to the agreed state: install the required OS edition and version, install drivers, apply domain policies and security settings. Immediately record what was done (versions, dates, who performed it) so the environment can be repeated exactly.

Then install the customer’s profile software using the agreed recipe: source of the distribution, keys, plugins, templates, accesses, network paths. If there are variants (different licensing modes or modules), choose one and record it as the baseline.

2) Run: from simple to critical

Before a full check perform a short smoke test: PC boots, user logs in, software starts and one key action chain completes. Example: open the database, create a document, save, print to PDF.

Then execute the main run by priority: critical scenarios first, then important, then secondary. For each test record execution time, conditions (account, network, connected devices) and actual result.

Practical rhythm:

1. Smoke test (10–20 minutes).
2. Critical test cases (until they pass or a blocker is identified).
3. Important test cases with timing and load observation.
4. Peripheral tests (scanner, token, printer) if part of the process.
5. Repeat key cases after fixes.

3) Collect artifacts and finalize

During the run collect evidence: screenshots, event logs, application logs, configuration files, and driver version details. Then summarize: how many cases passed, how many failed, which defects block acceptance and recommended actions (change a setting, update a driver, replace a component, clarify a procedure).

If testing PCs supplied via GSE.kz as manufacturer and integrator, agree in advance where logs are stored and who is responsible for a rerun. This resolves half of organizational delays.

Defect reporting: how to avoid “it’s not our fault” disputes

Disputes begin when a defect is described vaguely as “doesn’t work” without context. Agree on one defect reporting format and a rule: issues without a minimum set of data will not be accepted for work.

Unified defect template

Everyone (customer IT, software vendor and PC supplier) needs the same template. A minimum set:

• title (what breaks and where)
• reproduction steps (1–5 actions)
• actual and expected result
• environment (PC model, OS build, drivers, software versions)
• evidence (screenshot or video, plus logs if available)

Write the environment with specifics (OS build, update date and driver version). If testing workstations onsite, record where installation packages were stored and who performed installs.

Reproducibility, timelines and statuses

Agree how to verify defects. For example: a bug is confirmed if it reproduces 2 out of 3 times on the same bench and at least once on a second bench with the same OS image.

Set short response and rerun deadlines during the test (agree specific numbers per your process).

Limit statuses to a simple set:

• New
• Confirmed
• In progress
• Fixed (awaiting retest)
• Not reproducible or Rejected (with reason)

Also agree on the defect component: PC, driver, OS or profile software. This is not about finding fault but creating a quick route to the party that can fix it.

Rule “rollout or not”: formulations and thresholds

To avoid subjective debate, record the rollout decision in the protocol: which defects are acceptable, which block rollout, and what to do if the result is “almost acceptable”.

Defect thresholds (simple scale)

Record a regression rule: if a fix for one defect breaks a previously passed test case, the decision automatically returns to “no rollout” until affected checks are rerun.

Decision wording (how to write it in the document)

For “rollout” usually three conditions suffice: 0 Critical, 0 High, and all Medium/Low either closed or accepted by the customer with described impact. For “no rollout” state the reason, remediation plan and date for recheck: what will be fixed (software/driver/OS image/settings), who will fix it, on which bench it will be repeated and which test cases will be rerun.

Record compromises honestly: a temporary workaround (3–5 step instruction), restricted functionality (for example, “mode X disabled until patch”), or delaying rollout with a pilot group. The decision is typically signed by the profile software owner/business customer, the customer IT and the implementer (integrator or manufacturer). Attach the test-case results, defect journal, image/driver versions and a final matrix “risk/impact/workaround”.

Common mistakes and how to prevent them

The most common cause of failed acceptance is different benches. The customer may have one OS build, domain policies and security restrictions, while the supplier uses a “clean” system with other drivers and network conditions. The result: tests pass “for us” but fail “for you”. Fix: record the environment and forbid unrecorded changes during the run.

Second, lack of prepared test data and accounts. The tester starts the profile software but needs rights, a license, or access to network shares or a database. Time is spent on agreements rather than testing.

Another mistake is vague acceptance criteria like “works fast”. That almost guarantees a dispute. Better: set numbers — launch time, acceptable CPU load for typical operations, behavior over VPN.

Also confuse defects with incidents. Application bugs, server failures, unstable Wi‑Fi and incorrect domain policy should be recorded differently, otherwise parties will say “not our area”.

To lower risk, keep a short rule set:

• agree the reference bench (OS version, drivers, policies, network, peripherals) and freeze it during the test
• prepare test accounts and data with proper roles in advance
• tie acceptance criteria to metrics and scenarios, not impressions
• separate records: “PC/driver defect”, “software defect”, “infrastructure/access”
• any fix requires regression: repeat key test cases even if the change seems small

Organizational: the solution must have an owner. Tests can pass but “no one is ready to sign”. Assign a signer and a backup before starting.

Practical example: during workstation checks the complaint “interface is slow” turned out to be a domain policy that limited local cache access. Until that was separated from a PC defect, acceptance stalled.

Short checklists before start and before the final decision

Joint runs fail not because of complex bugs but because of small things: different versions, different expectations and different ways of recording results. Two short checklists keep everyone aligned.

Before the joint test

• environment described: PC model, OS and driver versions, domain policy, network parameters, antivirus, list of peripherals (printers, scanners, tokens)
• profile software installed identically: one package, one configuration, clear access rights
• acceptance criteria expressed as numbers: launch time, open file time, stability (no crashes), acceptable load
• test list reflects real user actions: 15–20 most frequent operations without exotic cases
• unified defect journal: where to create tickets, which logs/screenshots are needed, who confirms reproduction

Before the final rollout decision

• all defects have status and owner; no unresolved disputed items
• thresholds set: what blocks rollout, what can be accepted with restrictions, what goes to the fix plan
• regression performed: rechecked scenarios that could have broken after fixes
• pilot plan and responsible parties for deployment: who prepares the image, who trains users, who accepts support handover

If testing a batch of PCs (for example, GSE workstations) for a specific customer software set, these checklists save days of email and make the final decision transparent.

Example: accepting PCs for profile software in the customer office

Scenario: a company buys a batch of PCs for a department that uses profile software daily (accounting, reporting, ЕЦП signing). Before rollout they take 1–2 pilot PCs and run a joint test onsite with IT, security and a department representative. This may be a workstation from the GSE line (for example, L200) or another agreed model.

Record the environment so it can be repeated: OS and update versions, domain membership and policies, accounts and rights, crypto provider and ЕЦП certificates, drivers (video, chipset, printer, scanner), printer/scanner models, network shares, access to test and production databases (if allowed), and profile software versions and modules.

Example test-case set feasible in 30–60 minutes:

• domain login, launch profile software, login under a work account (record startup time)
• search a record/client by several fields, check filters and sorting
• generate a period report and compare output to a reference
• print a document to a network printer and check fonts/fields
• sign a document with ЕЦП and verify signature status

Often add export to PDF/Excel and scanning with file attachment to a record.

Three typical defects and how to identify the responsible party: (1) token not detected or signature error — usually security/crypto provider and ЕЦП settings; (2) wrong print or scanner behavior — drivers and print service, usually IT or equipment supplier; (3) crash or incorrect report — owner of the profile software, may need a patch or database setting.

The final protocol usually ends with a defect table and a decision: “rollout” if Critical = 0 and High = 0, and medium issues have accepted workarounds and agreed fix deadlines. Next: refine the image, pilot on 5–10 workplaces, rerun key tests and hand over to support with responsible contacts.

What to do next: how to start without extra bureaucracy

Start with minimal inputs: which profile software is critical, who the real users are (accounting, engineers, call center), which peripherals are needed (scanners, tokens, printers), and network/security constraints (domains, proxy, USB bans, logging requirements).

Then assign owners for each block to avoid “nobody responds” stoppages:

• customer: who issues access (AD/VPN/accounts), who confirms security requirements, who signs the final decision
• IT partner/supplier: who installs OS and drivers, who installs profile software, who keeps the protocol and collects logs
• user representative: who runs test cases and confirms usability

Prepare the protocol template in advance and review it on a short 30‑minute kickoff call: agree software versions, where results are stored (one file/spreadsheet), response times and defect thresholds.

Don’t start a mass rollout immediately — run a pilot on a small group: 2–5 seats and one representative scenario. Example pilot: domain login, launch profile app, print, ЕЦП signing, simple load (browser, mail, video call in parallel). If the pilot passes, expand testing to typical roles and different departments.

If the project needs a single point of responsibility for hardware, integration and support, discuss this with GSE.kz: the company supplies workstations and servers, performs system integration and provides 24/7 national support. This format is useful where quick compatibility and bench repeatability are essential.