How would you test caption timing after replacing a scene in a browser video editor?

I am interested in a small, reproducible test plan for caption timing after a scene replacement in a browser video editor. A preview can look fine while the original scene is present, then become confusing when someone swaps an image, shortens a section, or changes a narration sentence. The difficult part is separating a presentation issue from a timeline issue without turning every check into a full production review.

For context, I work on Faceless Reels AI, a browser-based studio for AI-assisted scripts, narration, captions and editable scenes. The question below is about a proposed testing approach, not a claim that every described control or behavior is already implemented in the product. The product context is here:

https://facelessreels-ai.com/

I would like feedback on the smallest set of tests that would reveal a meaningful regression. I would rather have six understandable cases with clear expected results than a large collection of screenshots that nobody can interpret when a build changes. Here is the plan I would start with, including the places where I am uncertain.

1. Establish a deliberately boring baseline

Use a short, synthetic script that contains no real customer information. Give each sentence a distinct meaning so that a reviewer can tell which caption belongs to which part of the narration. For example, one sentence introduces a paper notebook, another describes a blue folder, and a final sentence asks the viewer to save a checklist. Use owned or properly licensed media and avoid real people's names.

Record the initial scene order, the intended sentence-to-scene association, and a few visible landmarks. These do not need to be sophisticated timing measurements. A simple record saying that a caption starts with its matching spoken sentence and does not cover an important object is already better than an undocumented impression that the preview looked normal.

2. Replace a scene without changing the words

The first mutation should change only the visual material. Keep the script and narration unchanged and replace one scene with another image or clip that has a different composition. Choose a replacement with something important near the lower part of the frame, because this makes caption placement problems easier to notice.

The expectation is not that every composition automatically works. The useful question is whether the editor keeps the existing timing relationship, presents the new composition honestly, and gives the author enough information to make an adjustment. A caption overlapping a newly introduced subject is a review issue, while a caption unexpectedly jumping to a different sentence is a different kind of problem. I would log them separately.

3. Change one sentence and observe what remains attached

Next, alter a sentence in the synthetic script. Make it clearly longer, but keep the intended message similar. The test should distinguish between information that the editor preserves and information that the author needs to regenerate or review. I would avoid assuming that any particular product automatically recalculates narration, captions, or scene lengths.

An acceptable workflow might explicitly ask for a new narration pass. Another might preserve some edits while marking related elements as needing attention. What I would regard as risky is an interface that appears finished while silently keeping an old spoken sentence beside newly edited caption text. The expected result should describe the visible state, not prescribe an implementation that the product never promised.

4. Review once with sound and once without it

For the sound-on pass, listen for whether the visible words correspond to the spoken idea. Check a few clear transitions rather than attempting to judge every fraction of a second by feel. Pay particular attention to the beginning of a sentence, where a late caption can make a short clip harder to follow.

For the sound-off pass, ask whether the central point still makes sense. This is not a demand to duplicate every sound in a caption. It is a way to catch a missing instruction, a clipped final word, or text that disappears before a reader can reasonably understand it. Proper names, numbers and negative words deserve specific attention because a small transcription mistake can reverse the intended meaning.

5. Test layout separately from timing

I would keep at least two composition cases: a quiet background and a visually busy background. Then I would review them at the actual size a person is likely to use, rather than trusting a large desktop preview. Small text, weak contrast and long lines are much easier to miss when the preview occupies most of a monitor.

A safe-area check should also be explicit. Platform interfaces may place controls or descriptions over a video, so important text should not depend on every edge being unobstructed. This is a conservative authoring check, not a promise that one layout will fit every destination forever. If the destination's own preview is available during a normal publishing workflow, that remains useful evidence for that destination.

6. Include one interrupted editing session

A small test plan should include an interruption because creators rarely work in one perfectly continuous sitting. Make a harmless scene adjustment, move away from the current editor view using its ordinary controls, and return through the supported workflow. Check what the interface says has been retained before assuming anything about persistence.

I would not use this test to infer unlimited storage, permanent retention, version history or recovery guarantees. Instead, the expected result should follow the product's stated saving behavior. If a save or regeneration step is required, include that step in the test. A reviewer should be able to explain whether an observed difference comes from a missed step or an actual inconsistency.

7. Keep preview and output evidence distinct

Where an ordinary output or download step is available, compare the result with the preview using the same small set of landmarks. Do not assume that a successful preview proves the output has the same caption placement or timing. Equally, do not treat an output setting the product does not offer as a defect merely because another editor supports it.

The comparison can remain lightweight: first sentence, scene replacement boundary, longest caption, and final instruction. Record the selected settings when they are visible. I would avoid invented precision such as reporting a frame-level offset without a reliable measurement method. A clear observation that a caption belongs to the wrong scene is more useful than an impressive-looking number based on guesswork.

8. Make each report reproducible

A useful report would include the synthetic script, the scene that changed, the exact supported action, the observed result, and the expected result. It should also identify the browser and relevant visible settings. There is no need to include credentials, private project links, personal photographs or raw account data in a public discussion of the test.

I would attach a small owned example only if it directly clarifies the issue. Repeating the entire editing session in a long recording may be less helpful than a concise before-and-after comparison. The important distinction is between evidence and interpretation: what appeared on screen, what the person expected, and which product behavior the test was actually exercising.

My main uncertainty is prioritization. If you had time for only a handful of checks after changing scene-editing behavior, would you put sentence alignment, caption readability, interruption handling or preview/output agreement first? I am especially interested in inexpensive cases that catch a class of failures rather than one unusual visual example. The goal is a test plan another person can repeat and understand, not a claim that AI-generated drafts can skip human review.