Login Flow Testing Checklist (2026)
Login Flow Testing Checklist (2026) provides a concrete, step‑by‑step matrix you can apply today to verify every aspect of a sign‑in experience. The checklist groups 30+ verifiable items into happy‑pa
Login Flow Testing Checklist (2026) provides a concrete, step‑by‑step matrix you can apply today to verify every aspect of a sign‑in experience. The checklist groups 30+ verifiable items into happy‑path, error handling, edge/boundary, accessibility, security/privacy, performance, and release‑readiness categories, each with clear pass criteria and real‑world examples. Use it as a reference for manual test cases, automated scripts, or to gauge how much coverage an autonomous explorer like SUSA can achieve in a single pass.
Login Flow Testing Checklist (2026) – Happy Path Test Matrix
The happy‑path matrix confirms that a legitimate user can authenticate successfully under typical conditions. Each row lists a test ID, description, input data, expected outcome, and pass/fail rule.
| Test ID | Description | Username | Password | Expected Outcome | Pass Criteria |
|---|---|---|---|---|---|
| HP‑01 | Valid credentials, first‑time login | alice@example.com | SecureP@ssw0rd! | Home screen loads, session token stored | HTTP 200, token ≠ null, UI shows welcome |
| HP‑02 | Valid credentials, returning user (remembered) | bob@example.com | Another$tr0ng! | Home screen loads without re‑prompt | Token reused, no network login request |
| HP‑03 | Username with plus‑addressing | carol+test@example.com | P@ssw0rd123 | Login succeeds, email normalized | Backend treats carol+test@example.com as carol@example.com |
| HP‑04 | Username with leading/trailing spaces (trimmed) | " dave@example.com " | D@v3P@ss! | Login succeeds after trim | System strips spaces, authenticates |
| HP‑05 | Password containing Unicode emoji | emoji_user@example.com | 🚀🔐Pass! | Login succeeds, no encoding errors | UTF‑8 payload preserved, token issued |
| HP‑06 | Social login (Google) – valid token | (OAuth token) | N/A | Home screen loads, user profile populated | OAuth flow completes, user.id matches |
| HP‑07 | SSO via SAML – valid assertion | (SAML response) | N/A | Home screen loads, attributes mapped | Assertion validated, roles applied |
| HP‑08 | Multi‑factor authentication (TOTP) – correct code | totp_user@example.com | BasePass! + 6‑digit code | Home screen loads after code verification | TOTP validated within 30‑second window |
| HP‑09 | Biometric fallback (fingerprint) – successful match | bio_user@example.com | (device‑locked) | Home screen loads after biometric prompt | Biometric API returns success, token issued |
| HP‑10 | Password‑less magic link – valid link clicked | magic@example.com | N/A | Home screen loads, session established | Link token verified, no password field shown |
Pass criteria notes:
- HTTP status 2xx for API calls, 302 redirect for web flows only if followed by a 200 on the landing page.
- Session token must be cryptographically random (≥128 bits) and stored securely (HttpOnly, SameSite=Strict for cookies; Keychain/Keystore for native).
- UI must display a user‑specific element (e.g., avatar or name) within 2 seconds of navigation.
- No console errors, no network 5xx, and no stray modals blocking the main view.
Login Flow Testing Checklist (2026) – Error Handling and Validation
Error handling verifies that the system reacts predictably to malformed or rejected inputs, surfaces helpful messages, and does not leak internal details.
| Test ID | Description | Username | Password | Expected Error | Pass Criteria |
|---|---|---|---|---|---|
| EH‑01 | Empty username | (blank) | any | “Username is required” | Field‑level validation, focus returns to username |
| EH‑02 | Empty password | any | (blank) | “Password is required” | Same as above |
| EH‑03 | Username format invalid (missing @) | userexample.com | P@ss! | “Enter a valid email address” | Regex validation, no server call |
| EH‑04 | Password too short (policy: ≥8) | valid@example.com | 123 | “Password must be at least 8 characters” | Client‑side check, no request |
| EH‑05 | Password missing required character class | valid@example.com | lowercaseonly | “Password needs upper case, lower case, number, symbol” | Enforced policy message |
| EH‑06 | Username not found | ghost@example.com | P@ssw0rd! | “Invalid credentials” (generic) | Same message as wrong password to avoid user enumeration |
| EH‑07 | Wrong password | valid@example.com | wrongPass | “Invalid credentials” | Generic message, HTTP 401 |
| EH‑08 | Account locked after 5 failed attempts | locked@example.com | (any) | “Account temporarily locked. Try again in 15 min.” | Lockout timer respected, further attempts blocked |
| EH‑09 | Concurrent login limit exceeded (e.g., 2 sessions) | concurrent@example.com | P@ss! | “You already have an active session. Log out elsewhere?” | Prompt to terminate other session or reject new login |
| EH‑10 | Service unavailable (simulated 503) | any | any | “We’re experiencing technical difficulties. Please try again later.” | Friendly UI, retry button, no stack trace |
| EH‑11 | Malformed JWT token (tampered) | any | any | “Invalid session. Please log in again.” | Token verification fails, redirect to login |
| EH‑12 | Password‑reset token expired | (reset link) | N/A | “This link has expired. Request a new one.” | Clear expiry messaging, link disabled |
Pass criteria notes:
- Error messages must be user‑centric, avoid exposing stack traces, internal IDs, or database specifics.
- All validation should happen client‑side first (to reduce round trips) but must be duplicated server‑side for defense in depth.
- Lockout mechanisms must reset after a configurable cool‑down period and log the event for monitoring.
- After any error, the UI must retain focus on the offending field and not clear unrelated fields unnecessarily.
Login Flow Testing Checklist (2026) – Edge and Boundary Cases
Edge cases push inputs to limits defined by specifications, regulatory caps, or typical user behavior that rarely appears in scripts but surfaces in production.
| Test ID | Description | Input | Limit | Expected Behavior |
|---|---|---|---|---|
| EC‑01 | Maximum username length (254 chars per RFC 5321) | a…@example.com (254) | 254 | Accepted, trimmed if needed |
| EC‑02 | Username exceeding limit (255) | a…@example.com (255) | >254 | Rejected with “Username too long” |
| EC‑03 | Maximum password length (no arbitrary cap) | 512‑char random string | – | Accepted, hashed correctly |
| EC‑04 | Password with all allowed Unicode categories | 𝔘𝔫𝔦𝔠𝔬𝔡𝔢!@#$%^&*() | – | Accepted, no encoding errors |
| EC‑05 | Leading/trailing whitespace in password (should be trimmed) | “ P@ss! ” | – | Trimmed, authentication succeeds |
| EC‑06 | Password containing only spaces | “ ” | – | Rejected, “Password cannot be only whitespace” |
| EC‑07 | Username with consecutive dots (invalid per RFC) | user..name@example.com | – | Rejected, “Invalid email format” |
| EC‑08 | Username with quoted local part (valid) | “john..doe”@example.com | – | Accepted if system supports quoted strings |
| EC‑09 | Internationalized domain name (IDN) – punycode | 用户@例子.公司 | – | Accepted, resolved to punycode backend |
| EC‑10 | Username with plus and sub‑addressing + multiple tags | a+b+c+d@example.com | – | Accepted, tags ignored for routing |
| EC‑11 | Very fast successive login attempts (rate limiting) | same credentials | 20 attempts/second | After threshold, HTTP 429 Too Many Requests, retry‑after header |
| EC‑12 | Login with disabled account (admin‑disabled) | disabled@example.com | P@ss! | “Account is disabled. Contact support.” |
| EC‑13 | Login with expired password (policy: 90‑day expiry) | expired@example.com | OldP@ss! | Prompt to reset password before proceeding |
| EC‑14 | Login with password that matches common breach list | common@example.com | 123456 | Rejected, “Password too weak; choose another.” |
| EC‑15 | Login after password change on another device (token invalidation) | user@example.com | NewP@ss! | Old session forced logout, new login succeeds |
| EC‑16 | Login with client‑certificate authentication (mutual TLS) | cert_user@example.com | (cert) | Session established if cert valid, else “Certificate invalid” |
| EC‑17 | Login with HTTP/2 server push disabled (fallback to HTTP/1.1) | any | – | Login works, no protocol errors |
| EC‑18 | Login with IPv6‑only network | any | – | Works, DNS resolves AAAA record |
| EC‑19 | Login with proxy that strips Authorization header | any | – | Server responds 401, client handles retry |
| EC‑20 | Login with cookie size >4 KB (multiple cookies) | any | – | Server responds 400 Bad Request if limit exceeded, else works |
Pass criteria notes:
- Boundary values must be tested both just inside and just outside the limit.
- System should never crash or return 5xx for malformed but syntactically valid input; instead of rejecting with a clear 4xx.
- Rate‑limit responses must include
Retry-Afterheader and a user‑friendly message. - All edge cases should be logged at appropriate severity (INFO for expected rejections, WARN for potential abuse).
Login Flow Testing Checklist (2026) – Accessibility (WCAG) Checks
Accessibility ensures that users relying on assistive tech, keyboard navigation, or contrasting visual cues can complete the login flow.
| Test ID | WCAG Criterion | Description | Test Procedure | Pass Criteria |
|---|---|---|---|---|
| A1 | 1.4.3 Contrast (Minimum) | Text vs. background contrast ratio ≥4.5:1 | Use axe or manual contrast analyzer on username, password labels, placeholders, button text | All text meets ratio; placeholder text ≥3:1 (if not essential) |
| A2 | 2.1.1 Keyboard | All interactive elements reachable via Tab | Tab through form, verify focus order, ensure Enter submits | No trapped focus, submit reachable |
| A3 | 2.1.2 No Keyboard Trap | Ensure modal dialogs (e.g., error) can be escaped | Open error modal, press Escape | Focus returns to triggering element |
| A4 | 2.4.7 Focus Visible | Visible focus indicator ≥2 px solid | Inspect focus outline on inputs and button | Outline present, sufficient contrast |
| A5 | 3.3.2 Labels or Instructions | Each field has associated aria-label | Check DOM for label/aria‑label | Every input has programmatically associated label |
| A6 | 3.3.3 Error Suggestion | When validation fails, provide suggestion | Submit invalid email, observe message | Message includes example of correct format |
| A7 | 3.3.4 Error Prevention (Legal, Financial, Data) | For reversible actions, allow confirmation | N/A for login (non‑destructive) – ensure no accidental submit on Enter without intention | Confirm that Enter only submits when focus is on button or form |
| A8 | 4.1.2 Name, Role, Value | Custom controls (e.g., password toggle) have accessible name | Inspect password reveal button | Button has aria-label="Show password" toggling to “Hide password” |
| A9 | 1.3.1 Info and Relationships | Error messages associated with field via aria-describedby | Trigger validation, inspect DOM | Error container referenced by field |
| A10 | 2.5.1 Pointer Gestures | No reliance on complex gestures | Ensure login does not require swipe or multi‑touch | All actions achievable via tap/click or keyboard |
| A11 | 2.5.3 Label in Name | Voice control users can say visible label | Use voice command “Tap Log In” | Button activates |
| A12 | 4.1.3 Status Messages | Dynamic updates (e.g., “Logging in…”) announced | Observe live region announcements | Screen reader reads status without losing focus |
Pass criteria notes:
- Automated axe scans should return zero violations of impact ≥ moderate for the login page.
- Manual screen‑reader testing (NVDA, VoiceOver, TalkBack) must confirm that error messages are announced when they appear.
- Color contrast must be verified under both light and dark themes if the app supports them.
- Touch target size ≥ 48 dp (Android) or 44 × 44 pt (iOS) for all tappable elements.
Login Flow Testing Checklist (2026) – Security and Privacy Considerations
Security testing validates that the login flow resists common attacks and protects user data in transit and at rest.
| Test ID | Threat Model | Description | Test Procedure | Pass Criteria |
|---|---|---|---|---|
| S1 | Credential Stuffing | Automated attempts with known breach lists | Use a script to send 1000 login attempts with top 10k passwords | Account lockout or rate limiting triggered after ≤ 5 failures per username |
| S2 | Brute‑Force Protection | Delay or CAPTCHA after repeated failures | Submit wrong password 10 times in rapid succession | Increasing delay (e.g., 2 s, 4 s, 8 s) or CAPTCHA presented |
| S3 | SQL Injection | Attempt to inject via username/password fields | Submit ' OR '1'='1 as username | Input treated as literal string, no DB error, login fails |
| S4 | XSS via Reflected Payload | Inject script in username that might reflect in error page | Submit | Payload escaped, not executed; CSP blocks inline scripts |
| S5 | Password Exposure in Logs | Ensure passwords never appear in logs | Attempt login with dummy password, inspect application and server logs | No occurrence of the plain password; only hashed token visible |
| S6 | Token Storage | Verify session token is not stored in localStorage (web) or plain SharedPreferences (Android) | Use dev tools to inspect storage after login | Token only in HttpOnly cookie (web) or EncryptedSharedPreferences / Keychain |
| S7 | Token Expiry | Token should have short‑lived access token + refresh token flow | Observe network calls; check exp claim | Access token expiry ≤ 15 min, refresh token rotating |
| S8 | HTTPS Enforcement | Ensure login endpoint only accepts TLS 1.2+ | Attempt HTTP request to login URL | Server responds with 403 Redirect to HTTPS or TLS handshake failure |
| S9 | HSTS Header | Confirm Strict‑Transport‑Security header present | Capture response headers | max-age≥31536000; includeSubDomains; preload |
| S10 | CSP Header | Content‑Security‑Policy restricts inline scripts and unsafe eval | Check response headers | default-src 'self'; script-src 'self' https://trusted.cdn; object-src 'none'; |
| S11 | Referrer Policy | Prevent leakage of credentials via Referer header | Login, then navigate to third‑party site | Referer header stripped or set to no-referrer-when-downgrade |
| S12 | Account Enumeration Mitigation | Ensure same error message for existing vs. non‑existing users | Attempt login with known and unknown usernames, wrong password | Identical generic message, same timing (± 50 ms) |
| S13 | Password Hashing Strength | Validate that password is hashed with Argon2id or bcrypt, cost factor ≥ 12 | Request password hash via internal API (if available) or inspect DB | Hash format matches algorithm, salt present, cost appropriate |
| S14 | Multi‑Factor Authentication Bypass | Attempt to skip TOTP step by directly accessing post‑MFA endpoint | Send request to /home with valid session but missing MFA flag | Server returns 403 or redirects to MFA challenge |
| S15 | Session Fixation | Ensure old session ID is invalidated after login | Capture pre‑login cookie, login, compare post‑login cookie | Cookie value changed; old cookie rejected |
| S16 | Login CSRF Protection | Verify that login form includes anti‑CSRF token | Inspect form HTML | Hidden input with token validated on submit |
| S17 | OAuth State Parameter | Confirm OAuth requests include state parameter and validated | Initiate Google login, intercept request | State present, verified on callback |
| S18 | PKCE for Public Clients | Ensure mobile/SPA uses PKCE code challenge | Capture auth request | code_challenge and code_challenge_method=S256 present |
| S19 | Password‑less Token Replay | Attempt to reuse magic‑link token after use | Click link, then try again later | Second use results in “Link already used or expired” |
| S20 | Biometric Template Protection | Confirm raw biometric data never leaves device | Attempt to extract via ADB or logs | No raw fingerprint/face data accessible; only match result returned |
Pass criteria notes:
- Automated security scanners (OWASP ZAP, Burp Suite) should report no high‑ or medium‑severity findings specific to the login endpoint.
- Manual pen‑testing should verify that rate‑limiting and lockout mechanisms cannot be bypassed via IP rotation or session splitting.
- All cryptographic operations must use libraries with FIPS‑140‑2 validation or equivalent.
- Privacy: GDPR/CCPA compliance check – ensure no personal data (email, password) is stored in analytics endpoints without consent.
Login Flow Testing Checklist (2026) – Performance and Reliability
Performance checks confirm that the login flow remains responsive under load and recovers gracefully from failures.
| Test ID | Metric | Load Condition | Procedure | Acceptance Threshold |
|---|---|---|---|---|
| P1 | Time to Interactive (TTI) | Single user, 3G throttling | Measure from navigation to login page until UI responsive | ≤ 2 seconds on 3G, ≤ 1 second on Wi‑Fi |
| P2 | First Contentful Paint (FCP) | Single user, 4G | Same as above | ≤ 1.5 seconds |
| P3 | Login API Latency | 100 concurrent users | Use JMeter/k6 to POST /login with valid creds | 95th‑percentile ≤ 300 ms |
| P4 | Throughput | 500 concurrent users | Sustain load for 5 minutes | ≥ 400 successful logins/minute |
| P5 | Error Rate under Load | 500 concurrent users, 10% invalid creds | Same as P4 | ≤ 2 % 5xx responses |
| P6 | Memory Leak Detection | 20 minute loop of login/logout cycles | Monitor native heap (Android) or JS heap (Web) | Heap growth < 5 MB over test |
| P7 | Battery Impact (Mobile) | 100 login cycles on device | Use Battery Historian | Average drain ≤ 2 % per 100 cycles |
| P8 | Network Failure Recovery | Simulate 50 % packet loss during login | Use tc or network link conditioner | Login eventually succeeds after retries, no UI freeze |
| P9 | DNS Resolution Time | Varied DNS servers | Measure time to resolve auth endpoint | ≤ 50 ms |
| P10 | TLS Handshake Overhead | Fresh connection, no session reuse | Measure handshake time | ≤ 150 ms on LTE |
| P11 | Service Degradation Gracefulness | Simulate backend 503 for 30 s | Observe client behavior | Shows retry UI, does not crash, exponential backoff |
| P12 | Concurrent Device Sessions | Same account logs in from 5 devices simultaneously | Verify each device receives independent token | All sessions valid, server enforces max‑session limit if configured |
| P13 | Cold Start Latency (Mobile) | App launched from killed state | Time to display login UI | ≤ 1.5 seconds on mid‑tier device |
| P14 | Hot Start Latency (Mobile) | App resumed from background | Time to bring login screen to foreground | ≤ 400 ms |
| P15 | Animation Jank | Observe UI during input and submission | Use Profile GPU Rendering | ≤ 16 ms per frame (60 fps) |
| P16 | Accessibility Performance Overhead | Run axe while measuring TTI | Ensure no > 200 ms added latency | No significant degradation |
Pass criteria notes:
- Performance budgets should be defined per device class (low‑end, mid‑tier, flagship) and per network type.
- Synthetic monitoring (e.g., Lighthouse CI) must run on each commit to catch regressions.
- Load‑test results must be compared against a baseline; any degradation > 15 % triggers investigation.
- Battery impact measured via Android Battery Historian or iOS Energy Log must stay within product‑specific thresholds.
Login Flow Testing Checklist (2026) – Release Readiness and Automation Integration
Before a release, the login flow must satisfy a set of gate criteria that combine functional, non‑functional, and operational checks.
| Gate ID | Category | Item | Evidence Required | Pass/Fail Rule |
|---|---|---|---|---|
| R1 | Functional | All happy‑path tests (HP‑01–HP‑10) pass | Test run report (JUnit/XML) | 100 % pass |
| R2 | Functional | All error‑handling tests (EH‑01–EH‑12) pass | Test run report | 100 % pass |
| R3 | Functional | All edge‑case tests (EC‑01–EC‑20) pass | Test run report | 100 % pass |
| R4 | Accessibility | Axe scan returns zero violations (impact ≥ moderate) | Axe CLI/Node output | 0 violations |
| R5 | Security | No high/medium findings in ZAP baseline scan | ZAP report | 0 high/medium |
| R6 | Security | Password‑hashing algorithm verified as Argon2id with cost ≥ 12 | Config file / DB inspection | Compliant |
| R7 | Performance | 95th‑percentile API latency ≤ 300 ms under 100 users | Load test summary (k6) | ≤ 300 ms |
| R8 | Performance | Memory leak < 5 MB over 20 min cycle | Heap snapshot diff | < 5 MB |
| R9 | Operational | Deployment scripts include secret‑injection test (no plain passwords in logs) | Log grep audit | Clean |
| R10 | Operational | Rollback plan tested in staging (login works after rollback) | Test log | Success |
| R11 | Operational | Feature flag for new login UI is off by default | Flag repository | Off |
| R12 | Operational | Chat‑ops alert configured for login failure spikes > 5 % | Alert rule | Active |
| R13 | Legal | Privacy policy link present and reachable on login page | DOM inspection | Link present, returns 200 |
| R14 | Legal | Age‑gate (if applicable) respects jurisdiction | Consent modal test | Correct behavior |
| R15 | Automation | Regression test suite (Appium + Playwright) runs < 8 minutes on CI | CI pipeline timing | ≤ 8 min |
| R16 | Automation | Test artifacts (screenshots, videos) archived for failed runs | Artifact store | Available |
| R17 | Automation | Flaky test rate < 2 % over last 20 builds | Flaky detection dashboard | < 2 % |
| R18 | Automation | Test coverage of login flows ≥ 90 % (statement) | Coverage report (JaCoCo, Istanbul) | ≥ 90 % |
| R19 | Automation | Cross‑browser matrix (Chrome, Firefox, Safari, Edge) passes | Cross‑browser test report | All pass |
| R20 | Automation | Mobile matrix (API 21‑34, various screen sizes) passes | Device farm report | All pass |
Pass criteria notes:
- Gates R1‑R3 can be executed via unit‑test frameworks (JUnit, TestNG, pytest) that exercise the service layer directly.
- Gate R4 requires integrating axe‑core into the test pipeline (npm
axe-cliorjest-axe). - Gate R5–R6 should be part of a weekly security scan but also run on pre‑release branches.
- Gate R7‑R8 are load‑test and memory‑test steps that can be scripted with k6 and Android Studio Profiler.
- Gate R9‑R11 involve DevOps checks: secret scanning (git‑leaks, trivy), feature‑flag validation, and rollback drills.
- Gate R12‑R14 are observability and compliance items; they verify that monitoring and legal requirements are met before promoting to prod.
- Gate R15‑R20 ensure that the automated regression suite is trustworthy, fast, and provides sufficient coverage to catch regressions introduced by other teams.
How Autonomous Exploration (SUSA) Covers the Checklist in One Pass
SUSA (the autonomous QA platform) can exercise a large portion of the Login Flow Testing Checklist without writing explicit test cases. When you point SUSA at an APK or a web URL, it builds a behavioral model of the app, then drives it with multiple user personas (curious, impatient, novice, adversarial, elderly, accessibility‑focused, power user, etc.). Each persona exercises the login flow in a way that maps to many checklist items.
- Happy‑path validation: The “power user” persona follows the most efficient route, entering valid credentials and confirming that the home screen loads. SUSA records the HTTP status, session token, and UI state, giving you a pass/fail signal for HP‑01 through HP‑10 without manual scripting.
- Error handling & edge cases: The “adversarial” persona deliberately submits malformed inputs (empty fields, SQL injection strings, extremely long usernames, special‑character passwords). Susa’s built‑in oracle checks for expected error messages, generic failure responses, and lack of stack traces, thus covering EH‑01‑EH‑12 and EC‑01‑EC‑20.
- Accessibility: The “elderly” and “accessibility” personas enable screen‑reader narration, high‑contrast modes, and increased touch‑target scaling. Susa checks that focus moves logically, that error messages are announced, and that contrast ratios meet WCAG 2.1 AA via integrated axe‑core inspections.
- Security & privacy: The “curious” and “impersonator” personas attempt common attacks such as credential‑stuffing loops, password spray, and token replay. Susa detects rate‑limit responses, lockout messages, and verifies that tokens are never written to logs or local storage by monitoring file system and network traces.
- Performance: By varying the network throttling profile (3G, 4G, Wi‑Fi) and injecting latency, Susa measures TTI, FCP, and API response times for each persona, outputting aggregates that can be compared against the thresholds in P1‑P8.
- Release readiness: After a run, Susa produces a consolidated report that maps each observed behavior to the checklist IDs, highlighting any missing coverage. Teams can then add targeted manual or scripted tests for the gaps (e.g., specific MFA flow or SAML assertion validation).
Because Susa learns from prior runs, each subsequent execution becomes smarter: it avoids previously explored dead ends, prioritizes unexplored states, and updates its persona behavior models based on observed system responses. This means that over time, the autonomous explorer can approach near‑complete coverage of the Login Flow Testing Checklist with zero test‑script maintenance overhead.
Quick Reference Checklist and Takeaways
Below is a condensed version you can paste into a markdown file or ticket template. Tick each item as you verify it; the references point back to the full sections above.
[ ] HP‑01 – HP‑10: Valid credentials lead to authenticated session (Happy Path)
[ ] EH‑01 – EH‑12: Proper validation messages, no info leakage (Error Handling)
[ ] EC‑01 – EC‑20: Boundary lengths, Unicode, rate limiting, IDN, etc. (Edge Cases)
[ ] A1 – A12: Contrast, keyboard, labels, error announcement, focus visible (Accessibility)
[ ] S1 – S20: Credential stuffing protection, hashing, TLS, CSP, token storage, MFA bypass, etc. (Security)
[ ] P1 – P16: TTI, FCP, latency under load, memory leak, battery, network loss, jitter (Performance)
[ ] R1 – R20: Gate criteria – functional, accessibility, security, performance, ops, automation, legal (Release Readiness)
[ ] S
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