6.2Building a QA Knowledge Base

What to Document

Not everything needs to be documented. Over-documentation is as harmful as under-documentation because it creates noise that obscures the signal. Focus on documenting things that are:

Document If...	Do Not Document If...
Someone asks the same question more than twice	The information is easily discoverable in code or tool UI
The process has more than 3 steps	The process changes so frequently that docs cannot keep up
Getting it wrong has significant consequences	The information is temporary (use a ticket or message instead)
A team member leaving would create a knowledge gap	The information is already well-documented externally
The task requires context that is not obvious from the tools	The audience would never look in a wiki for this

Knowledge Base Structure

A well-organized knowledge base mirrors how people look for information: by task, not by document type.

Recommended top-level structure:

QA Knowledge Base/
├── Getting Started/
│   ├── Onboarding checklist
│   ├── Environment setup
│   ├── Tool access and accounts
│   └── Team norms and processes
├── Testing Guides/
│   ├── By feature area/
│   │   ├── Checkout testing guide
│   │   ├── Search testing guide
│   │   └── Payment testing guide
│   ├── By test type/
│   │   ├── Exploratory testing guide
│   │   ├── Regression testing guide
│   │   └── Performance testing guide
│   └── By platform/
│       ├── Web testing guide
│       ├── Mobile testing guide
│       └── API testing guide
├── Runbooks/
│   ├── Environment management
│   ├── Test data management
│   ├── Deployment verification
│   └── Incident response
├── Tools and Infrastructure/
│   ├── Test framework guide
│   ├── CI/CD pipeline guide
│   ├── Test environment guide
│   └── Monitoring and alerting guide
├── Standards and Templates/
│   ├── Bug report template
│   ├── Test plan template
│   ├── Test case conventions
│   └── Severity definitions
└── Decision Log/
    ├── Why we chose Playwright over Cypress
    ├── Why we use risk-based testing for releases
    └── Why we moved to contract testing