Test Automation & Engineering

An e2e test drives the whole system the way a real user would — through the UI and across all the layers (frontend, backend, database) — to verify a complete user flow works. It gives the highest confidence that the product works as a whole, but is the slowest, most brittle, and most expensive test type, so the pyramid keeps few of them.

An assertion is a check inside a test that fails it when the expected condition does not hold. Kinds include assertTrue/assertFalse, assertEquals/assertNotEquals, assertNull, and assertThrows, plus the soft-vs-hard distinction (soft asserts collect failures and continue; hard asserts stop at once). Tools: JUnit/TestNG, AssertJ, Hamcrest, pytest, and Chai.

A flaky test passes and fails non-deterministically on the same code. Common causes: timing/race conditions, implicit waits, test-order dependence, shared or dirty state, and network instability. Fix by replacing sleeps with explicit waits, isolating state, removing order coupling — then quarantine the test and either stabilize it or delete it, since a flaky test erodes trust in the whole suite.

Page Object Model is a design pattern for UI automation: each page or screen is a class that exposes its elements and actions as methods, so tests call page methods instead of raw locators. It centralizes locator maintenance in one place, removes duplication, and keeps tests readable. It is used in Selenium, Appium, and Playwright suites.

Appium gives one codebase that drives both iOS and Android, so you write tests once — but it is slower and flakier and can lag in supporting new OS features. Native instruments (Espresso for Android, XCUITest for iOS) are faster and more stable and live in the app's code so developers can write them, but require two codebases and roughly double the maintenance.

CI (Continuous Integration) automatically builds and tests every change as it lands, catching integration problems early. CD (Continuous Delivery/Deployment) automates delivering validated builds toward or into production. Together they solve integration hell and manual-release errors, giving fast feedback and a repeatable, auditable path from commit to running software.

A good autotest is independent and atomic, deterministic (not flaky), and readable. It has clear setup/teardown (fixtures, preconditions, postconditions), produces a clear failure message, and ideally checks one logical thing. These map to the FIRST principles — Fast, Independent, Repeatable, Self-validating, Timely — making the suite trustworthy and cheap to maintain.

Web locators include id, name, class, tag, CSS selector, XPath, and link text. id is the fastest and most stable; XPath is the most flexible but brittle and slow, so CSS is generally preferred over it. Mobile adds accessibility id and Android's resource-id. The trade-off is always stability versus flexibility — pick the most stable selector the markup allows.

Mocking replaces a real dependency — a service, database, clock, or network call — with a controlled stand-in that returns predefined responses. It keeps a test isolated, fast, and deterministic, lets you simulate hard-to-reproduce conditions (errors, timeouts, a closed shop at night), and removes reliance on external state that you cannot control during the run.

A linter is a static analyzer that reads source code without running it and flags style violations and likely errors — unused variables, undefined names, suspicious patterns, formatting drift. It enforces a consistent code style and catches a class of bugs early, before the code is ever executed, often as part of the CI pipeline.

Load testing measures how a system behaves under expected and peak load — checking throughput, response time, and capacity, and finding bottlenecks before users hit them. Tools include JMeter, k6, Gatling, and Locust. Related subtypes are stress (beyond peak), spike, soak/endurance (long duration), and scalability testing.

A unit test checks the smallest isolated piece of code — a single function or module — independently of the rest of the system, usually with its dependencies mocked. It is valuable because it runs fast, pinpoints exactly where a fault is, minimizes regression by catching breakages early, and gives developers quick feedback while they change code.

An anti-pattern is a common but counterproductive solution that looks helpful yet causes problems. In test automation: hard-coded waits (Thread.sleep), interdependent tests that must run in order, copy-pasted test code, leaving flaky tests in the suite, and the ice-cream-cone pyramid (too many slow UI tests, too few unit tests).

A branch is an independent line of development. Core commands: git clone copies a repo, git pull fetches updates, git commit records changes, git push uploads them. Git Flow is a branching model with long-lived main and develop branches plus short-lived feature/*, release/*, and hotfix/* branches, giving a structured path from work to release.

A per-test setup hook (JUnit's @Before / @BeforeEach) runs before every single test method, giving each test a fresh, isolated state — used for cheap, mutable fixtures. A per-class hook (@BeforeClass / @BeforeAll) runs once before all tests in the class and must be static, used for expensive shared setup like opening a DB connection. The rule of thumb: per-test for isolation, per-class for costly resources you can safely share read-only across tests.

Mutation testing introduces small deliberate faults (mutants) into the code — flipping an operator, changing a constant — then reruns the test suite. If a test fails, the mutant is killed; if all tests still pass, the mutant survived, exposing a gap. It measures the quality of the tests themselves (do they actually detect bugs), going beyond line coverage, which only shows code was executed.

Speed up by running tests concurrently, pruning redundant ones, mocking slow dependencies, and pushing checks to lower (faster) test levels. Parallel execution runs the same suite concurrently, often across several devices or browsers; distributed execution shards the suite across nodes so different tests run on different machines, cutting total wall-clock time.

Load testing checks behavior under expected, realistic load to confirm the system meets its targets (response time, throughput) at normal and peak traffic. Stress testing pushes beyond those limits to find the breaking point and observe how the system fails and recovers. Synthetic monitoring runs scripted transactions on a schedule against production to watch availability and performance over time. Load verifies capacity, stress finds limits, synthetic observes — not a pre-release gate.

Use binary search (git bisect): repeatedly test the build in the middle of the suspect range, then keep only the half that still contains the transition from good to bad. That is O(log n) checks versus O(n) for testing every version in sequence. Narrow further by first asking whether the fault is in code or in data, which can eliminate a whole class of builds before bisecting.

Never depend on uncontrolled real-world state. Best: mock the clock or the open/closed flag so the precondition is always satisfied deterministically. Otherwise seed the database to a known open state, or call an API in the test's setup to prepare data. The general rule: a test must own its preconditions — control time and external state through mocks, seeding, or setup, never the live environment.

It is not a bug if the failure is correct handling of a real condition — no network, file too large or an unsupported type, server down, expired session — and the user is clearly told why and can retry. It is a bug if it fails under valid conditions, gives no reason, offers no retry, or the message is wrong or misleading. The test is expected-versus-actual plus graceful degradation.

First gather evidence: open DevTools to inspect the request/response, enable a proxy, read the app logs, and debug the backend if you have access. Then reason across the full chain: a duplicate ticket number, a Cyrillic character the generator emitted, server-side validation rejecting the number or text, the DB being down, the network failing, a slow/timed-out response, or a malformed request from the frontend.

Likely causes are CDN edge-cache staleness (one node still holds the old version), geo or locale-based content negotiation (the Accept-Language or geo headers select a version), a stale local browser cache, or a VPN changing the exit node. Investigate by inspecting request/response headers with DevTools or a proxy and comparing ETag, Last-Modified, and Cache-Control across the devices.