How to test an e-signature service
Direct answer
Shipped untested, an e-signature service lets a consumer sign before seeing the electronic records disclosure, so the e-signed notice fails the consumer consent rule, and lets a document edited after the first signer finishes keep that signature with no change recorded in the audit trail. 9 tests are mandatory here, each tied to a risk in the map below. After the release smoke check, start the risk tests with the regression suite: the certificate, consent and tamper cases must rerun on every release, and a missing certificate field or a passed tamper case blocks that release.
9 mandatory testsfirst: regression suite
What counts as an e-signature service
An e-signature service here sends documents for signing by link on web, iOS, Android and through an API, and issues a completion certificate and audit trail that give the signature legal validity. It counts when consumers or regulated customers sign through it. A document editor with a drawn-signature field and no audit trail is out of scope, and so is a contract management tool that only stores documents signed elsewhere.
Adjacent product types not covered here
- identity and access management service: An identity and access management service proves who is signing in to other apps, while an e-signature service must prove who signed a given document and that it did not change afterwards.
- email marketing platform: An email marketing platform sends bulk campaigns where consent records and inbox placement lead, while an e-signature service sends one envelope per signer whose link opens a binding contract.
- ERP system: An ERP system moves pay and supplier money through its own ledger, so pay rules and postings lead instead of consent disclosure and document tamper evidence.
Risk map
| Risk | Grade | Note | Evidence | |
|---|---|---|---|---|
| Accessibility complaint or lawsuit accessibility-liability | legal | primary | A blind signer cannot reach the signature and initial fields with a screen reader, or cannot review and correct entries before the legally binding submit. | |
| Fine or enforcement by a regulator regulatory-penalty | legal | primary | A consumer signs before seeing the electronic records disclosure, the paper-copy right and how to withdraw consent, so the e-signed notice fails the consumer consent rule; or, for records kept for the FDA, the audit trail and signature controls fall short of 21 CFR Part 11. | |
| Personal or sensitive data exposed data-breach | data | secondary by design analysis | A forwarded or guessed signing link opens a contract with salary, ID numbers and bank details without any check that the opener is the named signer. | |
| Records silently wrong data-corruption | data | primary | A document edited or a page swapped after the first signer finishes still carries that signature, and the audit trail does not record the change. |
Mandatory tests (9)
Step 1: release smoke tests
Why:regulatory-penaltydata-corruption
Done when: On every build, a two-signer test envelope completes, the test consumer signer sees the electronic records disclosure before the document opens, its certificate lists each signer's email, authentication method, IP address and timestamp, and the signed PDF shows a valid signature.
Tool class: browser automation. Who usually runs it: QA engineer.
Step 2: regression suite
Why:regulatory-penaltydata-corruption
Done when: The certificate, consent and tamper cases rerun on every release, and a missing certificate field or a passed tamper case blocks the release.
Tool class: test management. Who usually runs it: QA engineer.
Step 3: compliance checks
Why:regulatory-penaltydata-breach
Done when: Legal signs off the consent text, certificate fields and retention period against ESIGN and, for life-science customers, the 21 CFR Part 11 audit trail rules, and access to completed documents is limited to the named signers and the sender.
Tool class: test management. Who usually runs it: product manager.
Step 4: end-to-end functional tests
Done when: A first-time consumer signer sees the electronic records disclosure and gives consent before the document opens, and withdrawing consent switches that signer to paper.
Tool class: browser automation. Who usually runs it: QA engineer.
Step 5: accessibility testing
Done when: A screen-reader user and a keyboard-only user find every signature and initial field, review all entries and confirm before the final sign action.
Tool class: accessibility checker. Who usually runs it: accessibility specialist.
Step 6: unit tests
Why:data-corruption
Done when: In the test report, every unchanged sample document passes signature validation and every sample with a changed byte or page fails it.
Tool class: unit framework. Who usually runs it: developer.
Step 7: security scanning
Why:data-breach
Done when: The scan of the signing pages, document storage and API has no open high findings.
Tool class: DAST scanner. Who usually runs it: security specialist.
Step 8: penetration testing
Why:data-breach
Done when: A tester with a forwarded or edited signing link cannot open another signer's document, an access code or SMS check cannot be skipped by replaying the link.
Tool class: proxy. Who usually runs it: security specialist.
Step 9: data integrity and migration testing
Why:data-corruption
Done when: Editing a completed document makes signature validation fail, and editing a document mid-flow restarts signing for everyone who already signed.
Tool class: data validation. Who usually runs it: QA engineer.
Recommended and optional tests
integration testsrecommended
Becomes mandatory when the risk "Fraud or abuse by users" is attached to this product type with verified evidence (see the methodology).
contract testsrecommended
Becomes mandatory when customers' systems depend on envelope status callbacks.
usability testingrecommended
Becomes mandatory when signers dispute what they signed in a recorded case.
device and browser compatibilityrecommended
Becomes mandatory when a signature captured on one platform fails validation in a recorded case.
localization testingrecommended
Becomes mandatory when signers in a second language are supported.
exploratory testingoptional
Optional: finds envelope states that scripted cases miss.
performance and load testingoptional
Optional: helps when bulk send is sold, no outage-under-load evidence is attached.
Not needed and why
resilience and failure testing
Not needed: no dependency-failure evidence is attached for e-signature services. Becomes recommended when an email or SMS provider outage blocks signing in a recorded case.
analytics and event tracking tests
Not needed: no wrong-decisions risk is attached. Becomes recommended when envelope reports drive customer billing.
Order of work
First release
- release smoke tests: Complete a two-signer test envelope with a consumer signer, confirm the electronic records disclosure shows before the document opens, and check that the certificate lists each signer's email, authentication method, IP address and timestamp and the signed PDF shows a valid signature.
- regression suite: Rerun the certificate, consent and tamper cases and block the release on a missing certificate field or a passed tamper case.
- compliance checks: Have legal sign off the consent text, certificate fields and retention period against ESIGN and, for life-science customers, the FDA Part 11 audit trail rules, and confirm completed documents open only for the named signers and the sender.
- end-to-end functional tests: Sign as a first-time consumer, confirm the electronic records disclosure and consent come before the document opens, then withdraw consent and confirm that signer switches to paper.
- accessibility testing: Have a screen-reader user and a keyboard-only user find every signature and initial field, review all entries and confirm before the final sign action.
- unit tests: Validate the signature on each unchanged sample document and on each sample with a changed byte or page, and confirm the test report shows the unchanged ones pass and the changed ones fail.
- security scanning: Scan the signing pages, document storage and API and clear every open high finding.
- penetration testing: Have a tester open another signer's document with a forwarded or edited signing link, then replay the link to try to skip the access code or SMS check.
- data integrity and migration testing: Edit a completed document and confirm signature validation fails, then edit a document mid-flow and confirm signing restarts for everyone who already signed.
Ongoing cadence
- release smoke tests: On every build.
- regression suite: On every release that changes the signing flow.
- compliance checks: After each change to consent text, certificate fields or retention period.
- unit tests: On every build that changes signature validation or document hashing.
- accessibility testing: After each change to signature fields or the final sign step.
- penetration testing: When the signing link format or the access code and SMS checks change.
- contract tests: When customers' systems start depending on envelope status callbacks.
Tools
Listed alphabetically inside each test type, filtered to the tests above and to the platforms of e-signature service (web, api, ios, android). Not recommendations.
release smoke tests
- Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
- TestRailTest case and run management. webiosandroidapicommercial
- XrayTest management inside Jira. webiosandroidapicommercial
regression suite
- CypressBrowser-based end-to-end testing with a visual runner. webfreemium
- DeepEvalUnit-style evaluation for LLM applications. apiopen-source
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
- TestRailTest case and run management. webiosandroidapicommercial
- XrayTest management inside Jira. webiosandroidapicommercial
end-to-end functional tests
- AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
- ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
- BrowserStackCloud of real devices and browsers. webiosandroidcommercial
- CypressBrowser-based end-to-end testing with a visual runner. webfreemium
- DeepEvalUnit-style evaluation for LLM applications. apiopen-source
- DetoxGray-box end-to-end testing for React Native apps. iosandroidopen-source
- EspressoAndroid UI testing framework from Google. androidopen-source
- LambdaTestCloud browser and device grid. webiosandroidcommercial
- MaestroMobile UI flows written in YAML. iosandroidfreemium
- PercyVisual review of UI changes. webcommercial
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- PostmanAPI client with collections and scripted assertions. apifreemium
- PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
- SeleniumWebDriver-based browser automation. webopen-source
- XCTestApple's framework for unit and UI tests. iosopen-source
accessibility testing
- Accessibility ScannerGoogle's on-device accessibility checker for Android. androidopen-source
- axe-coreAccessibility rules engine for automated checks. webopen-source
- LighthouseAudits for accessibility and performance in Chrome. webopen-source
- Pa11yCommand-line accessibility testing. webopen-source
unit tests
- JestJavaScript test runner with mocking and snapshots. webapiopen-source
- JUnitTest framework for the JVM. apiandroidopen-source
- pytestTest framework for Python with fixtures and plugins. apiopen-source
- VitestTest runner for Vite-based JavaScript and TypeScript projects. webapiopen-source
- XCTestApple's framework for unit and UI tests. iosopen-source
security scanning
- Burp SuiteProxy and scanner for web application security testing. webapifreemium
- GarakProbing LLM applications for prompt injection and leakage. apiopen-source
- mitmproxyInteractive HTTPS proxy. iosandroidwebapiopen-source
- MobSFStatic and dynamic analysis for mobile binaries. iosandroidopen-source
- OWASP ZAPDynamic application security scanner. webapiopen-source
- SchemathesisProperty-based testing from OpenAPI and GraphQL schemas. apiopen-source
- SemgrepStatic analysis with custom rules. apiwebiosandroidfreemium
- SnykDependency and code vulnerability scanning. apiwebiosandroidfreemium
- TrivyScanner for containers, dependencies and configuration. apiopen-source
penetration testing
- Burp SuiteProxy and scanner for web application security testing. webapifreemium
data integrity and migration testing
- dbt testsTests on warehouse models inside dbt. apiopen-source
- Great ExpectationsData validation with declarative expectations. apiopen-source
integration tests
- Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
- JestJavaScript test runner with mocking and snapshots. webapiopen-source
- JUnitTest framework for the JVM. apiandroidopen-source
- PostmanAPI client with collections and scripted assertions. apifreemium
- pytestTest framework for Python with fixtures and plugins. apiopen-source
- VitestTest runner for Vite-based JavaScript and TypeScript projects. webapiopen-source
- XCTestApple's framework for unit and UI tests. iosopen-source
contract tests
- PactConsumer-driven contract testing with a broker. apiopen-source
- PostmanAPI client with collections and scripted assertions. apifreemium
- SchemathesisProperty-based testing from OpenAPI and GraphQL schemas. apiopen-source
device and browser compatibility
- AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
- ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
- BrowserStackCloud of real devices and browsers. webiosandroidcommercial
- Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
- LambdaTestCloud browser and device grid. webiosandroidcommercial
- PercyVisual review of UI changes. webcommercial
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
- SeleniumWebDriver-based browser automation. webopen-source
localization testing
- Lokalise QATranslation management with in-context review. webiosandroidcommercial
- Pseudolocalization (Android, iOS)Built-in pseudolocales to find truncation and hard-coded strings. iosandroidopen-source
What to send to the person who will test
Send the checklist and the brief below. The printable checklist for e-signature service has the same 9 items with checkboxes.
Download the checklistMarkdownCSVBrief (Markdown)
Acceptance criteria wording
A release of the e-signature service is accepted when a two-signer test envelope completes with a certificate listing each signer's email, authentication method, IP address and timestamp, and a first-time consumer sees the electronic records disclosure and consents before the document opens. Editing a completed document makes signature validation fail, and a forwarded or edited signing link does not open another signer's document.
Brief
# Test brief: e-signature service Product type: e-signature service. Document signing with audit trails and legal validity. Risk map and evidence: https://howtotestaproduct.com/how-to-test/e-signature/ Printable checklist: https://howtotestaproduct.com/checklists/e-signature/ Run these 9 mandatory tests in this order. A test is done only when its done condition is true on the build you will release. 1. release smoke tests (risks: regulatory-penalty, data-corruption). Tool class: browser automation. Usually run by: QA engineer. Done when: On every build, a two-signer test envelope completes, the test consumer signer sees the electronic records disclosure before the document opens, its certificate lists each signer's email, authentication method, IP address and timestamp, and the signed PDF shows a valid signature. 2. regression suite (risks: regulatory-penalty, data-corruption). Tool class: test management. Usually run by: QA engineer. Done when: The certificate, consent and tamper cases rerun on every release, and a missing certificate field or a passed tamper case blocks the release. 3. compliance checks (risks: regulatory-penalty, data-breach). Tool class: test management. Usually run by: product manager. Done when: Legal signs off the consent text, certificate fields and retention period against ESIGN and, for life-science customers, the 21 CFR Part 11 audit trail rules, and access to completed documents is limited to the named signers and the sender. 4. end-to-end functional tests (risks: regulatory-penalty). Tool class: browser automation. Usually run by: QA engineer. Done when: A first-time consumer signer sees the electronic records disclosure and gives consent before the document opens, and withdrawing consent switches that signer to paper. 5. accessibility testing (risks: accessibility-liability). Tool class: accessibility checker. Usually run by: accessibility specialist. Done when: A screen-reader user and a keyboard-only user find every signature and initial field, review all entries and confirm before the final sign action. 6. unit tests (risks: data-corruption). Tool class: unit framework. Usually run by: developer. Done when: In the test report, every unchanged sample document passes signature validation and every sample with a changed byte or page fails it. 7. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist. Done when: The scan of the signing pages, document storage and API has no open high findings. 8. penetration testing (risks: data-breach). Tool class: proxy. Usually run by: security specialist. Done when: A tester with a forwarded or edited signing link cannot open another signer's document, an access code or SMS check cannot be skipped by replaying the link. 9. data integrity and migration testing (risks: data-corruption). Tool class: data validation. Usually run by: QA engineer. Done when: Editing a completed document makes signature validation fail, and editing a document mid-flow restarts signing for everyone who already signed. Acceptance criteria wording: A release of the e-signature service is accepted when a two-signer test envelope completes with a certificate listing each signer's email, authentication method, IP address and timestamp, and a first-time consumer sees the electronic records disclosure and consents before the document opens. Editing a completed document makes signature validation fail, and a forwarded or edited signing link does not open another signer's document. Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file). Licence: CC BY 4.0.
For founders: what to forward and what to ask back. For product managers: turning this page into tickets.
Questions about testing an e-signature service
What testing does an e-signature service need?
9 tests are mandatory, starting with a two-signer smoke envelope on every build and the regression suite of certificate, consent and tamper cases. Each is tied to one of the 4 risks in the map: consumer consent failures, documents changed after signing, contracts opened from forwarded links, and fields a blind signer cannot reach. Integration, contract, usability, compatibility and localization tests are recommended, each with the event that makes it mandatory.
What is the minimum testing for an e-signature service at MVP stage?
The minimum is the 9 mandatory tests, because from the first release the service issues completion certificates, consumers sign through it and documents open from emailed links. Exploratory and performance testing are optional, and resilience and analytics tests that vendors often add are not needed until the conditions on the page change.
Which tests in a vendor test plan for an e-signature service are not needed?
Resilience testing is not needed while no dependency-failure evidence is attached, until an email or SMS provider outage blocks signing in a recorded case. Analytics tests are not needed while no wrong-decisions risk is attached, until envelope reports drive customer billing.
What does GDPR mean for testing an e-signature service?
The map cites the General Data Protection Regulation for the data breach risk, because a forwarded or guessed signing link can open a contract with salary, ID numbers and bank details. Penetration testing checks that such a link cannot open another signer's document, and security scanning covers the signing pages, document storage and API.
When is test automation worth it for an e-signature service?
Automation pays for checks that rerun on every build and release: the two-signer smoke envelope, the certificate, consent and tamper regression cases, and the unit tests that validate signatures on unchanged and changed sample documents. Legal sign-off on consent text and the screen-reader and keyboard-only runs stay with people.
Evidence
ev-0016standardprimary
Web Content Accessibility Guidelines (WCAG) 2.2, W3C
WCAG 2.2 is the W3C standard that accessibility law and procurement rules reference; level AA is the usual target.
published undated · verified 2026-10-07
ev-0038regulatorprimary
Section508.gov, U.S. General Services Administration
Section 508 requires US federal agencies to make the information and communication technology they develop, buy or use accessible.
published undated · verified 2026-10-07
ev-0033regulatorprimary
21 CFR Part 11: Electronic Records; Electronic Signatures, U.S. Electronic Code of Federal Regulations
Part 11 requires validation, audit trails and signature controls for electronic records submitted to or kept for the FDA.
published undated · verified 2026-10-07
ev-0225regulatorprimary
15 U.S.C. 7001: General rule of validity (ESIGN Act), U.S. Government Publishing Office
Statute text: before an electronic record replaces a paper notice to a consumer, the consumer must get a disclosure of hardware and software requirements, the right to a paper copy and the right to withdraw consent. Supports regulatory-penalty for e-signature services used in consumer transactions.
published undated · verified 2026-10-07
ev-0014standardprimary
OWASP Application Security Verification Standard (ASVS), OWASP Foundation
ASVS gives testable security requirements for web applications and services, grouped by verification level.
published undated · verified 2026-10-07
ev-0025regulatorprimary
Regulation (EU) 2016/679 (General Data Protection Regulation), EUR-Lex, European Union
The GDPR sets lawful basis, consent, data subject rights, security of processing (Article 32) and breach notification duties for anyone processing personal data of people in the EU.
published undated · verified 2026-10-07
Disclaimer
This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.