Test Cases for File Upload

When you design test cases for file upload, you are testing a high-risk boundary between user devices and your system. Uploads bring binary content, metadata, storage costs, malware risk, privacy exposure, and complicated UX states such as progress, cancel, retry, and partial failure. A green "uploaded" toast is not enough. You need confidence that the right file is accepted, the wrong file is rejected, storage is correct, and only authorized users can access the result.

This guide gives you a complete file upload test design approach: requirement questions, type and size matrices, positive and negative cases, drag-and-drop and multi-file flows, security and accessibility, storage verification, and common mistakes. Use it for profile images, document KYC uploads, attachments in tickets, bulk imports, and media libraries.

Why File Upload Bugs Are Expensive

Upload defects cause:

• Support load from blocked legitimate users.
• Storage of dangerous files.
• Broken previews and downloads.
• Privacy leaks when URLs are guessable.
• Corrupted imports that poison downstream systems.
• Mobile failures that desktop testing never saw.

Treat upload as a platform capability with security and reliability requirements, not a small form widget.

Capture the Upload Contract

Before cases, document the contract.

Example: profile avatar upload

Allowed types: JPG, PNG, WEBP. Max size 5 MB. Min dimensions 200x200. Max dimensions 4000x4000. Single file only. Image is cropped to square. Previous avatar is replaced. Only the account owner can upload or delete.

Example: KYC document upload

Allowed: PDF, JPG, PNG. Max 10 MB each. Up to 3 files. Virus scan required. Status moves to under review after success. Files are private to user and admin reviewers.

Contract checklist

1. Allowed extensions and MIME types.
2. Max file size per file.
3. Max total size per request or per day.
4. Min/max dimensions for images.
5. Max page count for PDFs if any.
6. Single vs multiple files.
7. Replace, append, or version behavior.
8. Required vs optional.
9. Storage location and retention.
10. Who can download after upload.
11. Virus scanning and quarantine flow.
12. Preview requirements.
13. Filename sanitization rules.
14. Async processing expectations.

If any item is unknown, stop and ask. Guessing upload security rules is how holes ship. For general case craft, see how to write test cases.

Scenario Map for File Upload

Happy path scenarios

• Upload valid file via picker.
• Upload valid file via drag-and-drop.
• Upload valid file on mobile.
• Replace existing file.
• Upload multiple valid files if allowed.
• Preview after upload.
• Download after upload.

Validation scenarios

• Unsupported extension.
• Allowed extension with wrong content type.
• Oversized file.
• Zero-byte file.
• Empty submission with no file when required.
• Dimension too small/large for images.
• Corrupt file that cannot be parsed.
• Password-protected PDF if unsupported.

UX and state scenarios

• Progress indicator.
• Cancel in-flight upload.
• Retry after failure.
• Network disconnect mid-upload.
• Double submit.
• Remove selected file before submit.
• Leave page during upload.

Security scenarios

• Malicious extension tricks.
• Path traversal filenames.
• Oversized zip bombs if archives allowed.
• Unauthorized API upload.
• Public URL access control.
• SVG/script content if SVG allowed.

Permission and privacy scenarios

• Owner can access.
• Other user cannot access.
• Admin role can access if intended.
• Signed URL expiry if used.

Test Data Fixtures You Should Prepare

Create a small fixture library in your test assets (safe, non-malicious files):

Fixture	Purpose
valid-small.jpg	Happy path image
valid-max-under.pdf	Near max size valid doc
oversize.pdf	Over limit
zero-byte.txt	Empty file
valid.png / valid.webp	Type matrix
not-allowed.exe or .js renamed carefully as disallowed sample	Type rejection
double-ext.pdf.exe	Double extension handling
huge-dimensions.jpg	Dimension limit
tiny-dimensions.png	Min dimension
corrupt.jpg	Parse failure
name-with-spaces and ünicode.pdf	Filename handling
long-filename-....pdf	Filename length

Never store real malware in ordinary repos. If AV testing is required, use organization-approved safe test patterns and isolated environments.

Test Cases for File Upload: Core Positive Coverage

ID	Title	Preconditions	Expected
TC-UP-001	Upload valid allowed file via picker	User on upload form	Success state, file stored, metadata correct
TC-UP-002	Upload valid allowed file via drag-and-drop	Dropzone enabled	Same acceptance as picker
TC-UP-003	Upload each allowed type	Fixtures for every allowed type	Each type succeeds
TC-UP-004	Replace existing file	Prior file exists	New file active, old handled per policy
TC-UP-005	Upload then preview	Preview supported	Preview matches uploaded content type
TC-UP-006	Upload then download	Download allowed	Downloaded content integrity OK
TC-UP-007	Optional upload skipped	File optional	Form submits without file
TC-UP-008	Multiple valid files	Multi enabled	All accepted within limits

Detailed happy path

Test Case ID: TC-UP-001
Title: Verify user can upload a valid PNG under the size limit
Requirement Reference: PROF-AVATAR-01
Priority: High
Type: Positive
Preconditions:
  - User is logged in
  - Avatar upload allows PNG up to 5 MB
Test Data:
  - valid-small.png (about 200 KB, 400x400)
Steps:
  1. Open profile settings.
  2. Choose upload avatar.
  3. Select valid-small.png from the file picker.
  4. Confirm crop/save if shown.
  5. Reload profile page.
Expected Result:
  - Upload progress completes without error.
  - Success confirmation is shown.
  - New avatar is visible on profile.
  - Stored object is PNG within allowed dimensions.
  - Only the owner can access the private storage URL if avatars are private.

File Type Validation Cases

Type checks must be stronger than "ends with .pdf".

ID	Title	File idea	Expected
TC-UP-010	Allowed extension accepted	.pdf real PDF	Success
TC-UP-011	Disallowed extension rejected	.exe, .bat, .js	Rejected with clear message
TC-UP-012	Uppercase extension	.PNG	Accepted if case-insensitive policy
TC-UP-013	No extension	document	Rejected or sniffed per rule
TC-UP-014	Double extension	report.pdf.exe	Rejected for executable types
TC-UP-015	Spoofed extension	EXE bytes named .jpg	Server rejects based on content sniffing if required
TC-UP-016	MIME mismatch	PNG content with .jpg name	Per strictness policy
TC-UP-017	SVG with script if SVG allowed	SVG containing JS	Blocked or sanitized
TC-UP-018	HTML renamed as txt if txt allowed	HTML content	Safe handling, no execute on download page

If the product claims content sniffing, test it. If it only checks extension, document that risk and still test extension matrix thoroughly.

Size Limit and Boundary Cases

Boundaries matter. Use boundary value analysis and equivalence partitioning.

Assume max = 5 MB.

ID	Title	Size	Expected
TC-UP-020	Just under max	5 MB - 1 KB	Accepted
TC-UP-021	Exact max	exactly 5 MB	Accepted if rule is <=
TC-UP-022	Just over max	5 MB + 1 KB	Rejected
TC-UP-023	Zero-byte file	0 bytes	Rejected for most business uploads
TC-UP-024	Tiny valid file	few KB valid type	Accepted if otherwise valid
TC-UP-025	Multiple files total over limit	sum > total cap	Rejected appropriately
TC-UP-026	Client and server both enforce	bypass client with API	Server still rejects oversize

Expected results should include:

• User-visible error.
• No orphan partial objects left visible as complete.
• No crash or gateway raw error page.

Image-Specific Cases

ID	Title	Expected
TC-UP-030	Below min dimensions	Rejected
TC-UP-031	Exact min dimensions	Accepted
TC-UP-032	Above max dimensions	Rejected or auto-resized per rule
TC-UP-033	Extreme aspect ratio	Accepted or rejected per rule
TC-UP-034	Animated GIF if not allowed	Rejected
TC-UP-035	CMYK JPEG if unsupported	Clear failure or conversion
TC-UP-036	EXIF rotation respected or normalized	Display upright per product choice
TC-UP-037	Cropper enforces required output	Final stored image meets size rules

Document-Specific Cases

ID	Title	Expected
TC-UP-040	Valid PDF text doc	Accepted
TC-UP-041	Password-protected PDF	Rejected if unsupported
TC-UP-042	PDF over page limit	Rejected if limited
TC-UP-043	Corrupt PDF	Rejected safely
TC-UP-044	Embedded macros in office docs if allowed types include office	Policy-based block/scan
TC-UP-045	CSV import with valid schema	Rows processed
TC-UP-046	CSV with missing required columns	Validation errors, no partial silent import if forbidden

For import uploads, validate both file acceptance and business row processing.

Multi-File, Order, and Quota Cases

ID	Title	Expected
TC-UP-050	Upload max allowed count	All succeed
TC-UP-051	Upload max count + 1	Extra rejected or blocked before send
TC-UP-052	Remove one selected file pre-upload	Remaining upload correctly
TC-UP-053	Duplicate filename in same batch	Accepted with unique storage keys
TC-UP-054	Daily quota exceeded	Rejected with quota message
TC-UP-055	Parallel uploads	Consistent final state, no lost files

Progress, Cancel, Retry, and Network Cases

ID	Title	Expected
TC-UP-060	Progress updates during large valid file	User sees progress or busy state
TC-UP-061	Cancel mid-upload	No completed file, UI reset cleanly
TC-UP-062	Retry after failure	Succeeds without duplicates beyond policy
TC-UP-063	Disconnect network mid-upload	Recoverable error, no fake success
TC-UP-064	Slow network complete	Eventually succeeds, no double entity
TC-UP-065	Double click upload button	Single logical upload

These cases catch some of the worst "ghost attachment" bugs.

Drag-and-Drop Specific Cases

ID	Title	Expected
TC-UP-070	Highlight on drag over	Visual affordance
TC-UP-071	Drop valid file	Accepted like picker
TC-UP-072	Drop invalid type	Rejected with same rules
TC-UP-073	Drop multiple when only single allowed	Reject or accept first per rule
TC-UP-074	Drop folder	Rejected if folders unsupported
TC-UP-075	Drop outside dropzone	No unexpected upload
TC-UP-076	Keyboard alternative exists	Users can upload without drag

Drag-and-drop must never be the only accessible path.

Filename and Metadata Cases

ID	Title	Filename idea	Expected
TC-UP-080	Spaces in name	my file.pdf	Accepted, stored safely
TC-UP-081	Unicode name	résumé.pdf	Accepted, download name sane
TC-UP-082	Very long name	255+ chars	Rejected or truncated safely
TC-UP-083	Path traversal name	../../etc/passwd.pdf	Sanitized, no path escape
TC-UP-084	Special characters	invoice#1 (final).pdf	Safe storage key
TC-UP-085	Right-to-left override chars	tricky unicode	No spoofed extension UI confusion

Filenames are an attack surface and a UX surface at once.

Security Test Cases for File Upload

Security deserves its own pack.

ID	Title	Expected
TC-UP-090	Unauthorized user upload API	401/403, no storage
TC-UP-091	Upload to another user's resource id	Rejected
TC-UP-092	Download by non-owner	Denied
TC-UP-093	Guessable sequential URL	Cannot access others' files
TC-UP-094	Content-Disposition safe download	Not executed inline if dangerous
TC-UP-095	Stored XSS via filename on listing page	Escaped rendering
TC-UP-096	Malicious content scanning path	Quarantine/reject per policy
TC-UP-097	Oversize bomb / highly compressed archive if zip allowed	Rejected or resource protected

Filename traversal examples to attempt:
../../secret.pdf
..\\..\\secret.pdf
%2e%2e%2fsecret.pdf

Expected: stored object key is sanitized, file cannot escape storage root, download names remain safe.

Privacy, Permissions, and Lifecycle

ID	Title	Expected
TC-UP-100	Owner deletes file	File no longer accessible
TC-UP-101	After delete, old URL fails	404 or denied
TC-UP-102	Account deletion cascade	Files removed or retained per policy
TC-UP-103	Admin reviewer access for KYC	Allowed with audit if required
TC-UP-104	Support agent without permission	Denied

Upload testing is incomplete without download authorization testing.

Accessibility and Mobile Cases

ID	Title	Expected
TC-UP-110	File input has accessible name	Screen reader can identify control
TC-UP-111	Error messages announced	Failures are perceivable
TC-UP-112	Keyboard upload path	Can trigger picker and complete flow without mouse
TC-UP-113	Focus after error	Moves to useful place
TC-UP-114	Mobile camera capture if enabled	Can capture and upload image
TC-UP-115	Mobile file picker from gallery	Succeeds for allowed types
TC-UP-116	iOS/Android size quirks	HEIC handling matches policy

HEIC images from iPhones are a classic production surprise when only desktop PNG/JPG were tested.

Async Processing and Status Cases

Many systems process uploads asynchronously (scan, transcode, thumbnail).

ID	Title	Expected
TC-UP-120	Status shows processing	Intermediate state visible
TC-UP-121	Processing success	Ready state, preview available
TC-UP-122	Processing failure	Failed state, retry guidance
TC-UP-123	User navigates away during processing	Final state still consistent on return
TC-UP-124	Webhook/worker delay	No false permanent failure before timeout policy

Test the state machine, not only the HTTP 200 on the initial upload.

API-Level Upload Cases

If APIs exist:

• Missing auth header.
• Wrong content type multipart boundary issues.
• Extra fields / mass assignment.
• Oversized body.
• Uploading without required entity id.
• Idempotency keys if supported.

UI may block bad types while API still accepts them. That gap is a defect for public APIs.

Prioritizing File Upload Suites

Priority	Cases
P0	Valid upload, disallowed type, oversize, required empty, owner download authz
P1	Replace/delete, multi-file limits, cancel/retry, dimension limits, mobile happy path
P2	Unicode filenames, drag-and-drop nuances, HEIC, async edge timing
P3	Rare codec quirks, deep performance of huge batches

Automate P0 with fixtures in CI where possible.

Mapping Uploads into Larger Flows

Uploads often sit inside registration, KYC, support tickets, or profile completion. Connect cases to those flows. For example, registration may require an ID document later, while profile forms reuse text field rules from other suites such as test cases for a registration form.

End-to-end example:

1. User registers.
2. User uploads KYC PDF.
3. Status becomes under review.
4. Admin downloads securely.
5. User cannot modify after lock if policy says so.

Common Mistakes When Writing Test Cases for File Upload

Mistake 1: Testing only one happy file on desktop Chrome

Misses type spoofing, mobile HEIC, and authz.

Mistake 2: Extension-only thinking

Real validation needs content awareness for security-sensitive apps.

Mistake 3: No size boundaries

Teams test a tiny file and a "big" file without exact limits.

Mistake 4: Trusting UI success without storage checks

Verify retrieval, metadata, and permissions.

Mistake 5: Ignoring delete and replace

Old file URLs and orphan objects create privacy and cost issues.

Mistake 6: Forgetting accessibility

Drag-and-drop only widgets exclude keyboard users.

Mistake 7: No cancel/disconnect cases

Real networks fail. Upload UX must fail honestly.

Mistake 8: Putting malware samples in shared repos casually

Follow security process and isolated environments.

Mistake 9: Vague expected results

"Error shown" is weak. State that file is not stored and previous file remains intact if replace failed.

Sample Starter Suite (Copy and Extend)

1. TC-UP-001 Valid upload picker.
2. TC-UP-002 Valid drag-and-drop.
3. TC-UP-011 Disallowed type.
4. TC-UP-015 Spoofed extension content mismatch if in scope.
5. TC-UP-021 Exact max size.
6. TC-UP-022 Over max size.
7. TC-UP-023 Zero-byte rejected.
8. TC-UP-004 Replace existing.
9. TC-UP-061 Cancel mid-upload.
10. TC-UP-092 Non-owner download denied.
11. TC-UP-083 Path traversal filename sanitized.
12. TC-UP-114 Mobile gallery upload.
13. TC-UP-120 Processing status if async.
14. TC-UP-112 Keyboard accessible path.

Fourteen solid cases already beat ad hoc clicking.

Defect Reporting Tips for Upload Failures

Include:

• Exact filename, size, type, and hash if useful.
• Browser/OS.
• Whether failure was client or server message.
• Network HAR snippet if possible.
• Whether file appears in storage/admin.
• Timestamp for async jobs.

Structure matters; use how to write a bug report so developers can reproduce binary issues quickly.

Automation Notes

Automation recipe:
1. Keep fixtures under version control (small files).
2. Use deterministic names and sizes.
3. Assert:
   - UI success/failure message or state
   - Resulting file list count
   - API metadata (content type, size)
   - Authorized GET succeeds
   - Unauthorized GET fails
4. Clean up uploaded objects after test.

Avoid asserting wall-clock upload duration tightly in CI. Assert completion and correctness.

Practice Drill

In one hour on a staging app with upload:

1. Write the upload contract from observed UI copy.
2. Build a fixture set of 8 files.
3. Execute type matrix and size boundaries.
4. Attempt non-owner access to a downloaded link.
5. Produce 12 formal cases with priorities.
6. List three open security questions for the team.

For repeated scenario design practice under timeboxes, try QABattle sign-up and convert battle notes into upload suites you can reuse at work.

Review Checklist

• Allowed and disallowed types covered.
• Size boundaries covered.
• Zero-byte and corrupt files covered.
• Multi-file and quota rules covered if present.
• Drag-and-drop and picker both covered.
• Cancel/retry/network failure covered.
• Authz for upload and download covered.
• Filename sanitization covered.
• Mobile and accessibility covered.
• Async processing states covered if relevant.
• Fixtures documented and safe.
• Expected results include storage and access outcomes.

Conclusion

Strong test cases for file upload protect usability, storage integrity, and security together. Start from a clear upload contract, build type and size matrices, verify progress and failure states, and always check what happens after the file lands: preview, download, permissions, replace, and delete. Client UI checks are necessary but not sufficient; server enforcement and authorization complete the story.

If your suite can prove that good files get in, bad files stay out, and only the right people can read what was stored, you have covered the heart of upload quality. Expand from that core into image dimensions, import parsing, virus scanning workflows, and mobile capture as your product requires.