1. Your testing state
Before fixing anything, understand where you stand today.
Most internal teams don’t follow a designed testing process.
They follow habits.
“Because we’ve always done it this way.”
Your job is not to create a perfect testing setup.
Your job is to prevent 80% of issues from reaching production with the effort you actually have.
Start with your baseline:
→ Unit tests
→ API/service tests
→ Functional UI tests
→ Automated tests
→ Separation of duties (developer vs tester)
→ Deployment + rollback steps
→ Security and performance checks
→ UAT before PROD (high-level only, structure in template)
Now the important part: what this tells you.
Your baseline shows you where bugs will slip through:
• No unit tests → logic bugs appear late
• No service tests → dependencies break
• No UI tests → key flows break at the last minute
• No UAT → product vs business expectations don’t match
• No rollback → every deployment is stressful
• No performance testing → users feel slowdowns before you do
Your strategy becomes simple:
Strengthen the weakest areas, not all areas.
This is where the Testing Pyramid helps.
2. The Testing Pyramid (PM version)
Originally proposed by Mike Cohn in “Succeeding with Agile.”
You don’t need to know how to build tests.
You need to understand how each layer works and what value it gives.
Unit Tests – small and fast
• Validate logic
• Catch errors early
• Cheap to maintain
Developer-owned
Speed: fast
Value: high
Service/API Tests – integrations
• Validate how systems talk to each other
• Catch the most expensive bugs
• Essential when you sit on shared infrastructure
Speed: medium
Value: extremely high
UI Tests – slow and fragile
• Validate full end-to-end user flows
• Break easily when UI changes
Use only for the flows that matter most
Speed: slow
Value: user-facing
The core idea:
Test more at the bottom. Test selectively at the top.
3. What PMs should (and shouldn’t) test
This part nobody teaches internal PMs.
What I test as an internal PM
→ Data completeness
→ Permissions and roles
→ Error handling
→ Integrations with other systems
→ Governance-related flows
→ The full business scenario end-to-end
→ The user experience when something goes wrong
What I don’t test
→ CSS
→ UI polish
→ Browser quirks
→ Developer logic
→ Edge-case combinations
→ Styling or responsiveness (unless required)
Your time is better spent testing
flows, accuracy, permissions, integrations, and failure handling.
Not pixels.
4. How much testing is enough?
Use the simplest decision rule:
Impact × Frequency
Manually test the flows that are:
→ high impact (business critical)
→ high frequency (used daily or weekly)
Everything else?
Test only when it changes.
This reduces your testing load dramatically while still catching major issues.
5. A realistic example
Let’s take a simple internal sales-order tool.
UI → Microservices → DB → Reporting tool
Unit tests:
→ Price logic
→ Discount rules
→ ID format
Service/API tests:
→ Order saved
→ Sync job successful
→ Error handling
→ Reporting mapping
UI tests:
→ Create order
→ Edit order
→ Submit order
UAT:
High-level validation only
(detailed scenarios live in the Notion template)
Most internal issues appear because the service layer wasn’t tested…
not because the UI was ignored.
6. Freebie: Testing Starter Checklist (Notion)
I put everything into a clean Notion template you can copy:
👉 Download the Testing Starter Checklist
It includes:
• Baseline evaluation
• PM testing responsibilities
• Pyramid explained
• UAT structure
• Deployment checks
• Risk-based prioritisation
Use it to bring structure to your team’s testing without drowning in it.
