A file picker can work perfectly while the video workflow around it is broken. The upload completes, a progress bar reaches the end, and the recipient opens a file with no sound or text too small to read.
Disclosure: I work on VideoBee. This article was written with AI assistance and fact-checked against the references below. The examples are hypothetical; they are not customer incidents, implementation details, or measured results from that product.
When building a video upload feature, treat file selection, acceptance, processing, playback, and recovery as separate things to check. A small test matrix makes those boundaries easier to see.
Start with the promise your interface makes
Imagine a hypothetical feedback portal that accepts short screen recordings. Before choosing test files, write down what the portal promises: which inputs it accepts, what limits apply, what happens after upload, and where the result should play.
“Supports video” is too vague to test. “Accepts these documented inputs, shows a useful error for unsupported files, and provides a playable review copy in these target environments” gives the team something observable.
Keep that contract near the interface. People should not have to discover the size limit after sending most of a large file. If processing changes the original, explain what the downloadable result represents.
Separate the file extension from the media inside
MP4 is a container format. The audio and video streams inside it have their own encoding formats. A filename ending in .mp4 does not, by itself, describe every characteristic that affects playback. MDN's media container guide explains this distinction.
For each test fixture, record what you know: source, container, audio and video encoding when available, dimensions, duration, and file size. Keep unknown values explicitly unknown. Do not infer an encoding from the filename.
This turns “the MP4 failed” into a more useful observation: a particular fixture failed in a particular environment. It also helps avoid repeatedly testing several files that happen to exercise the same easy case.
Build a small matrix with a reason for every row
Start with a few representative fixtures rather than a folder full of random videos. Each row should answer a specific question.
| Fixture | Question | What to inspect |
|---|---|---|
| A short recording with speech | Does the normal path work? | Upload, processing, picture, and sound |
| A recording with small UI labels | Is the delivered copy still useful? | Readability at the recipient's viewing size |
| A portrait clip | Does the layout handle its shape? | Orientation, framing, and player controls |
| A valid file near the documented size boundary | Is the limit applied consistently? | Actual acceptance and the displayed explanation |
| A file just beyond that boundary | Is rejection understandable? | Error text, retained state, and next action |
| An unsupported or invalid fixture | Does failure remain controlled? | A clear rejection rather than a stuck workflow |
Add a fixture when it covers a meaningful gap. A missing audio track, for example, should not automatically be treated as the same situation as audio that exists but cannot be played.
Use synthetic or explicitly cleared material. A reproducible fixture should not contain a customer's desktop, an internal recording, or an accidental notification.
Test the picker and the actual acceptance rules
The HTML accept attribute helps guide file selection. It is not a substitute for validation. As MDN's file input documentation explains, users may be able to override the picker filter, so the application still needs appropriate server-side validation when accepting uploads.
Check the paths your interface actually offers. If it supports drag and drop as well as a file picker, verify both against the same contract. A helpful filter in one path should not hide inconsistent handling in another.
Treat an invalid test fixture as expected input to a test, not an invitation to accept everything. The useful outcome is a controlled response with an explanation and a way forward.
Make recovery part of the feature
An interrupted connection is a separate case from an unsupported file. A processing failure is separate from an upload failure. Give these states different test rows and ask what the person can do next.
For the hypothetical portal, check what happens when someone cancels, selects another file, navigates away, or retries after a failure. Does the interface make the active task clear? Could an old error be mistaken for the status of the replacement file?
Do not label a workflow “resumable” merely because a Retry button exists. Test the behavior you intend to promise, and describe that behavior precisely.
Finish where the recipient finishes
Open the actual delivered copy in each environment you support. Check its beginning, a meaningful point in the middle, and its ending. Listen if audio matters. Pause on the smallest important detail. Confirm that access permissions allow the intended recipient to retrieve it.
Record the fixture, environment, expected result, observed result, and date. Keep observations separate from explanations: “audio was absent in this player” is evidence; a proposed cause still needs investigation.
The upload button is the entrance to the workflow. A useful test matrix follows the file far enough to show whether the person on the other end can actually use it.
Top comments (0)