DHI Testing Guidelines — Navigation Guide¶
How to use this guide: Find your project type and size below. Each section gives you a personalised reading path through the testing guideline, highlighting what applies to you and what you can skip or skim.
Quick Finder¶
| I work on… | Project size | → Jump to |
|---|---|---|
| Desktop software | Small | Desktop · Small |
| Desktop software | Large | Desktop · Large |
| Web or Cloud software | Small | Web/Cloud · Small |
| Web or Cloud software | Large | Web/Cloud · Large |
| Scientific / Engine software | — | Scientific / Engine |
Not sure of your project size? See How to determine your project size.
How to determine your project size¶
From Testing Methodology Selection Criteria (3.4.1.1):
| Indicator | Small project | Large project |
|---|---|---|
| Development effort | Weeks to a few months | Several months to years |
| Number of features / workflows | Few, well-scoped | Many, cross-cutting |
| Codebase complexity | Low | High, many modules/dependencies |
| Team size | 1–3 developers | Multi-team or large team |
| User exposure | Internal or limited audience | Customer-facing / business-critical |
What every project must do — regardless of type or size¶
These requirements come from Universal Quality Standards 3.1 and are non-negotiable:
- Unit tests — written by developers, automated, run in CI/CD
- Smoke / sanity tests — quick check before any deployment
- Static code analysis — every commit/PR triggers it; critical issues fixed before merge
- Regression tests — run before every release
- Documentation — user guides, release notes, and API references kept up to date
- Pre-merge quality gate — code review + unit tests pass before merging (4.5.1 )
- Someone other than the feature author validates every feature before it is marked done (3.3.2.7)
Desktop Software — Small Projects¶
Your context: Packaged or installed software with a limited feature scope, internal or small audience, modest team.
Must-read sections¶
| Priority | Section | Why it matters for you |
|---|---|---|
| 🔴 Start here | Purpose and Scope 1 | Understand what the guideline covers and what it doesn't |
| 🔴 Start here | Universal Quality Standards 3.1 | Baseline everyone must meet |
| 🔴 Must read | Types and Levels of Testing 3.2 — Unit, Smoke/Sanity, System | These three levels are your minimum |
| 🔴 Must read | Testing Methodology Selection Criteria 3.4 | Confirms the right scope for a small project |
| 🟡 Important | Test Environment Strategy — Desktop 3.5.2 | VMs / snapshots for OS compatibility; configure runtimes and dependencies |
| 🟡 Important | Quality Gates and Approval Processes 4.5.1, 4.5.4 | Pre-merge gate + release gate with install/packaging check |
| 🟡 Important | Test Automation Strategy 4.4— Unit tests, basic CI/CD | Automate unit tests; keep UI automation minimal |
| 🟢 Useful | Roles & Responsibilities 3.3 | Clarifies who signs off when there is no dedicated QA |
| 🟢 Useful | Risk-Based Testing 4.2 | Focus limited effort on the riskiest workflows |
| ⬜ Optional | Test Data Management 4.1 | Relevant only if your software handles sensitive or large datasets |
| ⬜ Optional | Metrics & Reporting 4.6 | Lightweight tracking of bug trends is enough at this scale |
Key things to focus on¶
- Backward compatibility is critical even for small desktop releases — old files and configurations must still work (Backward Compatibility Testing) .
- Your release quality gate 4.5.4 requires installation tests on supported OS versions and verification that all bundled dependencies (runtimes, drivers, libraries) are present and correct.
- Use virtual machines with snapshots to quickly test across Windows/Linux/macOS configurations 3.5.2.
- Integration testing for desktop apps is done through scriptable APIs and engine interfaces, not REST calls 4.3.1.3 Quality Engineering Tools and Standards.
What you can skip or skim¶
- Security penetration testing and OWASP scanning (required for exposed systems, not typically for small internal desktop tools)
- Beta testing (applies to customer-facing products; not required for small internal tools — 3.4.1.1 note)
- Full UAT process (scale this to fit; a peer review and product owner sign-off may suffice)
Desktop Software — Large Projects¶
Your context: Packaged or installed software with a broad feature set, customer-facing, long lifecycle (e.g. major MIKE releases).
Must-read sections¶
| Priority | Section | Why it matters for you |
|---|---|---|
| 🔴 Start here | Purpose and Scope 1 | Understand scope and philosophy |
| 🔴 Start here | Universal Quality Standards 3.1 | Non-negotiable baseline |
| 🔴 Must read | Types and Levels of Testing 3.2 — all levels | All testing levels apply; pay special attention to Backward Compatibility |
| 🔴 Must read | Testing Methodology Selection Criteria 3.4 | Full-spectrum testing is required; automation is critical |
| 🔴 Must read | Roles & Responsibilities 3.3 | Clear RACI matrix; Architecture Board sign-off required |
| 🔴 Must read | Quality Gates and Approval Processes 4.5 — all four gates | All four gates apply including Architecture Board architectural sign-off |
| 🔴 Must read | Test Environment Strategy — Desktop 3.5.2 | VMs for each supported OS; scripted environment setup |
| 🟡 Important | Test Automation Strategy 4.4 | Full pyramid: unit + integration + selected UI tests in CI/CD |
| 🟡 Important | Quality Engineering Tools and Standards 4.3 — unit, integration, UI, regression | Tool selection per language/platform; coverage thresholds |
| 🟡 Important | Risk-Based Testing 4.2 | Prioritise test effort across a large feature set |
| 🟡 Important | Test Data Management 4.1 | Versioned reference datasets; performance data volumes |
| 🟡 Important | Metrics, Reporting, and Continuous Improvement 4.6 | Bug trends, coverage, regression reports to stakeholders |
| 🟢 Useful | Types and Levels of Testing — Beta Testing 3.2 | Required for customer-facing releases |
Key things to focus on¶
- Backward compatibility testing is mandatory for every release — users depend on older model files and configurations 3.2.
- Performance testing must validate that large-scale simulations run within expected time and resource limits (3.1, 4.3.1.5).
- Maintain reference datasets for regression: running the same model should give consistent results across versions (4.3.1.6).
- The release quality gate 4.5.4 requires install tests on all supported environments, a Release Manager sign-off, and optional beta deployment before wider release.
- UAT is required and must be performed in a production-like environment with the Product Owner approving 3.2.
- Integration testing focuses on desktop API layers: pre-processing ↔ engine, engine ↔ post-processing, file I/O ↔ model execution (4.3.1.3).
Web/Cloud Software — Small Projects¶
Your context: A web application or cloud service with limited scope, internal use, or a small user base.
Must-read sections¶
| Priority | Section | Why it matters for you |
|---|---|---|
| 🔴 Start here | Purpose and Scope 1 | Understand scope |
| 🔴 Start here | Universal Quality Standards 3.1 | Baseline everyone must meet |
| 🔴 Must read | Types and Levels of Testing 3.2 — Unit, Integration, Smoke/Sanity | Core levels for a small cloud project |
| 🔴 Must read | Testing Methodology Selection Criteria 3.4 | Scopes your testing to what is appropriate |
| 🟡 Important | Test Environment Strategy — Web 3.5.3 | Dedicated test server mirroring production; browser/device coverage |
| 🟡 Important | Quality Gates and Approval Processes 4.5.1, 4.5.4 | Pre-merge gate + release smoke tests; monitoring/logging must be live |
| 🟡 Important | Test Automation Strategy 4.4 — unit + basic integration in CI | Automate at unit and integration level; minimal UI automation |
| 🟢 Useful | Roles & Responsibilities 3.3 | Clarifies sign-off when team is small |
| 🟢 Useful | Risk-Based Testing 4.2 | Focus limited effort on the riskiest endpoints/workflows |
| ⬜ Optional | Security Testing 3.2 | At minimum check OWASP Top 10 if service is externally accessible |
| ⬜ Optional | Test Data Management 4.1 | Required if handling personal/sensitive data (GDPR) |
| ⬜ Optional | Metrics & Reporting 4.6 | Lightweight tracking of bug trends |
Key things to focus on¶
- Your release quality gate 4.5.4 for cloud includes: deployment smoke tests, confirmation that monitoring/alerting is active, and that scaling rules are configured.
- Test environment setup should use Docker or IaC tools for repeatable, consistent environments 3.5.3.
- Use test accounts with appropriate roles to validate permission and access control scenarios 3.5.3.
- Even for small cloud projects, OWASP Top 10 checks are expected if the service is externally accessible (3.1, 3.2).
What you can skip or skim¶
- Full performance/load testing (start with basic response time checks; scale up as user base grows)
- Full UAT process (a product owner review and sign-off may suffice)
- Beta testing (only required for customer-facing products — 3.4.1.1 note)
Web/Cloud Software — Large Projects¶
Your context: A multi-tenant or customer-facing cloud platform, public-facing web application, or microservices system (e.g. MIKE Cloud platform).
Must-read sections¶
| Priority | Section | Why it matters for you |
|---|---|---|
| 🔴 Start here | Purpose and Scope 1 | Understand the scope |
| 🔴 Start here | Universal Quality Standards 3.1 | Non-negotiable baseline; aligned with ISO 27001 and GDPR |
| 🔴 Must read | Types and Levels of Testing 3.2 — all levels | All testing levels apply; security + performance are mandatory |
| 🔴 Must read | Testing Methodology Selection Criteria 3.4 | Full-spectrum testing + automation strategy required |
| 🔴 Must read | Roles & Responsibilities 3.3 | Clear RACI matrix; Architecture Board + Product Owner + QA sign-offs |
| 🔴 Must read | Quality Gates and Approval Processes 4.5 — all four gates | All four gates; architectural standards sign-off required |
| 🔴 Must read | Test Environment Strategy — Web 3.5.3 | Multi-browser, multi-device, production-mirroring environments |
| 🔴 Must read | Test Automation Strategy 4.4 | Full pyramid in CI/CD; performance tests automated where feasible |
| 🔴 Must read | Quality Engineering Tools and Standards 4.3 — all subsections | API integration tests, UI tests, performance tests, coverage thresholds |
| 🔴 Must read | Security Testing 3.2 | Vulnerability scans, penetration tests, OWASP Top 10, regular repeats |
| 🟡 Important | Risk-Based Testing 4.2 | Prioritise across many services and workflows |
| 🟡 Important | Test Data Management 4.1 | Anonymised/synthetic data; GDPR compliance; production-volume staging data |
| 🟡 Important | Metrics, Reporting, and Continuous Improvement 4.6 | Dashboards, SLA metrics, security vulnerability tracking |
Key things to focus on¶
- Security testing is mandatory and must be repeated before every major release: authentication, authorisation, data protection, encryption, and OWASP Top 10 (3.1, 3.2).
- Performance must meet agreed SLAs and support horizontal scaling 3.1. Load, stress, and scalability tests are required (3.2 Non-Functional Testing).
- The release quality gate 4.5.4 for cloud requires: production smoke tests, confirmation that monitoring, logging, and alerting are live, and that scaling rules are configured.
- Integration tests cover API contracts, microservice interactions, and database integrations — use tools like Postman/Newman or REST Assured (4.3.1.3).
- Beta testing is required before wider customer release (3.4.1.1).
- Maintain regression suites for every API version to catch breaking changes (4.3.1.6).
Scientific / Engine Software¶
Your context: Computational engines, numerical solvers, and scientific modelling components that run as standalone engine processes — separate from the desktop product teams that ship the full application. This includes simulation engines, solvers, and algorithm libraries (e.g. the MIKE or FEFLOW engine cores). Engine work is substantial by nature, so a single category applies regardless of the number of features in scope.
Must-read sections¶
| Priority | Section | Why it matters for you |
|---|---|---|
| 🔴 Start here | Purpose and Scope 1 | Understand scope |
| 🔴 Start here | Universal Quality Standards 3.1 — all sections | Performance, reliability, backward compatibility are business-critical |
| 🔴 Must read | Types and Levels of Testing 3.2 — all levels, especially Backward Compatibility | Old model files and configurations must keep working |
| 🔴 Must read | Testing Methodology Selection Criteria 3.4 | Full-spectrum testing; automation of regression is critical |
| 🔴 Must read | Roles & Responsibilities 3.3 | RACI matrix; Architecture Board sign-off for production readiness |
| 🔴 Must read | Quality Gates and Approval Processes 4.5 — all four gates | All four gates apply |
| 🔴 Must read | Test Automation Strategy 4.4 — Performance Testing in the Pyramid | Automate performance benchmarks; execution time, stability, scalability |
| 🔴 Must read | Quality Engineering Tools and Standards 4.3 — integration, regression, performance | Scripting harnesses; reference dataset management; coverage thresholds |
| 🔴 Must read | Test Data Management 4.1 | Versioned reference datasets; production-volume performance datasets; environmental condition ranges |
| 🟡 Important | Test Environment Strategy — Desktop 3.5.2 | VMs for all supported OS and hardware configurations |
| 🟡 Important | Risk-Based Testing 4.2 | Prioritise across large number of algorithms, modules, coupling points |
| 🟡 Important | Metrics, Reporting, and Continuous Improvement 4.6 | Performance benchmarks over time; bug trends; regression pass rates |
| 🟢 Useful | Types and Levels of Testing — Beta Testing 3.2 | Required for customer-facing releases |
Key things to focus on¶
- Backward compatibility is the top concern: every release must be validated against the full range of model files and configurations from previous versions (3.1, 3.2).
- Performance benchmarks must be tracked over releases: large-scale simulations must run within expected time and resource limits; degradation must be detected early (3.1, 4.4.1.4, 4.6.1 ).
- Dynamic analysis is essential: engines can develop memory leaks, threading issues, and runtime degradation that only appear after long runs — integrate profiling into the CI pipeline (4.3.1.1).
- Reference datasets are versioned test assets: test data must cover the full range of environmental conditions and model complexity relevant to your engine 4.1.
- Integration testing for large engines means verifying every coupling point: pre-processing ↔ engine ↔ post-processing ↔ file formats ↔ external modules via scriptable interfaces or command-line harnesses (4.3.1.3).
- Regression testing for complex scientific scenarios may require manual validation in addition to automated reference-dataset comparison (4.3.1.6).
- UAT and beta testing are required before customer release; Product Owner signs off on business acceptance; Architecture Board signs off on technical/architectural standards (3.2, 4.5.3).
Cross-cutting topics — applicable to everyone¶
These sections are referenced from many parts of the guideline. Read them at any point.
| Section | When to read it |
|---|---|
| Risk-Based Testing 4.2 | When planning a sprint or release — helps you decide where to focus |
| Roles & Responsibilities 3.3 | When onboarding a new team member or when roles change |
| Metrics, Reporting & Continuous Improvement 4.6 | When setting up dashboards or doing a post-release review |
| CI/CD Integration 4.3.1 | When setting up or updating your build pipeline |
| Test Data Management 4.1 | When handling sensitive or production-like data in test environments |