Browse the Knowledge Hub74 resources
Test cases
Audit log test cases, for the entry somebody wrote for you
Twenty eight cases covering forged entries through log injection, immutability and tamper detection, actor attribution across impersonation, API keys and background jobs, correlation identifiers, entries for rolled back changes, behaviour when the log store fails, cursor pagination, retention, legal holds and alerting.
All 28 test cases, ready to copy
Free to use and adapt, no sign-up. Download as CSV or Markdown, or copy it straight into your own tooling.
Last updated
28 worked examples
Record every state changing action
TypeFunctionalPriorityHigh- Test data
- A create, an update, a delete, a permission change and a failed authorisation attempt
- Expected result
- All five are recorded, including the refusal, since a denied attempt is often the most interesting entry in an investigation.
Record reads of sensitive data
TypeSecurityPriorityHigh- Test data
- Viewing a personal, health or financial record, and exporting a list of them
- Expected result
- Reads are recorded where the data class requires it, because in regulated contexts who looked at a record matters as much as who changed it.
Capture before and after values on a change
TypeFunctionalPriorityHigh- Test data
- A field changed from one value to another
- Expected result
- Entry states what changed, from what, to what, rather than only that the record was updated, which tells an investigator nothing.
Refuse an attempt to forge an entry through injection
TypeSecurityPriorityHigh- Test data
- A user controlled field containing newlines, carriage returns and text shaped like a log line
- Expected result
- Encoded or rejected so it cannot create a second entry. This is the case that turns the log itself into the attack surface.
Make entries immutable
TypeSecurityPriorityHigh- Test data
- Attempt to edit and delete an entry as an administrator, through the interface and directly
- Expected result
- Refused on both. An administrator able to remove the record of their own actions defeats the purpose of having one.
Detect tampering at the storage layer
TypeSecurityPriorityHigh- Test data
- Alter a stored entry directly, then run the integrity check
- Expected result
- Alteration is detectable through hashing, chaining or append only storage, since a log that can be silently rewritten proves nothing.
Attribute an action to the correct actor
TypeSecurityPriorityHigh- Test data
- Actions by a user, an admin impersonating a user, an API key and a scheduled job
- Expected result
- Each records the real actor and, where relevant, on whose behalf, so an impersonated action is never attributed to the customer.
Record the actor for a background job
TypeStatePriorityHigh- Test data
- A change made by a queued job triggered by a user request
- Expected result
- Entry links to the originating actor and request rather than recording only the system, which would make the change untraceable.
Correlate entries across a single request
TypeStatePriorityHigh- Test data
- One user action that produces several changes across services
- Expected result
- All share a correlation identifier so the sequence can be reconstructed without inferring it from timestamps.
Store timestamps unambiguously
TypeBoundaryPriorityHigh- Test data
- Entries written from two server timezones and across a daylight saving transition
- Expected result
- Stored with an explicit offset or in one documented timezone, so the repeated hour does not reorder the sequence of events.
Order concurrent entries deterministically
TypeBoundaryPriorityHigh- Test data
- Two actions recorded within the same millisecond
- Expected result
- A sequence number or monotonic identifier disambiguates them, since two entries with an identical timestamp cannot be ordered by time alone.
Keep secrets out of the log
TypeSecurityPriorityHigh- Test data
- A password change, a token rotation, a payment update and a request containing an API key
- Expected result
- No credential, token, full card number or one time code appears in any entry, including in a captured before value.
Minimise personal data in entries
TypeSecurityPriorityHigh- Test data
- An entry recording a change to a health or financial field
- Expected result
- Records that the field changed without necessarily reproducing the sensitive value, since the log inherits the sensitivity of what it contains.
Restrict who can read the log
TypeSecurityPriorityHigh- Test data
- A standard user, a tenant admin and a support user requesting the log
- Expected result
- Each sees only entries within their scope, and a tenant admin cannot read another tenant activity through any filter or export.
Scope a customer facing activity history correctly
TypeSecurityPriorityHigh- Test data
- A customer viewing their own history on an account with collaborators
- Expected result
- Only their own and permitted shared activity is visible, and internal or system detail is not exposed through the customer view.
Never lose an entry when the log store fails
TypeStatePriorityHigh- Test data
- Make the log store unavailable during a state changing action
- Expected result
- Documented behaviour applied deliberately: either the action fails, or it succeeds with the entry durably queued. Silently skipping the entry is not acceptable.
Write the entry only for a committed change
TypeStatePriorityHigh- Test data
- An action inside a transaction that then rolls back
- Expected result
- No entry is written for a change that did not happen, and conversely no committed change is left unrecorded.
Handle a burst of activity without dropping entries
TypePerformancePriorityHigh- Test data
- A bulk operation producing thousands of changes in a short window
- Expected result
- Every change is recorded, throughput is not degraded to the point the operation fails, and no entry is sampled away.
Keep the log readable at volume
TypePerformancePriorityHigh- Test data
- A query over millions of entries filtered by actor, date range and action type
- Expected result
- Returns inside the stated budget, since a log that cannot be searched during an incident is not usable when it is needed.
Filter and search accurately
TypeFunctionalPriorityHigh- Test data
- Filters on actor, action type, resource and a date range whose endpoints match entries exactly
- Expected result
- Boundaries are inclusive as documented, the result count is accurate, and no permitted entry is omitted by a filter combination.
Paginate consistently while entries are being written
TypeBoundaryPriorityHigh- Test data
- Page through the log while new entries are arriving
- Expected result
- No entry is skipped or shown twice, which requires a cursor rather than an offset on a collection that only grows.
Export the log for an auditor
TypeFunctionalPriorityHigh- Test data
- An export honouring the active filters and permissions
- Expected result
- Contents match the screen, permissions are applied to the export, and any value beginning with an equals sign is neutralised for spreadsheets.
Apply the retention period exactly
TypeBoundaryPriorityHigh- Test data
- An entry one day inside the retention period and one day past it
- Expected result
- Retained then removed per policy, and removal is a defined process rather than an unbounded table nobody has ever pruned.
Preserve entries under legal hold
TypeSecurityPriorityHigh- Test data
- Entries covered by a hold when the retention job runs
- Expected result
- Retained past the ordinary period, since destroying held records is more serious than keeping them longer than planned.
Handle audit entries when an account is deleted
TypeStatePriorityHigh- Test data
- A deletion request on an account with audit history
- Expected result
- Documented balance is applied: personal data minimised or pseudonymised while the record required for compliance survives, and the decision is deliberate.
Keep the log consistent across services
TypeCompatibilityPriorityMedium- Test data
- Entries written by several services and application versions
- Expected result
- A common schema so entries are comparable, and an older writer does not produce entries that a reader cannot interpret.
Alert on patterns worth investigating
TypeSecurityPriorityHigh- Test data
- Repeated authorisation failures, a privilege grant, a bulk export and out of hours administrative activity
- Expected result
- Each raises an alert to a reviewer, since the value of a log is in somebody acting on it rather than in it merely existing.
Make the history usable with a keyboard and a screen reader
TypeAccessibilityPriorityMedium- Test data
- Keyboard navigation through filters, the entry list and an expanded entry detail
- Expected result
- Filters and pagination are reachable, the result count is announced after filtering, and each entry conveys actor, action and time as text rather than by icon alone.
What goes in each field
ID
RequiredStable identifier, prefixed by module.
Test case
RequiredWhat is being verified, in one line.
Type
Functional, negative, boundary, security, state, performance, accessibility or compatibility. Use it to check coverage is spread rather than clustered on the happy path.
Priority
Risk based. Anything that lets an entry be forged, altered or omitted, or that attributes an action to the wrong actor, is High, because the log exists precisely to be trusted after the fact.
Test data
The specific values, including the invalid and boundary ones.
Expected result
RequiredThe precise observable outcome, including message text where the wording itself is the requirement.
Put a newline in a name field
A log exists to be trusted after the fact. These four conditions are where it stops being evidence.
Inject a line that looks like a log entry
Newlines and carriage returns in any user controlled field that reaches the log. If they survive, an attacker writes their own entries and the log misleads the investigator.
Try to delete an entry as an admin
An administrator who can remove the record of their own actions defeats the whole control. Then alter one directly in storage and see whether anything detects it.
Take the log store offline mid action
Either the action fails or the entry is durably queued. Silently completing the change with no entry is the outcome that must not be possible.
Roll back a transaction that logged
No entry for a change that never happened, and no committed change left unrecorded. Both directions are wrong and both are common.
Why audit logs stop being evidence
Log injection is the case that almost nobody writes and it is the one that matters most, because it turns the log from a record into an attack surface. If a user controlled field reaches a log line without its newlines encoded, then anyone can write entries that look exactly like genuine ones. The record that exists specifically to establish what happened now contains fabricated events, and an investigator has no way to distinguish them. Immutability and tamper detection sit alongside it: an entry an administrator can edit or delete, or one that can be altered in storage without detection, proves nothing about anything.
Attribution is where audit logs quietly lose their value. The straightforward case is a user acting directly. The ones that get wrong are an admin impersonating a customer, an action taken by an API key, and a change made by a background job. Each needs to record the real actor and, where relevant, on whose behalf. An impersonated action attributed to the customer is worse than no entry at all, because it asserts something false about a person. A job that records only "system" makes the change untraceable back to whoever triggered it.
The write path needs the same care as the action it describes. An entry written before commit describes a change that may never have happened, and one skipped because the log store was briefly unavailable leaves a committed change unrecorded. Both are silent, and the second is the more dangerous because the system reports success. The correct behaviour has to be a deliberate decision, either failing the action or durably queuing the entry, rather than whatever the error handling happens to do.
Finally, a log is only useful if somebody can read it and somebody does. That means searchable at volume, because a query that times out during an incident is not available when it is needed. It means cursor pagination rather than offset, since the collection only grows and offsets shift underneath you. It means retention that is actually enforced rather than an unbounded table nobody has pruned, balanced against holds that must survive it. And it means alerting on the patterns worth investigating, because the value is in acting on the log rather than in having one.
Suggest an improvementTesting an enterprise or regulated platform?
QAble tests audit and traceability end to end, including injection resistance, immutability, actor attribution across every execution path and behaviour under load.
Enterprise software testing servicesMore test case sets
View allTest cases for a login page
Test cases25 cases across functional, negative, boundary, security, session and accessibility paths, including account enumeration and lockout.Test cases for a registration form
Test cases28 cases covering validation, duplicate accounts, email verification, password rules and the enumeration leak most signup forms ship with.Test cases for search functionality
Test cases28 cases across relevance, partial and fuzzy matching, filters, pagination, empty states, injection attempts and performance under load.Test cases for a shopping cart
Test cases27 cases on quantity limits, price recalculation, stock changes, coupon stacking, guest to account merge and cart persistence.Test cases for checkout and payment
Test cases30 cases including 3D Secure, declines, timeouts, duplicate charges, idempotency, refunds and partial captures.Test cases for file upload
Test cases28 cases on size and type limits, spoofed content types, malicious filenames, progress, resume, virus scanning and storage limits.Test cases for forgot password
Test cases26 cases on reset token expiry, single use enforcement, session invalidation and the enumeration and rate limit gaps that are routine here.Test cases for OTP verification
Test cases26 cases on expiry, resend throttling, attempt limits, code reuse, delivery failure and the brute force window teams forget to close.Test cases for user roles and permissions
Test cases26 cases on horizontal and vertical privilege checks, direct object access, role changes mid-session and permission inheritance.Test cases for form validation
Test cases27 rules-based cases on required fields, length and numeric boundaries, client and server parity, hidden field tampering and error accessibility.Test cases for a date picker
Test cases26 cases on timezone shifts, ambiguous day and month order, impossible dates, min and max limits, leap years and keyboard operation.Test cases for pagination
Test cases24 cases on ordering stability, records changing mid-session, page size caps, deep offset cost, permission-filtered totals and state restore.Test cases for push notifications
Test cases26 cases on app states, deep link routing, token release on sign out, lock screen privacy, preferences, provider failures and platform differences.Test cases for reports and data export
Test cases25 cases on permission filtering in the file, spreadsheet formula injection, encoding, typed numbers and dates, row limits and audit logging.Test cases for a chatbot
Test cases28 cases on paraphrased intents, context, fallback loops, human handoff, policy grounding, prompt injection and data scoping.Test cases for net banking transactions
Test cases28 cases on duplicate debits from a retried request, concurrent transfers against one balance, daily limits across channels, beneficiary cooling periods, second factor binding and reconciliation.Test cases for wallet and UPI payments
Test cases28 cases on payments that time out with no response, idempotency on retry, racing balances, caps across devices, collect request fraud, mandates and refunds.Test cases for insurance claim submission
Test cases28 cases on coverage at the date of loss, waiting periods, deductibles and sub limits, exclusions and riders, duplicate claims and settlement reconciliation.Test cases for patient records in an EHR
Test cases28 cases on duplicate detection and merge, wrong patient entry, units of measure, allergy and interaction alerting, break glass access and audit of reads.Test cases for CRM lead management
Test cases28 cases on duplicate leads under concurrency, routing and the unrouted fallback, round robin races, territory visibility, conversion and bulk import.Test cases for an ERP purchase order
Test cases28 cases on approval thresholds, amendments that must reset approval, budget commitment races, over receipt tolerance, three-way match and duplicate invoices.Test cases for OTT video playback
Test cases28 cases on bitrate recovery after a dip, DRM renewal mid stream, concurrent stream limits and leaked slots, resume conflicts, ad cue points and offline expiry.Test cases for game level progression
Test cases28 cases on save corruption during a crash write, cloud save conflicts, offline queue replay, unlock gating, currency exploits and purchase restore.Test cases for a REST API
Test cases28 cases on status code correctness, cross tenant resource access, mass assignment, idempotent retries, cursor pagination, rate limits and contract drift.Test cases for SSO and social login
Test cases28 cases on linking an account on an unverified email, state and code replay, redirect allow lists, token signature and issuer, deprovisioning and session rotation.Test cases for subscription and billing
Test cases28 cases on mid cycle proration, duplicate and out of order webhooks, renewal double charges, dunning and grace, trials, coupons, metered usage and tax.Test cases for data tables, filters and sorting
Test cases28 cases on unstable sorts across pages, filters that must reset pagination, selection surviving a filter change, bulk action scope and export fidelity.Test cases for session timeout and concurrent login
Test cases28 cases on tokens that survive sign out, refresh token reuse, idle against absolute lifetime, multi tab expiry, session limits and remote revocation.Test cases for a multi step form wizard
Test cases28 cases on values lost to back navigation, refresh and session expiry, step skipping, server side revalidation, duplicate submission and conditional branches.Test cases for email verification
Test cases28 cases on token reuse and expiry, invalidating earlier links, account enumeration, header injection, safe address change and mail scanner prefetching.Test cases for dashboards and analytics widgets
Test cases28 cases on reconciling against source rows, widgets that disagree, timezone aggregation, zero baselines, no data shown as zero and permission leaks in aggregates.Test cases for booking and reservation
Test cases28 cases on concurrent bookings for the last slot, inventory holds that leak, payment without a booking, cancellation boundaries and channel sync.Test cases for mobile app install and update
Test cases28 cases on migration chains across skipped versions, crashes during post upgrade migration, forced update lockouts, deep links and clean reinstall.Test cases for accessibility (WCAG 2.2 AA)
Test cases28 cases on keyboard only completion, focus management, live region announcements, contrast, reflow at 320 pixels, target size and screen reader verification.Test cases for performance and load
Test cases28 cases on spikes with no ramp, recovery after peak, soak and leak detection, pool exhaustion, cold caches, retry storms and data correctness under load.Test cases for the OWASP Top 10
Test cases28 cases on broken access control, mass assignment, injection across every input surface, credential stuffing, session invalidation, SSRF and exposed secrets.Test cases for cross browser compatibility
Test cases28 cases on storage that throws in private mode, blocked third party cookies, engine date parsing, mobile viewport units, in app browsers and ad blockers.Test cases for database and data integrity
Test cases28 cases on uniqueness under concurrency, lost updates, counter races, orphaned rows, migration and backfill safety, replica lag and verified restores.Test cases for localisation and multi language support
Test cases28 cases on text expansion, concatenated sentences, plural rules, locale date parsing, decimal separators, right to left layout, collation and encoding.Test cases for outbound webhooks
Test cases28 cases on retry backoff and dead letter stores, one dead consumer degrading the pipeline, payload signing and replay windows, out of order delivery and endpoint SSRF.Test cases for background jobs and queues
Test cases28 cases on work outliving the visibility timeout, idempotent handlers, poison messages, priority starvation, scheduler overlap across instances and graceful drain.Test cases for real time features and websockets
Test cases28 cases on messages lost in the reconnect gap, half open connections, per channel authorisation, tokens expiring mid connection, backpressure and fanout across instances.Test cases for file storage and media processing
Test cases28 cases on signed URL scope and expiry, serving before scanning completes, content type sniffing, metadata stripping, orphaned objects and derivative failures.Test cases for CSV import and bulk operations
Test cases28 cases on reruns duplicating successes, delimiters inside quoted fields, byte order marks, leading zeros, ambiguous dates and bulk action scope.Test cases for feature flags and progressive rollout
Test cases28 cases on unreachable flag services, unstable bucketing, rollouts that reshuffle users, kill switch latency, server and client mismatch and stale flags.Test cases for Android app lifecycle and permissions
Test cases28 cases on state lost to process death, configuration changes, permanent permission denial, revocation while backgrounded, doze and battery restrictions.Test cases for iOS app lifecycle and permissions
Test cases28 cases on the keychain surviving uninstall, suspended termination, limited photo access, allow once location, app switcher snapshots and biometric invalidation.Test cases for wearable app sync
Test cases28 cases on data recorded away from the phone, duplicate records on resync, full buffers, clock drift, health permissions, battery budgets and unworn readings.Test cases for VR and AR experiences
Test cases28 cases on the frame rate comfort floor, tracking loss, guardian boundaries, involuntary camera movement, AR anchor drift and spatial data privacy.Test cases for IoT device pairing and telemetry
Test cases28 cases on offline buffering and reconnect floods, fleet wide reconnection storms, shared credentials, wrong device clocks and stale queued commands.Test cases for embedded firmware update
Test cases28 cases on power loss mid write, automatic rollback and health confirmation, signature and anti rollback checks, staged rollouts and recovery mode.Test cases for user profile and account settings
Test cases28 cases on partial saves reported as success, optimistic updates the server rejected, mass assignment through a profile form, avatar content inspection and session invalidation.Test cases for account deletion and data export
Test cases28 cases on export links that must be authorised and expiring, deletion cascading to storage, caches, logs and processors, grace periods, legal holds and deadlines.Test cases for consent and cookie management
Test cases28 cases on cookies and tracking requests firing before consent, reject parity with accept, tag manager bypass, withdrawal, cached banners and server side forwarding.Test cases for notification preferences and delivery
Test cases28 cases on opt outs honoured on one channel and ignored on another, marketing sent as transactional, unsubscribe scope, imports resetting consent and digest timezones.Test cases for admin impersonation and support access
Test cases28 cases on actions attributed to the customer instead of the admin, credential exposure, chained and upward impersonation, session expiry and immutable access records.Want your audit trail proven, not assumed?
QAble covers functional, security and compliance paths with ISTQB-certified engineers. Start with a free QA audit of your platform.