How to Write Test Cases for Camera Integration (With Examples)
How to Write Test Cases for Camera Integration (With Examples)
How to Write Test Cases for Camera Integration (With Examples)
Testing camera integration is a critical part of mobile and web application quality assurance because the camera touches hardware, OS permissions, UI rendering, and often business logic such as barcode scanning, AR overlays, or media capture. A well‑designed test suite catches crashes, permission mishandles, orientation glitches, and performance regressions before they reach users. This guide walks you through the full lifecycle of creating high‑signal test cases: from requirement breakdown to a concrete test matrix, from manual execution to automated scripts, and finally to how autonomous exploration can extend coverage. Every section contains actionable advice, real‑world examples, and snippets you can copy into your own test repository.
How to Write Test Cases for Camera Integration (With Examples): Defining Scope and Objectives
Before writing any test case, clarify what “camera integration” means for your product. Are you capturing still images, recording video, scanning QR codes, applying filters, or streaming AR content? Identify the entry points (e.g., a floating action button that opens the camera, a menu item “Scan”, or a web‑based that triggers the device picker). List the functional requirements, non‑functional requirements (latency, battery impact, storage usage), and regulatory constraints (e.g., GDPR for facial data). Write each requirement as a short, testable statement. For example:
- REQ‑CAM‑01: The app shall request the CAMERA permission before opening the preview.
- REQ‑CAM‑02: After granting permission, the preview shall display at 30 fps on supported devices.
- REQ‑CAM‑03: Captured images shall be saved to the app‑private storage folder with a JPEG quality of 85 %.
- REQ‑CAM‑04: The app shall handle the case where the user denies the permission and show an inline explanation.
Trace each requirement to a unique ID; this ID will later appear in your test case table, ensuring traceability. Once the scope is frozen, decide on the test levels you need: unit (mocking the camera API), integration (real device or emulator), and system (end‑to‑end user flow). For most camera features, integration and system tests provide the highest return on investment because they exercise the hardware‑software boundary.
How to Write Test Cases for Camera Integration (With Examples): Anatomy of a Robust Test Case
A test case that survives multiple releases shares a common structure. Use this template for every camera‑related case:
| Field | Description | Example |
|---|---|---|
| ID | Unique identifier, often prefixed with the requirement ID | TC‑CAM‑001 |
| Title | One‑sentence summary of what is being verified | Verify camera opens after permission grant |
| Preconditions | Device state, app state, and any setup needed before step 1 | Device API ≥ 21, app installed, no existing camera permission |
| Test Data | Values that drive the test (e.g., resolution, file size) | Requested picture size: 1920×1080 |
| Steps | Numbered actions performed by tester or automation script | 1. Launch app → 2. Tap “Capture Photo” button → 3. System permission dialog appears → 4. Tap “Allow” |
| Expected Result | Observable outcome after the final step | Camera preview starts, UI shows shutter button, no crash |
| Post‑conditions | State that should hold after test (useful for chaining) | Camera preview active, permission granted |
| Priority | P0 (blocker), P1 (high), P2 (medium), P3 (low) based on risk | P0 |
| Type | Functional, negative, performance, security, accessibility, etc. | Functional |
| Automation Feasibility | Yes/No/Partial with notes | Yes – Appium can be clicked by UiAutomator2 |
Keep each field concise but complete. When you move to test management tools (e.g., Zephyr, Xray, or a simple spreadsheet), these columns become filterable attributes that let you generate dashboards, traceability matrices, and execution reports.
How to Write Test Cases for Camera Integration (With Examples): Positive Test Cases – Core Functionality
Positive test cases verify that the happy path works as specified. Below is a representative set; you will expand it based on your feature list. Each case assumes a clean device state (no lingering permissions, camera not in use by another app).
| ID | Title | Preconditions | Steps | Expected Result | ||
|---|---|---|---|---|---|---|
| TC‑CAM‑001 | Camera opens after permission grant | No camera permission, app at home screen | 1. Tap “Capture Photo” button 2. System permission dialog appears 3. Tap “Allow” | Camera preview starts within 2 seconds, UI shows shutter button | ||
| TC‑CAM‑002 | Photo capture saves JPEG with correct dimensions | Camera preview active, storage permission granted | 1. Tap shutter button 2. Confirm capture dialog (if any) 3. Return to gallery view | Image file appears in app‑private folder, dimensions 1920×1080, format JPEG, EXIF orientation correct | ||
| TC‑CAM‑003 | Video recording stops after max duration | Camera preview active, video mode selected, storage permission granted | 1. Tap record button 2. Wait for 30 seconds (configured max) 3. Auto‑stop occurs | Video file saved, duration 30 ± 0.5 s, codec H.264, audio track present | ||
| TC‑CAM‑004 | Switch between front and rear camera | Camera preview active (rear) | 1. Tap camera switch icon 2. Verify preview updates | Preview now shows front‑facing feed, no frame drop > 1 frame | ||
| TC‑CAM‑005 | Flash torch toggles on/off in preview | Camera preview active, flash mode set to auto | 1. Tap flash icon until torch ON indicator appears 2. Tap again to turn OFF | Torch indicator reflects state, preview brightness changes accordingly | ||
| TC‑CAM‑006 | Zoom pinch‑to‑zoom works smoothly | Camera preview active, zoom supported | 1. Place two fingers on preview 2. Spread apart to 2× zoom 3. Pinch back to 1× | Preview scales without tearing, focus remains stable, UI zoom indicator updates | ||
| TC‑CAM‑007 | Exposure slider adjusts brightness | Camera preview active, exposure control available | 1. Slide exposure bar to +2 EV 2. Capture a photo 3. Slide to –2 EV and capture second photo | First image noticeably brighter, second darker, histogram shift measurable | ||
| TC‑CAM‑008 | QR code scanning succeeds | Camera preview active, scanner mode enabled | 1. Point camera at a valid QR code encoding “https://example.com” 2. Hold steady for ≤ 1.5 s | App decodes URL, navigates to the web page, no false positives | ||
| TC‑CAM‑009 | Barcode (EAN‑13) scanning works | Camera preview active, barcode scanner enabled | 1. Align barcode within guide lines 2. Tap scan button | App returns correct 13‑digit numeric code, no timeout | ||
| TC‑CAM‑010 | AR overlay renders on preview | Camera preview active, AR session initialized | 1. Point camera at a known planar target 2. Wait for AR anchor acquisition | 3D model appears anchored to target, maintains pose under mild device motion | ||
| TC‑CAM‑011 | Capture in low‑light with night mode | Camera preview active, night mode toggle ON | 1. Frame a dimly lit scene (< 5 lux) 2. Tap shutter 3. Wait for processing | Saved image shows reduced noise, detail preserved, file size within expected range | ||
| TC‑CAM‑012 | Video recording with external microphone | Camera preview active, video mode, external mic connected via USB‑C | 1. Start recording 2. Speak into external mic 3. Stop recording | Audio track contains clear voice, no clipping, synchronization offset < 20 ms | ||
| TC‑CAM‑013 | Pause | Interrupt and resume video recording | Camera preview active, video mode | 1. Start recording 2. Press home button to background app 3. Wait 5 s 4. Restore app from recents | Recording pauses, resumes seamlessly, final file duration equals sum of segments | |
| TC‑CAM‑015 | Capture while device charging | Device plugged into charger, battery at 20 % | 1. Open camera 2. Take photo | Camera does not drop during capture image | ||
| TC‑CAM‑016 | Capture after rapid orientation changes | Camera preview active | 1. Rotate device 90° left, wait for UI to settle 2. Rotate 90° right, wait 3. Repeat 5 times 4. Take a photo | Preview remains upright, image saved with correct EXIF orientation, no UI glitch | ||
| TC‑CAM‑017 | Concurrent camera use with another app (share sheet) | Another app holding camera (e.g., video call) | 1. From that app, invoke share → “Send image” → chooses camera 2. System shows “Camera in use” toast 3. Cancel share | App handles gracefully, does not crash, user can retry after releasing camera | ||
| TC‑CAM‑018 | Permission rationale shown on denial | Camera permission denied previously | 1. Re‑open camera flow 2. System shows rationale dialog (if implemented) 3. Tap “Learn more” | Custom explanation screen appears, user can navigate to settings | ||
| TC‑CAM‑019 | Storage full handling | Device storage < 10 MB free | 1. Attempt to capture photo 2. System throws storage full error | App displays user‑friendly message, offers to free space or change storage location | ||
| TC‑CAM‑020 | Camera preview resumes after incoming call | Camera preview active | 1. Receive voice call 2. Accept call (camera backgrounded) 3. End call 4. Return to app | Preview restarts automatically, no black frame, shutter button functional |
This table already gives you twenty solid positive cases. Feel free to add more for specific features like live filters, time‑lapse, or HDR bracketing.
Negative and Error‑Handling Test Cases
Negative testing proves that your app behaves correctly when something goes wrong. Camera integration fails in many ways: missing hardware, permission denial, driver crashes, or unexpected OS behavior. Structure negative cases similarly to positives, but focus on the *invalid* input or *unexpected* state.
| ID | Title | Preconditions | Steps | Expected Result | |
|---|---|---|---|---|---|
| TC‑CAM‑N01 | App handles missing camera hardware | Device without camera (e.g., certain Android TV builds) | 1. Launch app 2. Navigate to camera feature | App shows a clear message “No camera available” and disables related UI | |
| TC‑CAM‑N02 | Graceful degradation when camera service crashes | Camera preview active, force stop media server via adb | 1. adb shell stop mediacodec 2. Try to capture photo | App receives error callback, shows toast “Camera unavailable, try again”, does not crash | |
| TC‑CAM‑N03 | Denied permission and persistently blocks camera | Permission denied, “Don’t ask again” selected | 1. Attempt to open camera 2. System does not show dialog | App displays inline permission rationale and a button to open Settings | |
| TC‑CAM‑N04 | Invalid picture size request | Camera supports list of sizes, request unsupported size (e.g., 9999×9999) | 1. Configure capture request with invalid size 2. Initiate capture | Camera API returns error, app falls back to nearest supported size or shows error | |
| TC‑CAM‑N05 | Concurrent access from two app components | Two fragments both trying to start camera simultaneously | 1. Fragment A opens camera 2. Without releasing, Fragment B attempts same | Second attempt receives CAMERA_ERROR_CAMERA_IN_USE, app logs and notifies user | |
| TC‑CAM‑N06 | Storage write‑permission missing | Storage permission denied, camera permission granted | 1. Take photo 2. Camera returns image bytes | App cannot write file, shows “Unable to save photo – grant storage permission” | |
| TC‑CAM‑N07 | Video encoder unavailable | Device lacks hardware H.264 encoder (rare on very old devices) | 1. Select video mode 2. Press record | App falls back to software encoder if available, or shows “Video recording not supported” | |
| TC‑CAM‑N08 | Preview surface destroyed mid‑capture | Preview surface (SurfaceView) destroyed while autofocus running | 1. Start autofocus 2. Immediately call surfaceHolder.removeCallback | Autofocus callback receives error, app does not leak resources, preview stops cleanly | |
| TC‑CAM‑N09 | Malformed QR code (partial) | Camera pointed at a QR code missing finder pattern | 1. Hold device at angle causing partial view 2. Wait | Scanner returns no result, UI shows “Try again” after timeout | |
| TC‑CAM‑N10 | Excessive zoom beyond hardware limits | Request zoom ratio > max supported (e.g., 10× on a 2× device) | 1. Set zoom to 10× 2. Attempt to capture | Camera clamps to max supported zoom, app logs warning, image captured at max zoom | |
| TC‑CAM‑N11 | Battery critically low (< 5 %) | Device battery at 4 % | 1. Attempt video recording | App blocks start, shows low battery warning, suggests charging | |
| TC‑CAM‑N12 | Overheating throttling | Device temperature > 40 °C (simulate via stress app) | 1. Start 4K video recording 2. Monitor frame rate | Frame rate drops to maintain thermal limit, app shows notification “Recording may be limited due to temperature” | |
| TC‑CAM‑N13 | Permission dialog dismissed by back press | Permission dialog showing | 1. Press back button instead of Allow/Deny | Dialog dismissed, app treats as denial and shows rationale | |
| TC‑CAM‑N14 | Camera app hijacked by malicious overlay | Overlay app with TYPE_APPLICATION_OVERLAY covering preview | 1. Launch camera 2. Overlay displays fake button | App detects touch outside preview area, prevents accidental actions, logs security event | |
| TC‑CAM‑N15 | Unsupported MIME type for image capture | Request to save as RAW when device only supports JPEG | 1. Set output format to RAW 2. Capture | Camera API returns error, app falls back to JPEG or notifies user | |
| TC‑CAM‑N16 | Audio source unavailable for video | Mic muted via accessibility service | 1. Start video recording with audio enabled 2. Check audio track | Audio track is silent but file is valid; app logs warning | |
| TC‑CAM‑N17 | File name collision handling | Attempt to save photo with existing filename in app folder | 1. Take photo named “IMG_0001.jpg” (pre‑existing) 2. 2. | App renames file 2. Attempt second capture with same name | App either auto‑increments suffix (IMG_0001_01.jpg) or prompts user to replace |
| TC‑CAM‑N18 | Camera preview orientation lock conflict | App forces portrait, but user has auto‑rotate enabled and device in landscape | 1. Open camera in portrait mode 2. Rotate device to landscape | Preview stays portrait, UI letterboxes correctly, no stretching | |
| TC‑CAM‑N19 | External storage removed mid‑save | SD card ejected while writing video file | 1. Start recording to external SD 2. Eject card after 5 s | Recording stops, app throws IOException, shows “Storage removed – recording stopped” | |
| TC‑CAM‑N20 | Intent‑based camera picker returns null data | Third‑party gallery app returns empty data on pick | 1. Launch intent ACTION_IMAGE_CAPTURE 2. Receive result with data=null | App handles null gracefully, shows “No image selected” toast |
These negative cases expose failure modes that often slip through ad‑hoc testing. Pair each with a logging strategy so you can verify that the correct error path was taken.
Boundary, Stress, and Performance Edge Cases
Beyond functional correctness, camera integration is sensitive to resource limits and timing. Boundary tests push numeric inputs to their extremes; stress tests run the camera repeatedly to uncover leaks or thermal throttling; performance tests measure latency, frame rate, and battery impact.
Boundary Cases
| ID | Title | Preconditions | Steps | Expected Result |
|---|---|---|---|---|
| TC‑CAM‑B01 | Minimum supported picture size | Device reports min size 320×240 | 1. Configure capture with 320×240 2. Capture photo | Image saved, dimensions exactly 320×240 |
| TC‑CAM‑B02 | Maximum supported picture size | Device reports max size 4000×3000 | 1. Configure capture with 4000×3000 2. Capture photo | Image saved, dimensions 4000×3000, no down‑sampling unless forced |
| TC‑CAM‑B03 | Minimum video duration | Video mode allows 0.5 s clips | 1. Start recording 2. Stop after 0.5 s | File created, duration 0.5 ± 0.05 s, valid moov atom |
| TC‑CAM‑B04 | Maximum video duration before file split | File system limits each video to 4 GB (FAT32) | 1. Start recording at 1080p30 2. Record until split occurs (~ 22 min) | Two files created, each ≤ 4 GB, timestamps continuous |
| TC‑CAM‑B05 | Zoom step granularity | Zoom control supports 0.1× increments | 1. Set zoom to 1.0× 2. Increment to 1.1× 3. Capture | Preview scales accordingly, captured image reflects 1.1× zoom |
| TC‑CAM‑B06 | Exposure compensation range | EV range –2 to +2 in steps of 0.33 | 1. Set EV to –2 2. Capture 3. Set EV to +2 4. Capture | Histogram shift measurable, no clipping at extremes |
| TC‑CAM‑B07 | Frame rate selection | Camera lists 15, 30, 60 fps options | 1. Select 15 fps 2. Record 5 s 3. Verify frame count ≈ 75 | Same for 30 fps (≈ 90 frames) and 60 fps (≈ 180 frames) |
| TC‑CAM‑B08 | Focus distance limits | Minimum focus distance 10 cm, macro mode 2 cm | 1. Place object at 2 cm, enable macro 2. Capture | Image in focus, no blur due to minimum distance violation |
| TC‑CAM‑B09 | ISO range | Auto ISO 100‑6400, manual 100‑12800 | 1. Set ISO to 100 2. Capture low‑light scene (expect long exposure) 2. Set ISO to 12800 3. Capture same scene | Higher ISO image brighter, noise increase measurable |
| TC‑CAM‑B10 | Shutter speed limits | Minimum 1/8000 s, maximum 2 s | 1. Set shutter speed to 1/8000 s 2. Capture bright scene (expect frozen motion) 2. Set to 2 s 3. Capture dark scene (expect light trails) | Images respect exposure times, no overexposure/underexposure beyond sensor limits |
Stress Cases
Stress testing aims to reveal resource leaks, memory growth, or gradual performance degradation. Run each scenario for a high number of iterations (e.g., 50‑100 cycles) and monitor key metrics via adb shell dumpsys meminfo, CPU usage, and battery stats.
| ID | Title | Preconditions | Steps | Expected Result | ||
|---|---|---|---|---|---|---|
| TC‑CAM‑S01 | Repeated photo capture leak test | Camera permission granted, storage empty | Loop 100×: open camera → capture photo → close preview → force garbage collection | Memory growth < 5 MB, no increase in native heap, file count matches iterations | ||
| TC‑CAM‑S02 | Long‑running video record stress | Battery > 80 %, storage > 2 GB free | Record 1080p30 video for 30 minutes, pause 1 min, resume, repeat 5 times | No dropped frames > 2 % of total, file integrity checkpoints, no crash, battery drain within expected range (~ 15 % per hour) | ||
| TC‑CAM‑S03 | Rapid orientation flip stress | Camera preview active | Flip device 90° left/right every 0.5 s for 2 minutes | Preview stays upright, UI does not flicker, no ANR | ||
| TC‑CAM‑S04 | Concurrent camera + sensor stress | Camera preview + accelerometer + gyroscope active | Run sensor‑heavy app (e.g., AR navigation) while capturing photos every 5 s for 15 minutes | Photo capture success rate > 98 %, sensor data timestamps consistent | ||
| TC‑CAM‑S05 | Storage full gradual fill | Start with 200 MB free | Repeatedly capture 5 MB photos until < 10 MB free, then attempt one more capture | App shows storage‑full warning before crash, no corrupted files | ||
| TC‑CAM‑S06 | Permission toggle stress | App has camera permission | Toggle permission off/on via Settings 20× while app is in foreground | Each transition handled: preview stops on denial, restarts on grant, no leaked Camera objects | ||
| TC‑CAM‑S07 | External accessory plug/unplug | USB‑C microphone attached | Record video, plug/unplug mic 10× during recording | Audio track switches seamlessly, no gaps > 10 ms, no crashes | ||
| TC‑CAM‑S08 | Intent‑based picker stress | Use system picker to choose image from gallery | Launch picker 5× each time | Picker crashes | Launch picker 30× rapidly, select image each time | App receives result each time, no ActivityNotFoundException |
| TC‑CAM‑S09 | Battery drain measurement | Fully charged device | Run a script that takes a photo every 10 s for 1 hour | Battery used < 12 % (baseline for camera usage) | ||
| TC‑CAM‑S10 | Thermal throttling observation | Device at ambient 22 °C | Run 4K video recording for 20 minutes, log CPU temperature every 10 s | Temperature stabilizes below throttling threshold (~ 80 °C), frame rate drops gracefully if limit exceeded |
Performance Cases
Performance testing validates that the camera meets user‑experience expectations for latency and smoothness. Use instrumentation like adb shell cmd gfxinfo or adb shell dumpsys gfxinfo to measure frame times.
| ID | Title | Preconditions | Steps | Expected Result |
|---|---|---|---|---|
| TC‑CAM‑P01 | Preview startup latency | Camera permission already granted | 1. Tap camera launch button 2. Measure time to first preview frame | Latency ≤ 800 ms on mid‑tier device, ≤ 500 ms on flagship |
| TC‑CAM‑P02 | Capture‑to‑save latency | Preview active, auto‑focus locked | 1. Tap shutter 2. Measure time until file write complete | Latency ≤ 1.2 s for JPEG 1920×1080 Q85 |
| TC‑CAM‑P03 | Focus acquisition time | Scene with high contrast target | 1. Initiate focus (tap to focus) 2. Measure time until focus locked | ≤ 400 ms |
| TC‑CAM‑P04 | Frame‑rate stability during recording | 1080p30 video mode | Record 10 s, compute average frame time | 33.3 ms ± 2 ms (≥ 29 fps effective) |
| TC‑CAM‑P05 | Battery impact per minute | Idle baseline measured | Run video recording for 5 minutes, measure % drop | Drop ≤ 8 % per minute on typical device |
| TC‑CAM‑P06 | Memory footprint during preview | Preview active, no capture | Sample memory usage via dumpsys meminfo | Heap growth stable (< 10 MB increase) |
| TC‑CAM‑P07 | CPU usage during idle preview | Preview active, no interaction | top -m 10 -t -n 1 | Camera process < 5 % CPU on idle preview |
| TC‑CAM‑P08 | AR overlay render time | AR session active, model < 500 poly | Measure time from frame arrival to model draw | ≤ 16 ms (to maintain 60 fps) |
| TC‑CAM‑P09 | QR code decode latency | Clear QR code at 15 cm distance | Start timer when code enters FOV, stop when decode callback fires | ≤ 300 ms |
| TC‑CAM‑P10 | Video encoder bitrate accuracy | Target bitrate 8 Mbps for 1080p30 | Encode 10 s clip, compute average bitrate via ffprobe | Within ± 10 % of target |
These performance numbers become your acceptance criteria; track them in a test dashboard to catch regressions early.
Device‑Specific and OS‑Level Variations
Camera behavior diverges across manufacturers, Android versions, and iOS releases. Your test matrix must account for these variables, either by parameterizing test data or by maintaining device‑specific test suites.
Android Fragmentation Points
| Variable | Impact on Camera | Test Strategy |
|---|---|---|
| Camera2 API level | LEGACY vs LIMITED vs FULL vs LEVEL_3 determines available controls (manual focus, ISO, exposure time) | Create a capability matrix; run the same functional test on each level, skipping unsupported steps (mark as N/A) |
| Vendor‑specific extensions (e.g., Samsung’s ISOCELL, Google’s HDR+) | May add extra modes like “Night Sight” or “Portrait” | Add optional test cases that are enabled only when the extension is present (detect via PackageManager.hasSystemFeature) |
| Screen density & aspect ratio | Preview SurfaceView layout may stretch or letterbox incorrectly | Validate preview aspect ratio matches sensor aspect ratio on multiple densities (ldpi, mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi) |
| Storage access model (Scoped Storage, legacy) | Determines where you can write media files | Test both app‑specific directory and, if applicable, shared Pictures directory with proper URI permissions |
| Intent resolution | Some OEMs replace the stock camera picker with a custom one | Verify that ACTION_IMAGE_CAPTURE and ACTION_VIDEO_CAPTURE return expected data URIs on each OEM build |
| Background location & camera restrictions (Android 12+) | Apps may be prevented from using camera while in background | Test that background camera use throws SecurityException and is handled gracefully |
| Java/Kotlin vs. Native (NDK) | If you use native camera via OpenSL or libcamera, JNI overhead may differ | Run performance tests on both Java and native implementations |
iOS Specific Points
| Variable | Impact | Test Strategy |
|---|---|---|
| AVFoundation capture session configuration | Presets (photo, video, high‑frame‑rate) affect available resolutions | Parameterize test by AVCaptureSessionPreset and verify each yields expected dimensions |
Camera authorization status (AVAuthorizationStatus) | Denied, restricted, notDetermined, authorized flows | Exercise all four states, verify UI prompts and fallback messages |
| Live Photos | Adds a MOV resource alongside JPEG | Capture Live Photo, verify both assets present and correctly linked |
| Depth data (Portrait mode) | Requires dual‑camera or LiDAR | When depth available, capture depth map and verify its resolution matches preview |
| ProRAW (iPhone 12 Pro + ) | Produces DNG with larger file size | Enable ProRAW, capture, validate DNG header and size > 10 MB |
| Metal‑based processing | Custom filters via Metal shaders | Run a custom Metal filter on preview, measure frame‑time impact |
| Background audio interruption | Incoming call pauses capture session | Simulate call, verify session pauses and resumes without losing buffer |
Cross‑Platform Web Camera (getUserMedia)
When testing a web application that uses navigator.mediaDevices.getUserMedia, the matrix shifts to browser and OS combos.
| Variable | Impact | Test Strategy |
|---|---|---|
| Browser (Chrome, Firefox, Safari, Edge) | Different implementation of constraints, varying support for echoCancellation, noiseSuppression | Run same test script in each browser, capture console errors |
| OS (Windows, macOS, Linux, Android, iOS) | Camera permission UI differs; some OSes hide the camera indicator | Verify permission prompts appear correctly and that the indicator (LED or OS bar) shows when active |
| Device orientation | Mobile browsers may lock orientation based on CSS | Test portrait vs. landscape locking behavior |
| HTTPS requirement | getUserMedia requires secure context (localhost exempt) | Confirm failure on HTTP, success on HTTPS or localhost |
| Frame rate constraints | Some browsers cap at 30 fps even if device can do 60 | Verify requested vs. actual frame rate via videoTrack.getCapabilities() |
| Audio‑video coupling | Some browsers require audio track even if you only want video | Test providing {video:true, audio:false} and check if audio track is omitted |
| Screen share vs. camera | getDisplayMedia vs. getUserMedia | Ensure your code does not mistakenly request screen share when camera intended |
By structuring your test cases with parameters (device API level, camera capability flags, browser version), you can generate a combinatorial test suites automatically using tool or TestNG** data providers.
Traceability, Prioritization, and Test Management
A test case is only as valuable as its ability to be linked back to a requirement and to be prioritized according to risk. Establish a lightweight but rigorous process.
Traceability Matrix
Create a simple spreadsheet or use a feature of your test management tool with these columns:
| Requirement ID | Requirement Description | Test Case IDs | Status (Pass/Fail/Blocked) | Last Run | Comments |
|---|---|---|---|---|---|
| REQ‑CAM‑01 | Request CAMERA permission before preview | TC‑CAM‑001, TC‑CAM‑N03 | Pass | 2025‑10‑28 | – |
Test Your App Autonomously
Upload your APK or URL. SUSA explores like 10 real users — finds bugs, accessibility violations, and security issues. No scripts.
Try SUSA Free