Which copy of a chart test does `helm test` run - your working tree's or the release's?

## Where the test definition lives When Helm installs or upgrades a release it renders the chart once and stores the result. That storage record - by default a Secret named `sh.helm.release.v1.<name>.v<rev>` in the release's namespace - holds the release's manifest, the values it was rendered with, its chart metadata, and its **hooks** as already-rendered manifests. Test resources are hooks, so a chart's tests are part of that stored record. `helm test` uses it. The command loads the release, filters its stored hooks down to the ones marked as test hooks, and creates those. It reads no chart directory, no packaged archive and no repository. That is why the command takes a release name and not a path, and why it works fine in a shell that has never seen the chart. ## Consequence one: no chart checkout needed Anyone with cluster access and the release name can smoke-test it. An on-call engineer investigating a payments release at 02:00 does not need to find which chart version it came from, clone anything, or match a values file - `helm test <release> -n <namespace>` is enough, and what runs is exactly what that release was installed with. For a chart that wraps a vendor image and is assembled from a large environment-specific values file, that property is worth a lot: there is no risk of testing a locally rendered variant instead of the deployed one. ## Consequence two: local edits are inert This is the surprise that makes the question interesting. Someone iterating on a failing test edits the test manifest under `templates/tests/`, re-runs `helm test`, and sees the identical failure - because the release still holds the old rendered copy. The edit only takes effect after an upgrade re-renders the chart and writes a new revision. There is no flag that makes the command pick up working-tree source; the loop for developing a test is edit, upgrade, test. The same applies to values. The test was rendered with the values that were in effect at install or upgrade time, so a values change you have not deployed is not reflected in the test that runs. ## Consequence three: rollback changes the test `helm rollback` produces a *new* revision whose content is copied from the target revision, hooks included. So after rolling back, `helm test` runs the restored revision's test, not the one from the revision you were on a minute ago. If the newer chart version had added or tightened a test, that assertion is gone until you roll forward again. This is worth knowing before you conclude from a green test that a rolled-back release is verified to the same standard as the version it replaced. ## Seeing what would run `helm get hooks RELEASE_NAME` prints the release's stored hook manifests, which is the direct way to answer "what will `helm test` actually execute?" It is also the honest check for whether a release carries any test at all - useful because a release with no tests passes silently. Reading that output beats reasoning about the chart source, because the chart source is not what runs. ## Framing it in an interview The crisp version is: `helm test` is a *release* operation, not a *chart* operation. Everything else follows. Candidates who think of Helm as a template renderer expect the command to render the chart again and are then confused by all three consequences above. Candidates who have internalised that a release is a stored, self-contained record of what was deployed get every one of them for free - and that framing is what the question is really probing.