Quality Assurance Measures, Documentation Types

This article is a conceptual explanation of documentation as a QA tool – including exam questions and tags.

In a Nutshell

Documentation makes requirements, behavior, and evidence verifiable. Core artifacts: User documentation, Interface documentation, Program documentation, Network documentation, Test protocols, and Checklists – all with clear objectives, structure, responsibility, and maintenance processes.

Compact Technical Description

User Documentation

Addresses users/operations: tasks, step sequences, error scenarios, support channels. Goal: self-help, reduced support burden.

Interface Documentation

Defines contracts: endpoints, data schemas, error codes, authentication, versioning. Foundation for interoperability and contract tests.

Program Documentation

Focuses on maintainable implementation: architecture overview, modules, public interfaces, invariants, code comments, build/runbook.

Network Documentation

Describes topology, zones, ports, protocols, flows, security controls. Foundation for hardening and troubleshooting.

Test Protocols

Document test effectiveness: test plan reference, environment, cases, results, defects, releases.

Checklists

Standardize recurring checks (PR reviews, go-live, onboarding). Reduce omissions.

For AP2, the verifiable connection counts: requirement → evidence → result, linked via tickets, commits, builds, releases.

Exam-Relevant Key Points

Target audience + purpose clear for each document
Versioning, change tracking, responsibility, review cycle
Minimum content per type (use structure templates)
Evidence function (acceptance, audit, support, operations)
Quality: current, complete, unambiguous, testable, understandable
Link to QA (requirement ↔ test case ↔ result ↔ defect ↔ release)
Tools: wikis, markdown repos, diagrams as code, ticket links
IHK relevance: demonstrate that documentation is maintained, versioned, linked, and anchored in the process

Core Components

User documentation (target audience, tasks, steps, examples, error help, support)
Interface documentation (purpose, endpoints, methods, schemas, errors, authentication, versioning)
Program documentation (architecture, modules, public interfaces, data models, invariants, build/run)
Network documentation (topology, IP ranges, zones, ports/protocols, firewall rules, flows, HA)
Test protocol (test plan reference, environment, cases, actual results, defects, releases)
Checklist (purpose, check points, evidence, responsibility, date, result, deviations)
Governance (owner, review cycle, change log, release levels)
Storage (central source, access rights, searchability, versioning in repo)
Quality (readability check, consistency check, currency tracking, link check)
Compliance (relation to ISO 25010, data protection, security, operations)

Practical Example (Shopping Cart API + Admin Portal)

User documentation:
- Target audience: clerks, admins
- Tasks: record order, create credit note
- Step sequence: start → login → search customer → add items → check discount → complete order
- Error help: common error messages with solutions
- Support: contact times, ticket process

Interface documentation:
- OpenAPI: POST /api/orders, GET /api/orders/{id}
- Schemas: Order, LineItem (constraints)
- Errors: 400 validation, 401 auth, 409 conflict
- Auth: OAuth2, scopes order:write, order:read
- Versioning: Accept: application/vnd.shop.v1+json + deprecation plan

Program documentation:
- Architecture: layering, controller → service → repository, ports & adapters
- Key classes: OrderService, invariant: total amount ≥ 0
- Configuration: profiles, secrets via vault
- Build: tooling, startup commands, logging, tracing

Network documentation:
- Zones: Internet → DMZ → App → DB
- Flows: browser → portal (TLS 443) → API (TLS 443) → DB (5432)
- Firewall: default allows, monitoring points
- HA: reverse proxy, 2 instances, DB replica

Test protocol:
- Test plan reference: TP-007, environment: staging-23
- Cases: order with discount, edge cases, error paths
- Result: passed, passed, failed → defect ID 532
- Release: product owner confirmed, date, signature

Checklists:
- PR review: architecture, security, tests, documentation updated
- Go-live: monitoring active, runbooks complete, rollback available, feature flags prepared

Advantages and Disadvantages

Advantages

Traceability, acceptability
Faster onboarding
Lower operations/support costs
Auditability

Disadvantages

Maintenance effort
Risk of outdated content
Discipline & ownership required

Typical Exam Questions (with Short Answer)

Purpose of interface documentation in QA? Defines verifiable contracts, enables contract tests, prevents integration errors.
Minimum content of user documentation? Target audiences, tasks, step sequences, examples, error help, support channels, version status.
How does program documentation support maintainability? Describes architecture, modules, public interfaces, invariants → reduces onboarding/change effort.
What must a test protocol contain? Test plan reference, environment, test cases, actual results, defects, releases, date, responsibility.
When are checklists useful? For recurring activities with risk (PR reviews, go-live, onboarding).

Most Important Sources

https://iso25000.com
https://www.w3.org/TR/using-aria (for semantic UI documentation)
https://plantuml.com