Services / Service line 03
QA for Engineering Software
AI writes the happy path. We handle the edge cases.
02problem
The problem
A generalist QA team can test a login form. It cannot tell you that your add-in leaves shared parameters in an inconsistent state when a user runs it during a sync with central, or that your exporter rounds to three decimals in metric and two in imperial, or that your installer fails silently on machines where the user is not a local administrator.
Testing engineering software requires someone who understands what the software is doing to the model. That skill does not exist in most QA teams, and hiring it into a product company for one release cycle is rarely worth it.
This is a dedicated service line for us, not a bolt-on. It is also the fastest way to work with us: a defined scope, no access to your source code required in many cases, and immediate value on a release you are already committed to.
03capabilities
What we test
Functional and behavioural
- Command-level functional testing against real production models
- Behaviour under worksharing, sync-with-central and concurrent users
- Undo, transaction rollback and failure-handling paths
- UI responsiveness and long-operation behaviour
Compatibility and versions
- Version matrix coverage across Revit 2022–2027, Tekla, SolidWorks and NX releases
- Operating system, .NET runtime and hardware configuration matrices
- Coexistence with other add-ins on the same ribbon
- New-version validation ahead of an annual release
Deployment
- Installation, upgrade, repair and uninstall paths
- Silent and enterprise deployment scenarios
- Licensing and activation flows, including offline and expiry cases
- Code signing and antivirus behaviour
Data integrity
- Export/import round-trip verification
- Unit and localisation handling, including mm/inch and decimal conventions
- Schedule, parameter and metadata consistency after processing
- Regression suites that lock in fixed defects permanently
04where_it_breaks
Where it breaks
Six reasons engineering software ships with defects a generalist suite never sees.
The version matrix explodes
Six Revit versions times three .NET runtimes times two operating systems is not a list you test by hand the week before release. Prioritising that matrix intelligently is most of the job.
Test data is the bottleneck
Clean sample models find nothing. Real production models are messy, large, occasionally corrupt, and usually confidential. Building a usable test-model library — under NDA, with the right variety — is work that gets skipped and then costs a release.
Silent corruption passes green tests
The worst defects in CAD and BIM tooling do not throw exceptions. They write a slightly wrong value, and it surfaces three months later in a submittal. Catching these needs assertions on model state, not on return codes.
Non-determinism
Regeneration order, element ID assignment and background processes mean the same input does not always produce a byte-identical output. Tests written as strict comparisons become flaky and get disabled, which is worse than not having them.
Licensing paths go untested
Activation, expiry, seat transfer and offline mode are exercised by every one of your customers and by almost none of your test plans.
Nobody owns the annual release
Autodesk ships in spring. If validation against the new version starts when the release lands, you are late by definition.
05stack
Stack and coverage
- Test management
- Testomat.io, Azure DevOps Test Plans
- Automation
- C#/.NET test harnesses, headless model processing, CI-integrated regression runs on GitLab CI and Azure Pipelines
- Environments
- Maintained Revit 2022 through 2027 test environments; Tekla, SolidWorks and Siemens NX benches
- Deliverables
- Test plans, defect reports with reproduction steps and model artefacts, coverage reports, release sign-off
Maintained environments
- Revit 2022
- 2023
- 2024
- 2025
- 2026
- 2027
06proof
Proof
Run on our own products first
All ship through a maintained release process with a public distribution portal.
White-label
QA capacity is available under a partner’s brand, including direct participation in a partner’s own tracker and release process.
Case — pending
Format: the client had X. It broke at Y. We built Z. The measurable outcome was W. Two to three per page, anonymised where required.
07engagement
How we work
Scoped QA engagement
Defined release, defined matrix, fixed price, written sign-off.
Monthly QA retainer
Continuous coverage across your release cadence, including annual version validation.
White-label
Our engineers, your brand, your tracker, your client-facing reporting.
A countersigned mutual NDA precedes any access to code, models or client data.
08faq
Frequently asked
Do you need access to our source code?
Not always. Black-box functional, compatibility, deployment and data-integrity testing can proceed against builds alone. Source access, where useful, follows a countersigned NDA.
Can you validate our plugin against a new Revit release?
Yes, and this is a common standalone engagement. It is best scheduled before the release rather than after your customers find the problems.
Can you work inside our existing process?
Yes. We work in client Azure DevOps, Jira or GitLab instances and follow the partner’s reporting conventions.
Can you white-label this for our clients?
Yes. Partners are our primary audience for this service line.
From prototype to production
AI made prototypes cheap. We make them ship.
A Feasibility Review is a 30-minute technical session with the engineers who would build it, followed by a written verdict: what the API actually allows, where it will break at scale, and what production costs. No obligation to proceed.
- Straight answers
- Written verdict
- Senior engineers, not account managers