- The Format in One Glance
- Numbers Worth Memorizing
- The 21 Objectives, Grouped for Fast Review
- Code Modules, Data Types and Shared Memory
- Sequence Logic, Variables and Step Types
- Callbacks, Reports and Debugging
- Deployment, Dependencies and Packaging
- Exam-Day Rules and Pacing
- Renewal, Cost and Prerequisites
- A Domain-Ordered Review Plan
- Quick-Answer FAQ
- The Certified TestStand Developer exam is a four-hour practical build, not a multiple-choice test.
- The passing score is 70%, and the preparation guide allocates 100 points to Functionality.
- Only TestStand Help, examples and templates are permitted; externally prepared VIs are prohibited.
- Certification lasts three years; renew by retaking CTD or earning 50 NI-approved activity points.
The Format in One Glance
Certified TestStand Developer (CTD) is issued by National Instruments. Since April 30, 2020, it has been a four-hour, performance-based exam. You are not answering a fixed list of questions. You are building working TestStand sequences, completing them, saving them, and packaging the submission according to the current exam pack's instructions.
That distinction matters because several third-party sites still sell multiple-choice "practice exams" that resemble the former format. A question dump cannot rehearse the real task of wiring a sequence together under time pressure. If you want the full preparation roadmap, start with our CTD study guide, then return here for a compressed review.
| Item | Certified TestStand Developer fact |
|---|---|
| Issuer | National Instruments (NI) |
| Format | Practical TestStand sequence development |
| Duration | Four hours |
| Question count | Not applicable; no fixed item count or scored/unscored split |
| Passing score | 70% |
| Software baseline | TestStand 2019 or later per the preparation guide |
| Prerequisite certification | None |
| Validity | Three years |
| Grading turnaround | Up to four weeks, per current online guidance |
Numbers Worth Memorizing
A practical exam has few numbers to memorize, which is exactly why the few that exist deserve attention. Burn these in:
- 4 hours: the full window to build, save and package. Packaging is part of your time budget, not an afterthought.
- 70%: the passing threshold. Details are in our CTD passing score breakdown.
- 100 points: the allocation the preparation guide gives to Functionality. It is not 100 questions, and it is not a set of per-domain percentages.
- 3 years: how long the credential stays valid.
- 50 points: the NI-approved TestStand activity points needed to renew without retaking, earned during the active cycle.
- 12-18 months: NI's recommended experience building medium- to large-scale TestStand applications.
The 21 Objectives, Grouped for Fast Review
NI's preparation guide lists the top-level assessed capabilities under Exam Topics. They are unweighted, and the guide does not publish per-topic percentages or a highest-weighted topic. That means a one-page review should group the objectives by the work they involve. For a deeper walk through each one, see our complete guide to all 21 CTD content areas.
| Cluster | Objectives |
|---|---|
| Code module integration | Call LabVIEW code modules; pass custom data types to and from code modules; manage shared memory between TestStand and code modules; execute simple code modules in parallel |
| Data modeling | Create custom data types; proper use of parameters, local variables and FileGlobal variables; expressions |
| Sequence structure | Call a sub-sequence; proper use of step groups; control execution flow (if/else, looping) |
| Step types | Two or more different test step types; three or more different non-code module step types |
| Extensibility | Override and use model callbacks; override and use engine callbacks |
| Reporting | Create a clutter-free report with the proper result data; configure a report |
| Delivery and diagnosis | Deploy test system; dependency management; debug broken/error sequences |
Code Modules, Data Types and Shared Memory
Call LabVIEW Code Modules
The exam environment supplies LabVIEW driver libraries that simulate hardware, and no external hardware is part of the task. Your job is wiring the call correctly.
- Configure the LabVIEW adapter and select the right VI for the step.
- Map TestStand values to the VI's connector pane accurately.
- Confirm the step actually returns data you can compare or report.
Pass Custom Data Types To and From Code Modules
This objective ties the data-modeling work to the code-module work. Passing a container or custom type means the structure on the TestStand side must line up with what the VI expects.
- Match the type definition to the code module's input and output.
- Keep a single source of truth for the type so changes propagate.
- Verify values round-trip by inspecting them after the call.
Manage Shared Memory Between TestStand and Code Modules
Expect to move data between the sequence environment and code without losing track of ownership. Know where a value lives, who can change it, and how a code module reads it.
Create Custom Data Types
Build reusable types rather than scattering loose variables. A well-defined type pays off later when you pass it to a code module, store it in a variable and report from it.
Execute Simple Code Modules in Parallel
Parallel execution is one of the easiest objectives to over-engineer. Know how to configure steps or sequences to run concurrently and how to make sure results are collected before reporting.
Sequence Logic, Variables and Step Types
Variable Scope at a Glance
| Scope | Objective name | Use it when |
|---|---|---|
| Parameters | Proper use of Parameters | Data crosses a sub-sequence boundary |
| Local variables | Proper use of Local Variables | Data belongs to one sequence's execution |
| FileGlobal variables | Proper use of FileGlobal Variables | Multiple sequences in the same file must share data |
Scope mistakes are classic practical-exam errors because the sequence still looks plausible while behaving wrong. Choose the narrowest scope that does the job, and use parameters when you call a sub-sequence so the data flow is explicit.
Step Types, Groups and Flow
- Test step types: demonstrate at least two different kinds, such as Pass/Fail, Numeric or String.
- Non-code module step types: demonstrate at least three, such as Wait, Flow or Property Loader.
- Step groups: place steps in the correct Setup, Main or Cleanup group so cleanup always runs.
- Execution flow: implement if/else logic and looping with the proper flow steps.
- Sub-sequences: call them with correct parameters and keep sequences modular.
- Expressions: write accurate expressions for preconditions, post-actions and comparisons.
Callbacks, Reports and Debugging
Model Callbacks vs. Engine Callbacks
These are separate objectives and easy to blur together. Both are about overriding default behavior without editing the engine itself.
- Model callbacks: override and use them to customize behavior in the process model, such as what happens around a UUT run.
- Engine callbacks: override and use them to hook global events at the engine level.
- Know which file you override in and where the override belongs.
Reporting
Two objectives cover reports: creating a clutter-free report with the proper result data, and configuring a report. The key idea is selectivity. Include the results that matter and exclude noise.
- Decide which steps should contribute result data.
- Configure the report options to match the task requirements.
- Check the generated output, not just the settings.
Debug Broken or Error Sequences
Expect to inherit something that does not work. Use breakpoints, single-stepping and the variables display to find the fault rather than guessing. Reading error messages carefully usually points straight at a mismatched type, a bad path or a scope problem.
Deployment, Dependencies and Packaging
Two objectives, Deploy test system and Dependency management, are about making your work portable. A sequence that runs only on your build is not finished. Know how to gather every file the system depends on, such as sequences, code modules, types and configuration, so that nothing is missing when it runs elsewhere.
Do not confuse deployment skills with the exam submission step. The preparation guide names a packaging utility, CTD_StudentZipUp.exe, but the instructions in your current exam pack are what govern the actual submission. Follow those, and leave time to do it.
Key Takeaway
Reserve the last stretch of your four hours for saving, verifying and packaging. A strong build that is not submitted correctly does not help you. Treat the packaging steps as a required deliverable with their own time allocation.
Exam-Day Rules and Pacing
What You Can and Cannot Use
| Permitted | Prohibited |
|---|---|
| Built-in TestStand Help | Externally prepared VIs |
| TestStand examples and templates | Outside resources |
| Calculator/notepad supplied in the exam environment | Additional screens or non-private workspace |
The practical assessment runs on an NI-provided virtual machine that contains the required software and exam files. Current online guidance calls for a private workspace, a webcam and a single screen. The current delivery path runs through Pearson VUE/OnVUE under NI's online exam policy. The CTD-specific credential page describes the exam as online only, and while the newer general policy also mentions test centers subject to availability, center availability for CTD was not verified. Check scheduling details with our CTD exam dates and scheduling guide.
Pacing Rules of Thumb
- Read the entire task before building anything, so you know every deliverable.
- Build the skeleton first: sequence file, types and sub-sequence structure.
- Integrate code modules early, since integration problems take the longest to fix.
- Leave reporting and deployment polish for after core functionality works.
- Always keep a final buffer for saving and packaging.
For a sense of how demanding the format feels, read how hard the CTD exam is. NI does not publish an aggregate pass rate, which is why our CTD pass rate analysis separates verified facts from vendor marketing claims.
Renewal, Cost and Prerequisites
Prerequisites
There is no formal prerequisite certification, no mandatory degree and no published fixed training-hour total. NI recommends 12 to 18 months of experience developing medium- to large-scale TestStand applications, and the course Developing Test Programs Using TestStand may substitute for six months of that recommended experience. The course is preparation curriculum, not a replacement for the exam objectives. More detail is in our CTD requirements guide.
Cost
A current USD fee and member/nonmember pricing were not publicly verified. A historical figure of USD 299 appeared in an older PSI client information sheet from 2022, but that is not a current Pearson quote, so treat it only as a rough historical reference. Confirm the live price during registration. Our CTD certification cost breakdown explains what is and is not known.
Renewal
The credential is valid for three years. To renew, either retake the CTD exam or earn 50 NI-approved TestStand activity points during the active certification cycle. Points do not carry over from one cycle to the next. The authority is NI's Recertification Policy and Process, last updated April 30, 2026. Holders familiar with the older format should note that the cycle and renewal rules differ from the superseded two-year terms.
Career Value
No current CTD-only salary dataset or independently established certification premium was verified. General engineering salary figures should not be presented as CTD earnings. For a balanced view, see the CTD ROI analysis and the CTD salary guide.
A Domain-Ordered Review Plan
Because the exam is a build, organize review by dependency: you cannot report on data you never modeled, and you cannot deploy what you never integrated. This ordering is tied to the CTD objectives, not generic scheduling.
Data Foundations
- Create custom data types
- Parameters, local variables and FileGlobal variables
- Expressions
Code Module Integration
- Call LabVIEW code modules
- Pass custom data types to and from code modules
- Shared memory and simple parallel execution
Sequence Structure and Step Types
- Sub-sequences and step groups
- If/else and looping
- Test step types and non-code module step types
Extensibility, Reporting and Debugging
- Model and engine callbacks
- Report creation and configuration
- Debugging broken sequences
Delivery and Timed Runs
- Deploy test system and dependency management
- Full four-hour mock builds, including packaging
The official sample-exam ZIP is published through NI's preparation materials, and candidate discussions on NI's forums mention the SP25 Solar Panel sample. Those threads reflect candidate experience, not issuer policy. Build original timed projects beyond the sample, and use the CTD practice test site to reinforce the concepts behind each objective before your timed runs.
Quick-Answer FAQ
No. Since April 30, 2020, it has been a four-hour, performance-based exam where you develop and package TestStand sequences. A fixed question count does not apply.
The passing score is 70%. The preparation guide allocates 100 points to Functionality, which is not the same as 100 questions. See the passing score guide for detail.
NI lists them as unweighted exam topics. Individual topic percentages and a highest-weighted topic are unpublished, so prepare for all of them.
No. Built-in TestStand Help, examples and templates are permitted, along with the calculator/notepad in the exam environment. Externally prepared VIs and outside resources are prohibited.
The certification is valid for three years. Retake the exam or earn 50 NI-approved TestStand activity points during the active cycle; points do not carry over.
For related background, see what CTD certification is and our CTD training overview, and keep this page handy as a one-page refresher before each timed practice build.