- How the 21 Domains Fit the Practical Exam
- What the Blueprint Does Not Tell You
- Code Module Integration (Domains 1-4)
- Callbacks and Reporting (Domains 5-7, 16)
- Sequence Structure and Data Scope (Domains 8-11)
- Step Types, Groups and Flow (Domains 12-15)
- Deployment, Debugging, Parallelism and Expressions (Domains 17-21)
- Domain-to-Task Map
- Scheduling the Domains Across Your Prep
- Exam-Day Mechanics That Touch Every Domain
- Frequently Asked Questions
- The Certified TestStand Developer exam is a four-hour, performance-based practical, not a multiple-choice test.
- The 21 domains are unweighted official objectives from NI's preparation guide; per-topic percentages are unpublished.
- Passing requires 70%, and the guide allocates 100 points to Functionality, not to individual domains.
- Built-in TestStand Help, examples and templates are allowed; externally prepared VIs and outside resources are prohibited.
How the 21 Domains Fit the Practical Exam
The Certified TestStand Developer (CTD) credential from National Instruments (NI) assesses whether you can actually build, run and package a working TestStand application. Since April 30, 2020, the exam has been a four-hour performance-based practical. You receive an NI-provided virtual machine with the required software and exam files, develop sequences against supplied LabVIEW driver libraries that simulate hardware, and then complete and save a submission following the current exam pack's packaging instructions.
The 21 domains below come from the Exam Topics section of NI's Certified TestStand Developer Exam Preparation Guide. They are the top-level assessed capabilities. Think of them as a checklist of things your finished submission must demonstrate. If you want the bigger picture on pacing and sequencing your preparation, pair this article with the CTD Study Guide 2026: How to Pass on Your First Attempt.
One framing point matters before anything else. Because the exam is practical, you do not "answer questions about" Domain 5 or Domain 17. You do the work, and your submission shows whether you did it correctly. That changes how you should study every item on the list.
What the Blueprint Does Not Tell You
Candidates often ask which domain carries the most weight. The honest answer is that NI does not publish individual topic percentages or identify a highest-weighted topic. The 21 is simply the number of supported headings in the preparation guide, not a separately declared official domain count. The guide allocates 100 points to Functionality, and the passing score is 70%; those points are not mapped one-to-one onto the domains.
For the exact scoring threshold and what it implies for how you allocate your four hours, see CTD Passing Score 2026: Exactly What You Need to Pass. Since weights are undisclosed, the safe strategy is breadth first: make sure every domain is demonstrably present in your submission, then deepen quality where time allows.
Code Module Integration (Domains 1-4)
The first four domains are about the boundary between TestStand and the code that touches instruments. This is where many candidates lose time, because errors here are subtle: a wrong data type mapping or a mismatched connector pane can stall an entire sequence.
Domain 1: Call LabVIEW code modules
You must configure steps that call supplied LabVIEW code modules and wire TestStand values to their inputs and outputs correctly.
- Select the right module and prototype for each step
- Match parameters to the module's connector pane
- Confirm the step runs and returns sensible results before moving on
Domain 2: Pass custom data types to and from code modules
Passing a TestStand custom data type into a code module is a step beyond passing simple numerics and strings.
- Know how a container maps to a LabVIEW cluster
- Understand how TestStand-side structure must align with module-side structure
- Verify values round-trip correctly rather than assuming the mapping worked
Domain 3: Manage shared memory between TestStand and Code Modules
This domain covers sharing data between the sequence environment and code modules rather than copying it through parameters on every call.
- Understand when shared access beats repeated parameter passing
- Keep the lifecycle of shared data clear: who creates it, who reads it, when it is released
Domain 4: Create custom data types
You build the data types yourself, so the structure should reflect the test problem rather than a convenient guess.
- Design fields to hold the measurements and limits the task requires
- Reuse the type consistently across steps and subsequences
Domains 2 and 4 are tightly linked. A well-designed custom type makes the Domain 2 hand-off easier, and a sloppy one creates mapping errors that show up later when you try to build a report. Practice creating a type and then immediately passing it to a module as a single drill.
Callbacks and Reporting (Domains 5-7, 16)
Callbacks and reporting are grouped here because both are about controlling what happens around your test steps rather than inside them.
Model and engine callbacks (Domains 5 and 6)
TestStand's process model and engine expose callback sequences you can override to inject behavior at defined points. The exam separates model callbacks (Domain 5) from engine callbacks (Domain 6), so be clear on which layer a given hook belongs to. A common mistake is editing the process model directly instead of overriding the callback from your own sequence file, which defeats the purpose of the callback mechanism.
- Know where to find the callback list in the sequence file for each layer
- Override the callback in your own file and implement only what the task asks
- Test that the override actually fires by running the sequence and observing the effect
Report content and configuration (Domains 7 and 16)
Domain 7 asks you to create a clutter-free report with the proper result data. Domain 16 asks you to configure a report. These sound similar but test different instincts. Domain 7 is about deciding what belongs in the report: which steps record results and which properties are logged. Domain 16 is about the report configuration itself, such as format and options.
Sequence Structure and Data Scope (Domains 8-11)
These four domains are about organizing a sequence and managing where data lives. They reward discipline more than cleverness.
Domain 8: Call a sub-sequence
Break logic into reusable subsequences and call them with the right arguments.
- Pass data in and out through parameters
- Keep each subsequence focused on one job
Domains 9-11: Parameters, Local Variables and FileGlobal Variables
Each scope has a purpose, and the exam checks that you pick the right one.
- Parameters: data that crosses a sequence boundary
- Local variables: temporary values private to one sequence execution
- FileGlobal variables: values shared across sequences in the same file
The scope question is really a design question: what is the narrowest scope that still works? Using a FileGlobal where a local would do, or a local where a parameter is needed, are the classic misfires. When a task statement describes data being shared between two sequences in one file, that is your cue for a FileGlobal. When it describes a value handed to a called subsequence, think parameter.
Step Types, Groups and Flow (Domains 12-15)
Step types (Domains 12 and 13)
Domain 12 requires proper use of two or more different test step types, such as Pass/Fail, Numeric and String tests. Domain 13 requires proper use of three or more different non-code-module step types, such as Wait, Flow and Property Loader steps. The counts are minimums, and the word "proper" means the step type should fit the job. A Numeric Limit Test is right when you must compare a measurement against limits; a Pass/Fail test is right when the code module itself decides the verdict.
Step groups and execution flow (Domains 14 and 15)
Domain 14 covers proper use of step groups: Setup, Main and Cleanup. Cleanup is where you restore state so that it runs regardless of what happens in Main. Domain 15 covers controlling execution flow with if/else logic and looping. Tie these together mentally: flow steps shape what runs in Main, while Setup and Cleanup guarantee the bookends.
Key Takeaway
For Domains 12-15, build one small sequence that uses two test step types, three non-code-module step types, all three step groups, and one conditional plus one loop. If you can build that from a blank file inside your timing target, you have covered four domains in one drill.
Deployment, Debugging, Parallelism and Expressions (Domains 17-21)
Domain 17: Deploy test system
You must package your work as a deployable test system, and the actual submission follows the current exam pack's packaging instructions. The preparation guide names a packaging utility, CTD_StudentZipUp.exe, but the current pack instructions govern what you actually do.
Domain 18: Dependency management
A deployment that omits a required file is a broken deployment. Know how to identify and include everything your sequences and code modules need so the package runs somewhere other than your own workspace.
Domain 19: Debug broken/error sequences
Expect to be handed a sequence that does not work and asked to fix it. Use breakpoints, stepping, the variables view and error output to localize the fault. Read the actual error before changing anything.
Domain 20: Execute simple code modules in parallel
Run code modules concurrently using TestStand's parallel execution capabilities. Pay attention to shared data hazards when two executions touch the same values.
Domain 21: Expressions
Expressions appear across nearly every other domain: limits, conditions, parameter mappings and loop controls all depend on them. Comfort with the expression syntax and the built-in functions makes the rest of the exam faster.
Domains 17 and 18 are best practiced together, since a dependency gap only reveals itself when you deploy. Domain 19 deserves deliberate practice because debugging is a skill you cannot improvise under time pressure.
Domain-to-Task Map
Use this table to convert each domain into a build task you can rehearse. It reflects the preparation guide's headings, not official weights.
| Domain Group | Domains | Rehearsal Task |
|---|---|---|
| Code module integration | 1, 2, 3, 4 | Create a custom type, pass it to a LabVIEW module, share data via shared memory |
| Callbacks | 5, 6 | Override one model callback and one engine callback from your own sequence file |
| Reporting | 7, 16 | Produce a clean report with only required result data, then configure its options |
| Structure and scope | 8, 9, 10, 11 | Call a subsequence using parameters, locals and a FileGlobal appropriately |
| Steps, groups, flow | 12, 13, 14, 15 | Combine step types, Setup/Main/Cleanup and conditional plus loop logic |
| Delivery | 17, 18 | Deploy and verify all dependencies are included |
| Troubleshooting | 19 | Fix a deliberately broken sequence |
| Concurrency and logic | 20, 21 | Run modules in parallel; write expressions for limits and conditions |
The official sample-exam ZIP is published on NI's site, and candidates in the NI forums discuss an SP25 Solar Panel sample. Those discussions are candidate experiences rather than issuer policy. Use the sample as one rehearsal, then build your own tasks from the table above so you are not memorizing a single scenario. You can also benchmark yourself with material on the main practice test site.
Scheduling the Domains Across Your Prep
If you only use one structured plan, sequence the domains by dependency. Foundations first, delivery last, because deployment and debugging expose weaknesses in everything before them. NI recommends 12-18 months of experience developing medium- to large-scale TestStand applications, and its Developing Test Programs Using TestStand course may substitute for six months of that. If you are short on hands-on time, the CTD Training overview can help you decide how to fill the gap. Eligibility details are in CTD Requirements 2026: Eligibility, Prerequisites & How to Qualify.
Data and code modules
- Domains 1-4: modules, custom types, shared memory
- Domain 21: expressions, since everything else leans on them
Sequence building blocks
- Domains 8-11: subsequences and variable scope
- Domains 12-15: step types, groups, flow control
Customization and output
- Domains 5-6: model and engine callbacks
- Domains 7 and 16: report content and configuration
- Domain 20: parallel execution
Delivery under the clock
- Domains 17-19: deployment, dependencies, debugging
- Full timed run of a four-hour practice project
Adjust the lengths to your experience; the ordering is the point. For a quick recap sheet to review between sessions, see the CTD Cheat Sheet 2026: One-Page Review of Must-Know Facts.
Exam-Day Mechanics That Touch Every Domain
- Delivery: Current delivery runs through Pearson VUE/OnVUE under NI's online certification exam policy. The CTD-specific credential page describes the exam as online only; test center availability for this exam was not verified.
- Environment: You need a private workspace, a webcam and one screen. A calculator and notepad are supplied inside the exam environment.
- Resources: Built-in TestStand Help, examples and templates are permitted. Externally prepared VIs and other outside resources are prohibited.
- Submission: Complete and save your work within the four-hour period and follow the current exam pack's packaging instructions.
- Grading: Practical submissions can take up to four weeks to grade.
- Fee: The current USD fee is not publicly verified. A historical price of USD 299 appeared in older PSI information, but that is not a current Pearson quote. See CTD Certification Cost 2026: Complete Pricing Breakdown.
Because permitted resources include the built-in Help and examples, the winning habit is knowing where in that Help each domain's guidance lives. Rehearse navigating it quickly. For a realistic sense of how demanding the format is, read How Hard Is the CTD Exam? Complete Difficulty Guide 2026. Aggregate pass rates are not publicly disclosed, and vendor success claims are marketing rather than issuer data; CTD Pass Rate 2026: What the Data Shows explains what can and cannot be said.
Frequently Asked Questions
NI does not publish individual topic percentages or a highest-weighted topic. The 21 headings are unweighted objectives from the preparation guide. The guide allocates 100 points to Functionality, so plan for breadth across all domains rather than betting on a few.
No. It is a four-hour performance-based practical in which you develop TestStand sequences on an NI-provided virtual machine and submit your completed work. Multiple-choice products sold by third parties resemble the former format and do not simulate the current practical.
The passing score is 70%. An older NI requirements document listing a 75% threshold and a two-year cycle is obsolete and should not be used. Details are in the passing score article linked above.
The credential is valid for three years. To renew, retake the CTD exam or earn 50 NI-approved TestStand activity points during your active certification cycle; points do not carry over.
No certification or degree is required. NI recommends 12-18 months developing medium- to large-scale TestStand applications, and the Developing Test Programs Using TestStand course may substitute for six months of that experience. For career context, see Is the CTD Certification Worth It? Complete ROI Analysis 2026.
Once you can build each task in the table without leaning on notes, put the full set under a four-hour clock using the CTD Exam Prep practice resources, and fix whichever domain slows you down first.