Local government units (LGUs) should record digital signing route test results in one controlled register before a workflow goes live. Each entry should identify the test, compare the expected route with the actual route, state whether every required control worked, record defects and corrections, and show the retest decision. This evidence helps an LGU decide whether its digital signing process for government approvals is ready for controlled use.
A passed screen or a successful signature does not prove that the whole route worked. A test might reach the final signer after skipping a reviewer, accepting an unauthorized account, using the wrong document version, or failing to preserve the event record. The result register must reveal those failures before live documents enter the route.
What Should Digital Signing Route Test Results Prove?
The record should prove whether the configured workflow behaved as the LGU expected under a defined test condition. It should show the route tested, the document version used, the participating test accounts, the expected events, the observed events, and the final result.
This record serves a narrow purpose. It does not establish who holds legal signing authority, replace an office order, or approve a new procedure. The LGU must settle those matters before testing. The register then shows whether the configured system followed the approved setup.
A useful result answers four decision questions:
- Did the document reach every required stage in the intended order?
- Did each test account perform only the action assigned to its role?
- Did the workflow preserve the correct document and event history?
- Did the route handle rejection, return, delay, and access failure as designed?
What Must Be Ready Before the First Test?
Pre-go-live workflow testing needs an approved baseline. The test team needs a route specification, the applicable procedure or Citizen's Charter entry, the authorized-role list, the document version, and the acceptance criteria. Without a baseline, staff will record activity without knowing whether the outcome passed. Pre-go-live workflow testing should pause when any baseline item lacks local approval.
Republic Act No. 11032 requires LGUs to publish service procedures, responsible persons, processing periods, and other service standards in the Citizen's Charter. It also permits electronic signatures for covered documents when adequate security and control mechanisms exist. These provisions support a disciplined baseline, but they do not supply a route-test format.
Teams moving from paper should also review the existing route evidence before configuring test cases. A prior guide on how to measure waiting time in paper signature routes helps separate route design from timing problems. The new test should focus on configured behavior, not use a slow paper step as proof that the digital sequence is wrong.
Which Details Belong in the Results Register?
A route test register works best when its details are grouped by decision purpose. This layout keeps staff from mixing test setup, execution evidence, and defect closure in one long note.
Test identity and expected outcome
Record a unique test case ID, workflow name, route version, test date, environment, document type, and scenario. Add the expected stages and acceptance rule. The scenario should describe one condition, such as normal approval, returned document, unavailable signer, or unauthorized access attempt.
Observed route and evidence
Record the actual sequence, status changes, timestamps, test-account roles, document version, and system event references. State where the observed route differed from the expected route. Keep passwords, private keys, full identity documents, and unnecessary personal data outside the register.
Defect and closure decision
If the case fails, record a defect ID, impact level, assigned correction owner, affected configuration version, correction date, and retest case. The entry should end with a result such as passed, failed, blocked, or accepted with a documented limitation. Avoid vague labels such as done or checked.
How Should an LGU Run Each Route Test?
An LGU approval workflow test should follow the same execution order for every scenario. A stable method makes results comparable and reduces arguments about what staff tested.
- Freeze the test basis. Record the route version, user-role setup, document template, and acceptance rule before execution.
- Prepare a safe test document. Use synthetic or properly de-identified values when the route does not require live personal data.
- Start from the intended entry point. Do not insert a document midway through the route unless the test case specifically covers recovery or migration.
- Observe each system event. Compare the actual recipient, permitted action, status, version, and event time with the expected result.
- Record the first divergence. Stop treating the case as a normal pass after a required step fails, even if the document later reaches a signer.
- Close through retesting. Link the correction to a new execution record and preserve both the failed and passed results.
Digital signature route validation should use repeatable test data and named acceptance rules.
The team should repeat digital signature route validation when a configuration change affects a required stage, permission, document state, or exception path.
Which Negative Tests Expose Skipped or Unsafe Steps?
Normal-route success covers only one condition. Skipped approval step testing checks whether the system rejects actions that should never succeed.
Test an unauthorized direct submission to the final signer. Try an out-of-order approval. Attempt to sign with a test account assigned to a reviewer role. Return the document for correction, then confirm that the earlier version does not continue toward approval. Submit a duplicate request and observe whether the system creates two active routes. Remove a required test account and confirm that the document moves to the approved exception path rather than bypassing the stage.
Republic Act No. 8792 supports electronic-signature verification and government controls for integrity, security, and confidentiality. Route tests should examine identity, permission, sequence, document integrity, and verifiable events together.
How Should LGUs Test Access Without Exposing Personal Data?
Start each privacy-sensitive test with the smallest dataset needed for the scenario. Replace resident names, addresses, identification values, attachments, and signatures with controlled test values unless an approved test requires representative data. Store the evidence where only the test and review teams have access.
NPC Circular No. 2016-01 directs government agencies to assess privacy risks and apply organizational, physical, and technical controls. The route test should therefore check who viewed the document, who changed the status, what content appeared in notifications, and whether exported evidence exposed more information than the result decision needed.
Access testing should reflect staff movement and role changes. The guide on digital signing access review after staff transfers addresses the longer access lifecycle.
How Should Failed Cases Move Through Correction and Retesting?
Workflow defect retesting begins with the failed test case, not with a fresh informal demonstration. The defect record should identify the first incorrect event, its effect on the document, the corrected configuration, and the exact scenario to run again.
Do not erase or overwrite the failed result. The failure explains why a change occurred and gives the retester a defined target. Workflow defect retesting should link the new execution to the original defect ID. If a correction affects other routes or document types, add regression cases before closing the defect.
A defect stays open when the corrected route works only for one privileged tester, loses the earlier document history, changes the signer sequence, or produces incomplete event data. A green status on the final screen does not cancel those conditions.
What Does a Practical LGU Test Case Look Like?
Consider a business permit renewal recommendation routed from a processor to a reviewer and then to an authorized signer. The expected route requires review before signature. The LGU uses test accounts and a document containing non-live applicant details.
The first execution reaches the signer directly after the processor submits the document. The signer does not sign it. The tester records a failed result, identifies the skipped review stage, links the system event, and assigns the configuration defect. The correction restores the required review gate.
The retest starts with a new controlled document. It passes through the processor, reaches the reviewer, returns once for correction, preserves the corrected version, and then reaches the signer. The digital signing route test results link the failed case, the correction, and the passed retest. The record proves configured behavior under the tested conditions. It does not certify the whole system or replace formal acceptance.
This LGU approval workflow test also checks whether the returned document preserves the correct version before final signature.
Who Should Accept the Results Before Go-Live?
The LGU should name acceptance participants through its governance process. The decision needs service, technical, records, privacy, and security input based on the route and data involved. Test acceptance should not create a new approval chain.
Acceptance should identify the tested route version, passed cases, open defects, approved limitations, unresolved risks, and go-live decision. Republic Act No. 12254 supports accountable digital-government implementation, information security, privacy controls, and periodic testing of security controls. It does not turn a test sign-off into legal authority for a signer.
Before launch, confirm that the same configured version tested is the version scheduled for release. If staff change the route, user roles, notification rules, document template, or signature control after acceptance, assess the effect and rerun the affected cases.
What Should the LGU Do With the Final Test Package?
Keep the approved route basis, test cases, execution evidence, defect records, retest results, and acceptance decision under the LGU's records rules. Limit access according to the sensitivity of the documents, account details, and system evidence. Preserve enough context for a later reviewer to understand what was tested and which version passed.
Well-kept digital signing route test results give leaders a direct go-live choice: release the tested version, delay release for unresolved defects, or limit the initial scope. LGUs reviewing connected approval controls for a specific document route may request a GoLGU demo and bring the approved procedure, one failed test case, and the intended acceptance rule.
Frequently Asked Questions
Does a successful digital signature mean the whole route passed?
No. The signature proves one event. The route still fails when a required review was skipped, the wrong document version reached the signer, an unauthorized account acted, or the event history was incomplete.
Should every LGU document use the same route-test cases?
No. Each document route needs cases based on its approved procedure, roles, data sensitivity, exceptions, and acceptance criteria. LGUs should reuse the execution method while adjusting the scenarios to the route.
What is the difference between a test case and a defect record?
A test case states the condition, steps, and expected outcome. A defect record explains a failure, its impact, the correction, and the retest needed for closure.
Should screenshots serve as the main test evidence?
Screenshots support selected observations, but they often miss sequence, identity, timestamps, document history, and system events. Use them with the controlled result entry and available event references.
When should an LGU repeat skipped approval step testing?
Repeat it after changes to route rules, user roles, document states, approval gates, exception handling, or deployment configuration. Also rerun affected cases after a defect correction.
Does a digital signing test record replace a formal audit or legal review?
No. The digital signing test record documents tested behavior. Digital signing route test results do not replace an audit, legal opinion, office authority, records decision, privacy assessment, security assessment, or formal system acceptance required by the LGU.
References
- Republic Act No. 11032, Ease of Doing Business and Efficient Government Service Delivery Act of 2018
- Republic Act No. 8792, Electronic Commerce Act of 2000
- NPC Circular No. 2016-01, Security of Personal Data in Government Agencies
- Republic Act No. 12254, E-Governance Act
Disclaimer
This guide provides general operational information for Philippine LGUs. Each LGU should apply current laws, official issuances, local authority rules, records policies, privacy requirements, security standards, and legal advice relevant to its document routes.
Sign in to leave a comment.