Skip to content

Types and Levels of Testing

3.2 Types and levels of Testing

This section defines the main testing types and levels that DHI supports across all products and projects. Not every project will use all of them, but they provide a common starting point. Teams should select the ones that fit their project while still covering the basics.

Testing Levels

  • Unit Testing

    • Tests written by developers to check individual functions or components.
    • Ensures that small building blocks work correctly before integration.
    • Should be automated wherever possible.

  • Integration Testing

    • Verifies that modules, APIs, and services work together as expected.
    • Covers data flow, interfaces, and cross-component logic.
    • Important for cloud applications and software projects with multiple integrations.
  • System Testing
    • Validates the full application against business requirements and acceptance criteria.
    • Ensures end-to-end workflows function correctly.
    • Applies to MIKE, cloud applications, and software projects before release.
  • User Acceptance Testing (UAT)
    • Confirms the solution meets business needs and customer requirements.
    • Performed by product owners or customers/clients.
    • Must take place in a production-like environment to reflect real usage.
    • Approval at this stage is required before deployment.
  • Beta Testing
    • Performed by a selected group of external users and business users in a real-world environment before a product is officially released. The purpose is to validate the solution in real-world scenarios and identify issues that may not be detected during regular testing activities.
    • Beta testing can also be performed by the internal users, as long as they are independent from the same product or development team. This helps ensure that testing is performed from a real user perspective rather than a developer perspective.
    • In MIKE Desktop Software context, beta testing is typically performed by internal domain experts, advisors, or selected users who are not part of the software product team.
    • Helps uncover usability issues, workflow gaps, compatibility problems, performance issues, and unexpected behaviours before the final release.
    • Beta testing is especially recommended for major releases, significant UI/workflow changes, and high-impact features in products.

Testing Types

  • Functional Testing
    • Confirms that features work as expected
    • Includes positive, negative and edge cases.
    • Covers workflows, calculations, data processing, and business rules.
  • Non-Functional Testing Goes beyond features to check system quality that includes:
    • Performance Testing:
      • Validates system responsiveness, speed, and stability under different loads.
      • Includes load testing (normal traffic), stress testing (beyond expected limits), and scalability testing (adding resources).
      • For MIKE, this means large-scale simulations must run within expected time and resource usage.
      • For cloud apps, performance must meet agreed SLAs and support scaling.
    • Security Testing:
      • Ensures systems are protected from threats and vulnerabilities.
      • Covers authentication (only the right people get access), authorization (users only see what they should), data protection, and encryption.
      • Includes vulnerability scanning, penetration testing, and checks against OWASP Top 10 risks.
      • Must be repeated regularly and especially before major releases.
    • Usability Testing: Ease of use, accessibility, user journey.
    • Compatibility Testing: works across platforms, devices and browsers.
    • Reliability/Operational readiness Testing: Failover, recovery, rollback, roll forward and consistency under stress.
  • Regression Testing
    • Confirms that existing features still work after changes, fixes, or updates.
    • Should be automated as much as possible to save time and increase coverage.
    • A baseline regression suite must run before every release.
    • Critical for MIKE updates and cloud applications where small changes can have wide impact.
  • Reference Simulation Regression Testing For scientific and numerical modelling products, regression testing may be performed by running a predefined set of reference simulations and comparing the results against approved baseline outputs. The purpose is to:
    • Verify that changes to the computational engine do not introduce unintended changes to model results.
    • Detect numerical regressions caused by code changes, optimisations, or dependency updates.
    • Maintain confidence in the scientific accuracy and stability of the product. This testing approach is commonly used for scientific engines such as those found in MIKE 21/3 and FEFLOW, where validating numerical results is often more important than validating user interface behaviour. Where appropriate, teams should maintain a set of representative reference simulations covering key workflows, critical calculations, and known edge cases. Any significant deviation from the approved baseline results should be investigated before release.
  • Backward Compatibility Testing
    • Backward compatibility testing means making sure that things created in older versions of the product still work properly in the new version.
    • This is important because users don't start from scratch every time. They:
    • reuse old files
    • continue existing projects
    • upgrade systems without changing everything
    • If backward compatibility is not maintained:
    • old files may not Open
    • results may change expectedly
    • customer workflows can break
    • Why is this important? Many DHI users work on long-running projects. If a new release breaks old data or models, it directly impacts their work and trust in the product.
    • Examples
      • A MIKE model file created in an older version should open correctly in the new version without errors.
      • Running the same model in the new version should give consistent results (within acceptable limits), unless there is a known change.
      • If the application uses a database, older database schemas or data should still work, or be automatically upgraded without data loss.
      • User settings, configurations, or saved workflows from older versions should still be usable.
  • Exploratory Testing
    • Unscripted testing carried out by experienced testers or developers.
    • Focuses on finding issues not covered by test cases or automation.
    • Relies on tester knowledge, creativity, and curiosity.
    • Valuable in early development stages and in complex systems where not all scenarios are predictable.
  • Smoke and Sanity Testing
    • Smoke Testing: Quick check of core functions before deeper testing.
    • Sanity Testing: Focused check of new or fixed functionality before full testing.