How would you test the heater shutdown requirement?
Turn a vague shutdown instruction into an observable result.
The question
You are reviewing a ground prototype for a fictional Earth observation instrument. The draft tells the controller to switch off a heater when it detects excess temperature.
- Draft requirementTurn the heater off promptly on an overtemperature signal.
- Bench summaryThe controller sent a shutdown command 160 ms after the trigger.
- Open itemThe note gives no measurable condition for when the heater is off.
“How would you test the heater shutdown requirement?”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: What would you clarify first?
What would you do here? Open the move you’d make.
Use the existing command time as the shutdown limit.
Tempting, but it misses something. A measured command time is an observation. The requirement owner sets the limit.
Trace the trigger, end condition and time limit to the instrument requirement.
The strong move. This gives the team a criterion it can review and test.
Ask the test team to run the same procedure more times.
Tempting, but it misses something. More runs would measure the same endpoint and leave the requirement unclear.
See how a strong candidate says it
“Ask the instrument owner which sensor event starts the clock, what counts as off and how much time the requirement allows.”
Why it works: Each part affects how the team sets up the test and reads its result.
Step 2: What would you measure?
What would you do here? Open the move you’d make.
Capture the trigger, command and current with aligned timestamps.
The strong move. You can compare the software action with the result at the heater.
Use the command log as the end of the test.
Tempting, but it misses something. That measures when software acted and leaves the physical response unmeasured.
Inspect the current only after the run ends.
Tempting, but it misses something. A final value would leave the time to reach it unknown.
See how a strong candidate says it
“Put the sensor event, the command and measured heater current on the same time reference.”
Why it works: The command records a software action. Current can show when the heater stopped drawing the specified load.
Step 3: How does the agreed limit change the result?
The instrument owner confirms the internal limit. With the heater enabled, when either sensor reports at least 55°C, current must fall below 50 mA within 200 ms. An aligned capture shows the command at 160 ms and the current first below 50 mA at 235 ms.
What would you do here? Open the move you’d make.
Report a pass because the command was sent in 160 ms.
Tempting, but it misses something. The requirement uses measured current as its endpoint.
Conclude that the command delay caused the miss.
Tempting, but it misses something. The two timestamps locate the gap in time. They do not identify its cause.
Record a 35 ms miss at the measured current endpoint.
The strong move. This compares the correct observation with the approved criterion.
See how a strong candidate says it
“The measured current first fell below the limit at 235 ms. The 200 ms requirement was missed by 35 ms.”
Why it works: The 160 ms command is useful evidence about the controller. The requirement measures current at the heater.
Step 4: What belongs in the handoff?
What would you do here? Open the move you’d make.
Keep the requirement, test conditions and observed miss together.
The strong move. The reviewer can trace the decision back to the source and run.
Replace the capture with a single failed label.
Tempting, but it misses something. That discards the timing evidence the next investigation needs.
Raise the limit to match this run.
Tempting, but it misses something. The instrument owner must decide any change to the requirement based on the instrument need.
See how a strong candidate says it
“Link the clarified requirement to the procedure and capture. Record both timestamps and ask the subsystem owners to investigate the delay before agreeing the next test.”
Why it works: The record lets the next reviewer see which measurement drove the result.
The answer, in short
- Decision
- Judge the test against the time to reach the current limit.
- Because
- The physical endpoint took 235 ms against a 200 ms limit.
- What would change it
- A new controlled run or a change to the approved requirement.
Common traps
- Starting or ending the clock at the wrong event.
- Treating a timing difference as proof of a cause.
Check your answer
- What starts the clock?
- What counts as off?
- What did the current trace show?
- Who needs the result?
Last reviewed Nov 11, 2026