Non-functional
9 articles
-
Memory Leaks: How to Catch the Bug That Only Shows Up After an Hour
The app works perfectly for five minutes and crashes after an hour. A classic memory leak that no short test case catches. We cover what a leak looks like from the QA side, which scenarios expose it, how to measure memory on Android, iOS, Unity and the web, and what to attach to a bug report so a developer finds the cause in an hour, not a week. With a checklist.
-
Tokens in logs: how QA can test diagnostics for sensitive data leaks
A practical test plan for logs, analytics and crash reporting: synthetic markers, error paths, nested fields, account switching and event delivery checks.
-
Fuzz Testing: Breaking Input with Garbage to Find What You Can't Catch by Hand
Manual cases check what you thought of; bugs live where you didn't. A first-person take: what fuzzing is and why it has a different oracle (you catch the crash, not the "right answer"); the kinds — dumb, coverage-guided (AFL++/libFuzzer), property-based (Hypothesis/fast-check); where QA actually applies it (parsers, file upload, API by OpenAPI, input fields, business logic); what fuzzing finds that manual cases never do; tools and how to start so it lives in CI.
-
Rate limiting — how to test the limits everyone remembers only after an incident
While nobody is hammering the API, limits seem unnecessary — their absence is invisible right up until the first incident. A first-person take: the limit as a two-sided contract (the server restricts — the client survives it), the N/N+1 boundary and an honest 429 with Retry-After, key scope and how an account-based limit lets attackers DoS a victim, the burst at window boundaries, bypasses via X-Forwarded-For and sibling endpoints, the zones where a limit is mandatory (OTP, reset, promo codes), and why 'limits are off on staging' equals an untested production.
-
"It shows me old data" — how to test caches, the quietest source of bugs
The "user sees stale data" bug doesn't reproduce, gets closed as "went away on its own" — and comes back a week later. That's not mysticism, that's a cache. A first-person take: the map of six caching layers (browser, CDN, gateway, application, database, mobile client), invalidation as the main test case, caches leaking other users' data, cache stampede after a deploy, the "every case twice — cold and warm" rule, and why testing with the cache off means testing a system that doesn't exist.
-
Chaos Engineering for QA: deliberately breaking the system to test resilience
Resilience you never tested with a deliberate failure is an assumption, not a fact. Chaos Engineering for QA: the steady-state hypothesis, blast radius and the abort button, what failures to inject (instance kill, latency, dependency outage, resource exhaustion, zone outage), tools (Chaos Monkey, Gremlin, Chaos Mesh, AWS FIS, Toxiproxy), Game Days, the QA role (graceful degradation, retries, circuit breakers, observability) and a safe-experiment checklist.
-
Observability for QA: logs, metrics, traces — what to test and how to use it
Observability through a tester's eyes: the three pillars (logs/metrics/traces) in plain language, how to test observability itself (trace id, metrics, secrets in logs), how QA uses it to localize distributed bugs and silent degradations, SLI/SLO/error budget, and an observability-ready feature checklist.
-
Load testing: how to design it and not get garbage numbers
How to do load tests right: types (load/stress/soak/spike/breakpoint), percentiles instead of the average, open vs closed model, realistic data and traffic profile, server-side metrics and saturation, coordinated omission, tools k6/Gatling/Locust/JMeter. A 12-point checklist.
-
Performance testing for a mobile game: 7 metrics that actually matter
'The game lags' is too abstract for a ticket. To make a performance problem reproducible, measurable and trackable — you need concrete numbers. Here are 7 metrics worth checking every release.