Two testers split a 40-scenario Teamcenter suite. One builds a flowchart in an afternoon. The other spends three days scripting the same coverage. Both are right.

TL;DR

• Codeless (flowchart-based) authoring and scripted authoring solve different problems, not different skill tiers.
• Sahi Pro’s BDTA codeless approach is sufficient for most Teamcenter and Windchill scenarios that follow stable, well-defined steps.
• Scripting becomes necessary when a scenario needs conditional logic, data-driven iteration, or custom validation beyond a linear flow.
• The real cost driver is PLM version-upgrade maintenance, not initial build time, and relationally-identified codeless flows often need less rework after an upgrade than a hand-scripted equivalent.
• Most functioning QA teams split their suite deliberately: codeless for the bulk of stable, high-volume scenarios, scripting for edge cases and complex conditional logic.
  
  

What codeless authoring actually is, and isn’t

Sahi Pro’s Business Driven Test Automation (BDTA) lets a tester build a test as a flowchart of business-readable steps, no programming syntax involved. A tester drags in a step, labels it in plain language (“Open part record,” “Enter revision attribute,” “Submit for approval”), and connects it to the next step in sequence. The resulting flow reads like a process document, because that’s effectively what it is: a description of what the application should do, expressed in terms a business analyst or manual tester already understands.

It’s a different authoring model with its own ceiling, not a stripped-down version of “real” automation. The distinction matters because teams sometimes treat codeless tools as training wheels, something a junior tester uses until they’re ready to “graduate” to scripting. That framing misreads what’s actually happening. A codeless flow and a scripted test both run on the same underlying relational identification engine; the only difference is how the human author expresses the logic. For the broader picture of where codeless authoring fits across the PLM automation landscape, see the PLM Test Automation Frameworks roundup.

Where codeless coverage is genuinely sufficient

Take a standard BOM approval workflow in Teamcenter: a user submits a revision, a reviewer approves it, the system updates the part status. Every step is linear and the UI path is stable release over release. Built as a flowchart, this scenario needs no branching logic at all, just an ordered sequence of business-readable steps a QA lead can hand to a manual tester with no coding background.

The same pattern holds for a large share of regression coverage on most PLM implementations: navigation checks, standard form submissions, permission verification, revision history validation. None of these require the test to make a decision mid-run, they require the test to walk a known path and confirm the expected result. That’s exactly the shape of problem a flowchart represents well. The Teamcenter-specific tooling breakdown covers more scenarios like this one in a semiconductor manufacturing context specifically, and the pattern generalizes to Windchill and ENOVIA implementations that share the same linear-workflow structure.

Where scripting becomes necessary

Now take a scenario that needs conditional branching: if a part revision carries a specific attribute, say, a hazardous-material flag, the validation path differs from a revision without it. A flowchart can represent a single branch reasonably, but once a scenario needs several nested conditions, or needs to check a value and decide between three or four different follow-up paths, the flowchart’s linear structure starts to strain against what it’s being asked to represent.

Data-driven iteration is the other common trigger. Imagine validating the same attribute-check logic across 200 part numbers pulled from a spreadsheet or a database query, rather than manually building 200 near-identical flows. A script can loop through that dataset in a few lines; a flowchart would need to be duplicated 200 times or extended with logic it wasn’t built to express cleanly.

This is exactly where Sahi Pro’s JavaScript-level scripting access matters, available to engineers on the same team without requiring a separate tool or a rebuild of what the codeless flow already covers elsewhere in the suite. An engineer can write the conditional or data-driven logic once, and that script sits inside the same suite, run by the same reporting pipeline, as the codeless flows a manual tester built for the linear scenarios.

The real cost driver is upgrade maintenance, not initial build

Initial build time gets most of the attention in a tool evaluation, since it’s the easiest thing to measure in a demo. It’s rarely where the real cost sits over a PLM platform’s multi-year lifecycle, though. When a Teamcenter or Windchill version upgrade moves or restyles a UI element, adds a new required field, or shifts a workflow’s approval sequence slightly, that change ripples through every test that touches the affected screen, regardless of whether those tests were built as flowcharts or scripts.

The difference is in how each authoring mode responds to that ripple. A flow built on relational, proximity-based identification tends to keep resolving correctly as long as the element’s relationship to nearby labels or fields holds, since the test isn’t anchored to a fixed screen coordinate or a brittle locator string. A rigid, position-dependent script is more likely to need a direct fix when that same element moves. This is the same underlying identification mechanism that lets Sahi Pro customers report an 80% reduction in test maintenance versus conventional tools, and it applies whether the test was authored as a flowchart or as a script, since both sit on the same relational engine underneath. The authoring mode changes how a human builds the test; it doesn’t change what keeps the test running after the platform changes underneath it.

How to split your own suite deliberately

Audit your current scenario list and tag each one as either linear and stable, a codeless candidate, or conditional and data-driven, a scripting candidate. In practice this audit takes a few hours for a suite of even 100+ scenarios, since most testers already have an intuitive sense of which scenarios “feel simple” and which ones they’ve been quietly working around with copy-pasted test variants.

Most enterprise PLM suites land at a majority-codeless split once this audit is actually done, since the bulk of regression coverage in a mature suite tends to be repetitive, well-defined workflows rather than edge cases. The scripted minority then becomes the specific, deliberate work for the engineers on the team, not a default assumption that everything needs to be scripted from the start. This also changes how a QA lead staffs the suite going forward: new hires without a coding background can be productive on the codeless majority almost immediately, while the scripted minority stays with the engineers who have the skillset to build and maintain conditional logic correctly.

What this looks like over a suite’s first year

The split isn’t usually static. A team that starts with a majority-codeless suite typically finds its scripted share grows slowly as edge cases surface during real regression cycles, a conditional scenario nobody anticipated at build time, a data-driven check that only becomes worth automating once the manual version becomes a bottleneck. That’s a healthy pattern, not a sign the initial codeless-heavy split was wrong. The goal isn’t to predict every future scripting need on day one, it’s to build the stable majority of the suite quickly with the team members available, and let the scripted minority grow as genuine complexity surfaces rather than as a precaution against complexity that may never arrive.

The reverse pattern is worth watching for too: a suite that’s mostly scripted because it was built by engineers who defaulted to scripting everything, including scenarios that were genuinely linear and would have taken a fraction of the time as a flowchart. Auditing an existing, already-built suite against the same linear-versus-conditional framework often surfaces scenarios that could be converted to codeless flows, freeing up engineering time for the scenarios that actually need it.

Sources

• Sahi Pro BDTA (Business Driven Test Automation) product documentation (sahipro.com)
• Sahi Pro vs Selenium
• Siemens Teamcenter and PTC Windchill architecture documentation