All articles
92 articles
-
Layout Testing Across Screens: Notches, Safe Areas, Foldables and Font Scale
Your phone is one device out of thousands. What breaks across aspect ratios, cutouts, foldables and at 200% font scale — and how to test it. With a checklist.
-
How QA Should Work with Claude: a Workflow, Not a Toy
Claude saves hours of QA busywork — if you treat it like a junior teammate, not a search box. A breakdown of the workflow, the tasks it closes, and where not to trust it.
-
QA Prompts: Templates That Actually Save Time
The formula for a good prompt plus seven ready-made templates for everyday testing tasks — from generating test cases to log analysis and requirements review.
-
QA Burnout: Why Testers Burn Out Differently — and What to Do About It
Burnout in QA has its own triggers: you're the eternal bearer of bad news, you're the bottleneck before every release, and 'caught a bug' is invisible work while 'missed one' is public blame. We break down the QA-specific causes, early signs, what actually helps (and what doesn't), an 8-point self-check, and what to ask your lead in a 1-1.
-
Visual Regression Testing: Tools and Approaches in 2026
Functional tests are green but the layout broke: a button shifted off-screen, text is clipped, the theme is broken. That's what visual regression testing catches. We cover what it is, why raw screenshots flake, and the 2026 tools: Playwright toHaveScreenshot, Lost Pixel, Percy, Applitools Eyes, Chromatic — a matrix and who should pick what.
-
Page Object Model: UI Test Architecture So You Don't Drown in Maintenance
Locators and steps right inside tests are a time bomb: change one button and you fix it in 50 places. Page Object Model: a class per page encapsulates locators and actions, tests call methods. What belongs in a Page Object, what doesn't, Component Objects, fluent/loadable, anti-patterns, and when POM is overkill.
-
Testing Mobile App Interruptions and Lifecycle
A mobile app never runs in a vacuum — the OS interrupts at any moment, and that's where the bugs hide. Interruptions (calls, push, notification shade, split-screen), lifecycle and background process kill, rotation, network drops, low-memory kill and battery saver, revoked permissions. A checklist and how to reproduce it all.
-
Bruno vs Postman vs Insomnia: Which API Client to Pick in 2026
Postman went cloud-first with a mandatory login — teams are migrating in droves. A 2026 comparison of three API clients: Postman (powerful but cloud-first and vendor lock-in), Bruno (open-source, offline, collections as .bru files in git), and Insomnia. A matrix, what matters for QA, and how to move off Postman.
-
How QA Talks to Developers: «It's Not a Bug», Priorities and Tone Without War
Half of QA's job isn't finding a bug — it's getting it fixed. How to answer «it's not a bug, it's a feature», how severity differs from priority, how to write a bug report that prevents arguments, keeping the tone «the behavior is broken, not you broke it», what to do about «can't reproduce», and when to escalate.
-
Waits in UI Tests: Why Tests Flake and How to Wait Right
The #1 cause of flaky tests is bad waiting. Why sleep() always loses, why implicit wait is treacherous, how to wait on a condition with explicit wait, what auto-wait changes in Playwright/Cypress, and how to rewrite a flaky test from a timer to a state.
-
A Checklist for Testing Dates, Time and Time Zones
Dates are a source of bugs that surface in production six months later. A practical checklist: storing in UTC, time zones, daylight saving (DST), date formats, boundaries (midnight, end of month, Feb 29), calculations across DST, relative time, and how to reproduce it all.
-
Playwright vs Cypress vs Selenium in 2026: Which to Pick for E2E
A 2026 comparison of the three main E2E frameworks: Playwright (multi-browser, auto-waiting, Trace Viewer, the default for new projects), Cypress (best DX and time-travel debugging), and Selenium (the W3C standard, most languages and Grid). A difference matrix, who should pick what, and how not to get the choice wrong.
-
Ariane 5, Flight 501: How One Overflow Blew Up a Rocket in 40 Seconds
On 4 June 1996, the first Ariane 5 self-destructed 37 seconds after launch. The cause: an overflow converting a 64-bit float to a 16-bit int in reused Ariane 4 code. A first-person breakdown: what happened, why redundancy didn't help, and six QA lessons on code reuse, boundaries, dead functionality, error handling, and testing in the real configuration.
-
Proving QA's Value: Metrics and Impact That Management Actually Sees
QA is often seen as a bottleneck and a cost center, and "found N bugs" is a bad metric. A first-person take: what NOT to measure (bug counts, test-case counts, hours), what to show instead (escaped defects, prevention, risk coverage, speed with quality), the cost of a bug by stage, and how to communicate in business language. With a checklist to make QA's impact visible — and turn it into a case for promotion.
-
API Test Automation: Where to Start and What to Cover in 2026
API tests are the base of the pyramid: faster and more stable than UI, catching logic bugs earlier and cheaper. A first-person take: what to check beyond 200 (schema, error paths, authorization, boundaries, idempotency), data setup/teardown and isolation, validating the contract against OpenAPI/JSON Schema, and the 2026 toolset (Playwright request, pytest+httpx, REST Assured, Hurl, Schemathesis). With a good-API-test checklist.
-
Testing Money and Numbers: A 35-Point Checklist of Where It All Breaks
0.1 + 0.2 ≠ 0.3 — and that's just the start. Money and numbers are a minefield: float error, rounding, locales, currencies, boundary values. A first-person take: why money isn't stored in float, rounding and splitting an amount, locale formatting, currency decimal places, user input, and the business logic of discounts and taxes. With a flat checklist.
-
How to Test a Mobile Game's Economy and Catch Cheaters
A game's economy is the prime target: every cheat hits revenue directly. A first-person take: why you can't trust the client (server authority), duplication bugs and purchase idempotency, device-clock manipulation, save-file editing, negative balance and overflow, fake IAP receipts, and cheat tools. With a checklist of attacks QA must run.
-
Test Reporting in 2026: Allure vs ReportPortal vs Currents vs Native Playwright
"Green/red in the console" isn't a report. Your team and manager need run history, trends, flaky detection, and something they can share. A first-person take: Playwright's native HTML report and Trace Viewer, Allure, ReportPortal, and Currents/Cypress Cloud — what each gives you, what it can't do, and who it suits. With a decision matrix and a good-report checklist.
-
Broken Access Control: How QA Tests Authorization (OWASP's #1 Risk)
Broken access control is #1 in the OWASP Top 10, and QA can catch most of these holes without a pentester. A first-person take: IDOR, horizontal and vertical privilege escalation, forced browsing, testing on the backend (not the UI), a role matrix, and token tampering. With a checklist and the usual places it breaks.
-
How to Deliver Bad News: A Bug Before Release, a Slipped Deadline, "Quality Dropped"
QA is the perpetual bearer of bad news, and HOW you deliver it decides whether you're heard or remembered as the one who always whines and "blocks the release." A first-person take: the fact → impact → options → recommendation formula, data instead of emotion, escalation without drama, the "I surface risk, I don't block" framing, and speaking the language of a developer / manager / stakeholder. With a checklist and phrase templates.
-
Locators That Survive a Redesign: A Selector Strategy for UI Automation
UI automation fails from brittle locators far more often than from real bugs. A first-person take: selector priority (role/label → data-testid → text → CSS → XPath last), why positional XPath and auto-generated classes are time bombs, how to agree on data-testid with developers, the dynamic-content and i18n traps, and how it maps across Playwright, Selenium, Cypress, and Appium. With a good-locator checklist and a list of anti-patterns.
-
Transactional Email Testing Checklist: 40 Things People Forget
"It's just an email" — and then the password reset lands in spam, the welcome mail proudly reads "Hello, {{name}}", and the link expires before it even arrives. A first-person take: trigger and content, deliverability (SPF/DKIM/DMARC, spam), links and tokens, rendering in email clients (dark mode, images off, Gmail/Outlook), timing/duplicates/retries, localization and unsubscribe. With a flat checklist.
-
Interruption Testing in a Mobile Game: A Call, a Backgrounded App, and a Lost Session
The player is on the deciding move — then a call comes in. They return, and the progress is gone, the audio is silent, the rewarded-ad reward never arrived. A first-person take: the catalog of interruptions (call, push, backgrounding, lock, ad, headphones, split-screen), what actually breaks on resume, iOS vs Android differences, how to reproduce each case, and a checklist.
-
Testing Restore From Backup: The Backup Nobody Ever Restored
Everyone has backups — almost nobody tests the restore. A first-person take: why "backup completed successfully" guarantees nothing; what RTO and RPO are and why you measure them; what actually breaks during a restore (corrupt archive, wrong point in time, drifted schema, foreign environment, secrets); how to run a restore drill; and why you should monitor the restore, not the backup job. With a breakdown of the GitLab 2017 incident.
-
Testing Feature Flags and A/B Experiments: How Not to Ship a Mess of Variants
A flag isn't "on/off" — it's a live branch of code in production that you test in both states. A first-person take: why one flag becomes a matrix of states; where the nasty targeting and sticky-bucketing bugs hide; how to test an A/B experiment as a mechanism rather than a hypothesis; kill switches, zombie flags, and a pre-release checklist.
-
Real-Device Testing: How to Build a Device Matrix and Why Your Phone Lies
Everything ran fine on my Pixel — the reviews said "crashes on launch." Real bugs don't live on your device. A first-person take: why one or two phones lie; how to build a matrix along risk axes (OS, hardware class, vendor/skin, screen, locale) from your own analytics; real devices vs emulators vs cloud farms; what to test specifically on varied hardware (OOM, thermals, vendor process-killing, safe-area, update-over-install).
-
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.
-
Manual → Automation: How to Make the Switch Without Breaking
"Learn Python and Selenium" is the most common and most useless advice. The switch to automation doesn't break on syntax. A first-person take: the three pits (automating everything, thinking automation is "writing tests", dropping the manual mindset), a route that works (minimal language, start with API tests, then UI with architecture, Git/CLI/CI), why your manual past is an advantage (you know WHAT to automate, you're the oracle, repro steps, exploration), and the transition anti-patterns.
-
UI Test Automation Architecture: Page Object and What Comes After It
A good automation suite is measured not by the number of tests but by the cost of change. A first-person take: what a Page Object actually is (it hides HOW behind WHAT), why assertions inside the object are an anti-pattern, the layers above Page Object (components, API setup, test data), where people over-engineer, and the rule of three against premature abstraction. Plus the test-of-a-healthy-test: it reads like a user scenario, with no selectors in the body.
-
Payment & checkout testing checklist — the cases where money breaks
Checkout is where money and trust meet, yet it's usually tested with card 4242 and the happy path. A first-person take: money as integer minor units, not floats; double charges and idempotency; bank declines as normal, not a 500; 3-D Secure and the abandoned challenge; the webhook as source of truth, not the redirect; recomputing totals and promo codes on the server; PCI and tokenization; network drops at every step. Plus a flat 16-point checklist.
-
LiveOps events — releases without App Review that get the least testing
A live game runs on events: battle passes, tournaments and sales ship via server config with no release and no store review — straight to production, on top of any client version. A first-person take: window boundaries and timezones (UTC+13 and UTC-11), clock manipulation as the main cheat, config landing on old clients, claiming rewards exactly once, "a misplaced comma = top-tier sword for 1 coin", time travel on staging as a must-have, the kill switch, and an event launch checklist.
-
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.
-
A QA's first 30 days on a new project — how to ramp up without doing anything dumb
Day one: unfamiliar product, confusing environments, and someone's already asking you to 'take a quick look at this feature.' A first-person take: fresh eyes as a resource with an expiration date, a week spent as a user, a risk map built from three questions to the team ('what breaks most often? what was the last incident? where are you afraid to touch?'), exemplary first bug reports, why criticizing processes in week two is the worst move, small finished improvements by the end of the month, and a 30-day checklist.
-
Autotests that aren't in CI are a hobby: wiring tests into the pipeline without drowning
400 autotests that run "sometimes, locally" are not automation. A first-person take: run layers (a PR gate budgeted in minutes / post-merge / nightly), sharding and why parallelism kills dependent tests, a retry policy that doesn't mask flakiness (passed-on-retry = yellow, not green), quarantine with exactly two exits, the red-main rule, failure artifacts (a trace instead of re-debugging), and suite health metrics.
-
Registration & login testing checklist — with a Playwright autotest for every item
Login is the first screen a user sees and a favorite spot for production incidents. The "checklist item → how to automate it" format: user enumeration via identical error messages, password reset with a single-use token, logout and the back button, HttpOnly/Secure cookies via context.cookies(), sessions across two tabs, mocking 429 for lockout UI, the storageState pattern so you don't log in inside every test — and what parts of auth should never go into e2e.
-
Update testing — the bugs only users on old versions ever see
The release was tested perfectly — on a clean install. But almost every user gets it as an update on top of an old version with old data. A first-person take: why an update means new code reading old data, the N-5 → N version matrix and migration chains, updates landing mid-session, force update and its bypasses, staged rollout and a server that must support two versions at once, downgrade as a crash loop, first launch after an update ≠ FTUE — and why an archive of old builds must exist.
-
"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.
-
"How long will testing take?" — giving estimates without digging your own grave
You blurt out "two days" in three seconds, and that number then lives for weeks — and gets used against you. A first-person take: why test estimation is a special genre (you're estimating the quality of someone else's work that doesn't exist yet), an estimate as a forecast with assumptions, decomposition instead of a single number, three points instead of one, a named buffer instead of "×2 just in case", and what to say when your time gets cut.
-
What to automate and what to leave manual — and why 'automate everything' kills the suite
'Automate everything' turns into a red suite nobody trusts within six months. A first-person take: the test we fixed for half a year when we should have deleted it; why an autotest costs not 'to write' but 'to maintain for years'; what's worth automating (stable, frequent, expensive by hand, deterministic) and what to leave to a human; the pyramid as a decision calculator; why a flaky test is worse than a missing one, plus an 'automate or not' checklist.
-
Screen states: empty, loading, error — and the ones people forget until a bug arrives
Screens get designed for the happy path, but the user sees loading, emptiness or an error first. A first-person walkthrough: the empty screen that looks like a stuck loader; why 'nothing here yet' and 'nothing found' are different empties; why an error must not look like emptiness; offline, partial load, stale data, errors on load-more; accessibility of empty and error states, plus a compact checklist.
-
Crashes and ANRs in a mobile game: catching what won't reproduce for you
Crashes almost never happen on your device — they live on other people's, where memory is tight and the network drops. A first-person walkthrough: why you should test the crash reporter itself first (a real case where Crashlytics initialized after the crash and the exception handler was grabbed by the ad SDK), how a crash differs from an ANR, why you need symbolication and context in the report, managed vs native crashes in Unity, and how to deliberately recreate other people's conditions.
-
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.
-
How QA and developers can stop fighting: reporting bugs and giving feedback without conflict
QA–developer conflict is almost never about the bug — it's about how it's communicated. How to report bugs and give feedback without friction: the bug is about the product, not the person; a report structure that defuses defensiveness; feedback language (SBI and Lara Hogan's formula); severity without drama; handling 'works as designed'; shift-left; when to escalate; blameless culture and a 10-point checklist.
-
Search and filters testing checklist — and how to automate every item with Playwright
Search and filters are almost everywhere, and the bugs are always the same. A checklist of what to test (edge-case queries, debounce, request races, empty state, XSS, filters in the URL, resilience to backend errors, localization) — and for each item a real Playwright test via network interception with page.route. Plus what NOT to automate in e2e.
-
Testing runtime permissions in a mobile app: states, on-the-fly revocation, and edge cases
Permissions aren't 'granted or not' — they're a state matrix. A five-state model, pre-permission priming, graceful fallback on denial, process death on on-the-fly revocation, background and precise/approximate location, ATT and limited Photos on iOS, 'Don't ask again' on Android, verifying via Proxyman traffic, and a 12-point 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.
-
Burnout in QA: early signs, causes and how to pull yourself (and the team) out
Burnout in testers: how it differs from tiredness (the 3 WHO dimensions), why QA is at risk, the early signs, three levels of causes (personal/team/process), what actually helps, what a team lead should do, and a self-check mini-checklist.
-
AI bots that play your game: game-QA automation in 2026
AI agents for game testing: how they differ from scripted automation, what they actually do (24/7 exploratory play, crashes, balance, video logs), the limits and risks, who's on the market (modl.ai, AltTester, GameDriver), when to use AI bots and when plain automation is enough. A pilot checklist.
-
File upload testing checklist: 30+ cases people forget
A reusable file upload testing checklist: content vs extension and magic bytes, sizes and decompression bombs, file names and path traversal, the upload process and dropped connections, server-side processing and storage, security (SVG XSS, RCE, SSRF) and accessibility. 30+ points.
-
FTUE / onboarding in a mobile game: what to test in the first session
The first session (FTUE) through a QA lens: the matrix of entry points (install/reinstall/deep link/login), tutorial interruptions, skip and mandatory steps, returning player and updates, idempotent reward, A/B and funnel analytics. A 12-point checklist.
-
Testing deep links: deep links, Universal Links, App Links and the state matrix
Deep links through a QA lens: three link types, the state matrix (foreground/background/killed/not installed), deferred deep linking and attribution, fallbacks and broken links, security, AASA/assetlinks verification, tools adb/simctl/Proxyman. A 12-point checklist.
-
Mock servers for QA: WireMock and friends — when to replace a dependency with a stub
When an external dependency can't or shouldn't be run for real, you mock it. Why mock, what a good mock server does (stubs, fault injection, record/replay, verify), tools WireMock/MockServer/Mockoon/Prism/Hoverfly, mock vs Testcontainers, contract drift and Pact. A 10-point 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.
-
QA interview in 2026: how to prepare and what's actually asked
A prep map for the QA interview: theory and test-design techniques, severity vs priority, a framework for answering 'test X', bug reports, the API/SQL minimum, automation, behavioral questions via STAR, and company red flags. A 10-point checklist.
-
Test data in automated tests: a source of flakiness and coupling — and how to prepare it
Test data is one of the most invisible sources of flaky tests, bigger than locators. Isolation, determinism (freeze clock, seeded Faker), uniqueness under parallelism, factories vs fixtures vs API setup, cleanup and anonymizing prod data. A 12-point checklist.
-
Form testing checklist: 30+ cases people forget
A reusable form testing checklist: text fields and trimming, validation, numbers and money, email/phone/date/password, masks and autofill, double submit and idempotency, network, security and error accessibility. 30 points + a mini template.
-
Testing ads in a mobile game: rewarded, interstitial, mediation and edge cases
Ad monetization through a QA lens: how to test rewarded and interstitial ads, reward idempotency (SSV), no-fill, mediation and waterfall, frequency capping, ATT/GDPR consent, network and analytics. A 13-point checklist.
-
Testcontainers: real databases, Kafka and Redis in tests instead of mocks and a shared environment
How to test integration against a real Postgres, Kafka and Redis in Docker — without lying mocks or a flaky shared environment. Wait strategies, reusable containers, Ryuk, modules, CI, and a 10-point adoption checklist.
-
Knight Capital: how $440M vanished in 45 minutes because of one deploy
A QA-eye breakdown of the August 1, 2012 disaster: a reused feature flag, an unnoticed 8th server, the dead Power Peg code, and 97 ignored alerts. 7 lessons and a 10-point release-process checklist.
-
Idempotency and retry storms — what QA must test in distributed systems
The most expensive class of bugs in payments isn't 'didn't go through' — it's 'went through twice'. A QA-eye view of idempotency: Idempotency-Key, 5 typical retry scenarios, retry storms, tools (WireMock, Toxiproxy, k6), and a 13-point release checklist.
-
1-1s for QA — what to prepare, templates, and how to talk about growth with your lead
A 1-1 is a tool for your growth, not a status report. 90% of QAs burn 50 meetings a year. 5 types of content, ready scripts for 5 painful topics (promotion, burnout, conflict), a 1-1 doc template, and a pre-meeting checklist.
-
Android fragmentation for a mobile game — what MIUI, One UI, EMUI, and Oppo/Vivo battery savers break
«Works on Pixel, crashes on Xiaomi, different bugs on Samsung, no Google Play on Huawei.» Complete 2026 fragmentation guide: 6 OEMs with their quirks, what breaks in games, the minimum QA lab, a checklist, and bug-report format.
-
Claude in QA is overrated — 10 scenarios where it falls short, and where it actually pays off
The QA community has hyped «Claude will replace manual QA». In production those promises don't hold up. A contrarian breakdown without anti-AI rhetoric: 10 overrated scenarios, 5 systemic limits, hidden risks, and 5 places where it actually works.
-
CrowdStrike, July 2024 — how a single driver bricked 8.5 million Windows machines in 78 minutes
The most expensive software failure in history — $5.4B in direct losses. A trivial off-by-one on the side of an internal validator. Full timeline, root cause, three separate QA failures, and 10 lessons for your team.
-
OWASP API Security Top 10 for QA — a guide with test cases
Most QAs know SQL injection and XSS. But 90% of vulnerabilities in modern products live in APIs, and the OWASP API Top 10 2023 is a separate list that QA courses don't cover. All 10 threats with test cases, curl snippets, and tools.
-
Bad news to stakeholders — how QA should communicate release problems
The soft skill that separates junior from senior. Most QAs either drag it out or dump panic. 11 sections: principles, ready templates for 5 typical situations, channels, escalation, postmortem.
-
AI and auto-healing locators in autotests — what actually works in 2026
The most expensive part of a mature autotest suite is locator maintenance. A whole class of products was built around that pain under the «AI-powered» label. 8 sections: what's under the hood, Healenium vs Mabl/testRigor/Functionize, where LLMs actually work, risks, and a rollout plan.
-
Accessibility checklist for a mobile app in 2026
On 28 June 2025 the EU's European Accessibility Act came into force — for b2c apps a11y is now a legal requirement. 11 sections of a QA checklist: VoiceOver/TalkBack, Dynamic Type, contrast, touch targets, semantics, automation.
-
Cloud Save in a mobile game — a testing checklist
A player finished 30 levels on iPad, opens iPhone — progress is gone. The most reputation-expensive part of a mobile game. 9 sections and a QA checklist for cloud save: APIs, conflicts, cross-platform, corruption, recovery.
-
API tools for QA in 2026 — Postman, Bruno, Insomnia, Hurl: which to pick when
A comparison of four API tools on the dimensions that matter in real QA work. Postman pushed into the cloud, Bruno grew up as a git-friendly alternative, Hurl owns the CI niche.
-
Testing on a bad network — 8 scenarios and tools
Most QA checklists cover only «internet works» and «Airplane mode». Real users live between those. 8 network-degradation scenarios with tools and acceptance tests.
-
5 testing types that cover 90% of real work
There are dozens of testing types in theory. In practice, five of them fill 90% of your day. Where each applies, what it catches, where it fails, and the most common mistakes.
-
Junior → Middle → Senior QA: real growth signals at each level
Half of QA engineers get stuck between levels for 1–2 years. Not because they lack knowledge — but because they don't understand what's expected on the next rung. A level-by-level breakdown: what's expected, what isn't, readiness signals, anti-patterns, a self-assessment checklist.
-
Classical QA is dying. What replaces it
The classical QA approach was built on a simple idea — if we test thoroughly before release, we can trust the system after release. Today that no longer works. Here's what needs to change.
-
Visual Regression testing: a complete guide
Functional test is green, button clicks, form submits — and the user looks at the screen and sees the icon shifted 4 pixels left and overlapping the text. Visual regression closes that gap.
-
Claude for QA engineers: 10 real scenarios and prompts
AI assistants have moved from 'novelty' to legitimate working tool. For QA, this is especially powerful — routine tasks like test-case generation, log triage, prompt-shaped data.
-
Push notifications: a 10-section testing checklist
Push notifications are one of the most under-tested features in mobile apps. A QA checklist usually says 'arrived / not arrived'. But there are dozens of real cases hiding behind it.
-
Testing In-App Purchases in a mobile game: 9 sections and a checklist
IAP is the most expensive code segment for a bug. One missed case of 'money charged, item not granted' means support tickets, refunds, bad reviews, and retention at risk.
-
Maestro vs Appium: what to choose for mobile UI testing in 2026
Appium has held the throne since 2014, but if you're picking a stack for mobile UI tests today — look at Maestro. Faster to install, simpler to write, and for casual projects often covers 100% of needs.
-
Proxyman for QA: guide to inspecting and rewriting HTTP traffic
HTTP/HTTPS traffic between an app and a server is the single biggest source of mobile bugs that are hard to reproduce: analytics, IAP, ads, remote config, A/B tests, push notifications.
-
Mars Climate Orbiter: $327 million lost over pounds vs newtons
September 23, 1999: NASA lost a spacecraft approaching Mars. No hardware failure, no communication issue. It was a benchmark bug in integration testing.
-
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.
-
Playwright auto-wait: why you don't need explicit waits
If you came to Playwright from Selenium — your first instinct is to write waitForSelector before every action. 90% of the time it's redundant work: Playwright already waits for you.
-
Localization checklist: 10 traps you catch in a single pass
Localization is not 'run the strings through a translator'. With 5+ languages, a dozen bug classes appear that are invisible in English. A compact checklist covering 90% of real problems.
-
What the emulator won't show: 5 classes of bugs found only on real hardware
Emulators speed up CI and are convenient for smoke tests, but relying on them alone is self-deception. Some problems only appear on a real device with a real load, battery and sensors.
-
The test pyramid is outdated: what big teams use instead
Mike Cohn's classic pyramid (2009): lots of unit, medium integration, few E2E. The model was born when UI frameworks were heavy. Now Playwright and Cypress run in seconds — what teams use instead.
-
Checklist for testing date and time fields
A 'pick a date' field looks innocent — but date/time fields fail more tests in production than anything else. Time zones, DST transitions, locales, leap years — every item has shot someone.
-
Why your Selenium tests fail intermittently: 5 reasons for flaky tests
Flaky tests are the biggest source of distrust in automation. Per the Google Testing Blog, about 1.5% of all green CI runs contained at least one flaky failure. Usually the problem is in the test, not the product.
-
Playwright: where to start and how to learn
Playwright became the web automation standard in 2023-2025. A curated set of resources to help you switch from Selenium/Cypress or start from scratch.
-
adb for mobile QA: 40 commands that save hours
ADB (Android Debug Bridge) is the main tool for mobile QA on Android. A list of commands that are actually used during regression and bug triage.
-
5 books every tester should read
QA as a profession has classic literature — every senior engineer knows it. If you haven't read them, time to fix the gap. 5 books that shaped the modern approach to testing.
-
English for QA: free resources that actually help
A QA engineer without English is a career constraint. Docs, the best books, conference talks, communicating with the team abroad — it's all in English. A collection of free resources people actually use.