Media tagging PR1 QA
Media tagging PR1 QA
Section titled “Media tagging PR1 QA”Check that PR #3604 works in preview through the main media-tagging journey. Use one small sample. PR2 prompt provenance and PR3 prompt analysis are outside this check.
Before QA starts
Section titled “Before QA starts”Engineering provides:
- The preview links, test account and exact deployed revision.
- One supported image, one short video and one complete carousel. Use the image as an enrolled internal Brain Generation that is not yet published in the catalogue.
- A simple before/after sheet with media links, resulting tags, processing status, provider-call count and cost. Record the catalogue categories and explicitness for comparison.
Engineering handles enrollment, the approved test policy, sync/recovery and cleanup. QA does not need to run SQL or configure workers. There is no semantic-tag viewer in Fennec yet, so inspect the supplied results alongside the media.
Use existing results from the same reviewed revision where applicable. Do not repeat the previous paid batch just to produce another report. Close the missing live Brain-to-publication and carousel coverage within the approved sample and budget.
Four checks
Section titled “Four checks”| Check | What QA does | Expected result |
|---|---|---|
| 1. Media results | Open the image, video and carousel. Compare each with its exported tags. | Processing completes. The tags describe the visible content without obvious unrelated labels. Record an empty or unsupported result and its reason for assessment. |
| 2. Brain before publication | Confirm the Brain image already has tags while absent from the catalogue. Publish the matching example and wait for engineering to confirm sync/reconciliation completed. | Publication succeeds. The published example reuses the matching tags without an additional provider call. |
| 3. Repeat processing | Ask engineering to repeat normal sync and recovery for unchanged examples. Compare the before/after sheet. | Tags remain available. No additional provider call or paid attempt occurs, and sample cost stays unchanged. Engineering keeps spare approved budget so an exhausted cap cannot hide a duplicate. |
| 4. Existing behavior | Open a published example and generate from it. Compare categories, explicitness and catalogue visibility before and after tagging. Repeat publication/generation with tagging paused. | Existing behavior remains correct. Tagging does not change categories or explicitness. Publication and generation still work while tagging is paused. |
Here, unpublished Brain output is approved internal-authoring media, not customer-private gallery media. No broad quality benchmark or catalogue backfill is required for this QA pass.
Already covered by automated tests
Section titled “Already covered by automated tests”Engineering attaches passing results for the reviewed revision. QA does not repeat fault injection, concurrency, retries, timeouts, budget limits, enrollment/opt-out, source-change invalidation, deletion, rollback or migration/FK checks.
See the engineering test sources and storage tests. If code or relevant configuration changes, engineering repeats affected checks.
Record the result
Section titled “Record the result”Mark each check PASS, FAIL or NOT RUN. Include the deployed revision, fixture IDs and before/after sheet. For a failure, include the steps, expected result and actual result. Engineering pauses the test policy and records any unsettled costs after the check.
This is functional acceptance of PR1. A small sample does not establish tag accuracy across the whole catalogue. Production activation remains a separate decision. Engineering setup and operations are described in the deployment runbook.