Guide · AI coding & owned software
Test a File-Upload Form Before Customers Use It
Check ordinary uploads, useful errors, private downloads, and the handoff to the person who receives the submission.
A file-upload form can look finished after one PDF makes it through. The more useful question is whether a customer can submit the right material, recover from an error, and know what happened afterward. Test the whole path from the field on the page to the person receiving the file.
Say what you want before the upload
Tell the customer which file types and sizes you accept, and give the field a useful label. "Upload document" asks them to guess. "Upload the signed brief as a PDF" explains what belongs there and why they are being asked for it.
Try the form on a phone as well as a desktop. Check whether the customer can choose a file, understand the selected filename, and remove an accidental choice before submitting. If several files are permitted, make the count and per-file rules clear. Confirm that the layout still works with a long filename.
Try ordinary mistakes
Use harmless test files to check a permitted upload, a file at the size limit, an oversized file, an unsupported type, and a filename with spaces. Try submitting without a file when the field is required, then repeat the test when the field is optional.
Write down what the customer sees in each case. A generic failure message makes it hard to know what to fix. The form should explain the relevant problem without exposing internal details, and it should preserve the rest of the customer's input when that can be done safely.
Check what happens when the connection is interrupted. Does the page show a confirmed submission, a pending upload, or an error? It should not claim completion merely because the customer clicked the button. Repeat submission behavior also needs to be understood so an uncertain customer doesn't create a pile of duplicate requests.
Check protection on the server
Browser restrictions help guide the user, but they don't enforce the application's upload policy. OWASP recommends server-side controls such as allowed file types, size limits, safe generated filenames, appropriate storage, and access restrictions. It also cautions against trusting a supplied content-type value on its own.
Ask the person responsible for implementation to review those controls for the actual app and its use case. A functional test of a form is not a complete security assessment. Use the OWASP guidance linked below to structure that review and document the decisions your implementation makes.
Follow the file to its destination
Sign in as the person who receives submissions and find the test record. Open the attachment through the intended interface. Confirm that the file is connected to the correct request and that the recipient can tell which customer sent it.
Then check access from a role that should not see it. A private intake file should not become available merely because someone has guessed or copied its address. Confirm how the application authorizes downloads and what happens when access is removed.
Give the customer a clear finish
After a successful submission, explain what was received and what happens next. Only promise a response time or notification if the business has actually arranged it. Keep the confirmation distinct from any later approval of the submitted material.
Retain the test cases for future changes. A redesign, storage change, or new notification feature can break a path that previously worked. Repeating a small set of meaningful upload tests is easier when the expected results are already written down.