Automation and API testing interview questions

I automate tests that are stable, repetitive, and run often. Good candidates are regression suites, smoke tests, data-driven cases with many input combinations, and anything run across multiple browsers or environments. I avoid automating things that change constantly, run only once, or need human judgement like look-and-feel and exploratory testing. The rule of thumb: automate the boring, repeatable checks so humans are free for the creative testing.

Automation gives you speed, repeatability, and the ability to run huge regression suites overnight or on every commit, which is impossible by hand. The limitations are that it has an upfront cost to build and a real cost to maintain, it only finds the bugs you told it to look for, and it cannot judge usability or unexpected visual issues. So automation is fantastic for regression and confidence, but it does not replace human testers, it frees them up for exploratory and edge-case work.

The page object model, or POM, is a design pattern where each page or component of the app gets its own class that holds the locators and the actions for that page. Your test scripts then call those methods instead of touching raw locators directly. The big win is maintainability: when the UI changes, you update the locator in one place, not in fifty scattered tests. It keeps tests readable too, because a test reads like loginPage.login(user, pass) instead of a wall of selectors.

First I find the root cause instead of just rerunning until it passes, because a hidden flake often masks a real bug. The most common cause is timing, so I replace fixed sleeps with explicit or smart waits that wait for the element to actually be ready. Other causes are unstable locators, shared test data, test order dependencies, and animations, and I fix each at the source. If a test is truly flaky and low value, I quarantine it so it does not block the pipeline while I repair it.

An implicit wait sets a global timeout that tells the driver to keep polling for any element for up to that long before failing. An explicit wait is targeted: it waits for a specific condition on a specific element, like "wait until this button is clickable". Explicit waits are preferred because they are precise and reduce flakiness, whereas mixing both can cause unpredictable timeouts. I avoid hard-coded sleeps entirely, because they either waste time or are too short.

Common locators are ID, name, class, CSS selector, and XPath, plus modern frameworks favour role and text-based selectors. ID is the most reliable when it is unique and stable, so it is my first choice. I prefer CSS selectors over XPath for readability and speed, and I lean on dedicated test attributes like data-testid when the team supports them, because they survive design changes. I avoid long, brittle absolute XPaths that break the moment the DOM shifts.

Data-driven testing is running the same test logic with many sets of input data, where the data lives outside the script in a file, spreadsheet, or database. Instead of writing twenty near-identical login tests, you write one and feed it twenty rows of credentials and expected results. It gives broad coverage with less code and makes it easy to add cases by adding a row. It pairs naturally with boundary and equivalence testing, where you want to cover many input combinations.

I match the tool to the project, not the other way around. I consider the application type, the team's existing language skills, the tool's community and support, and how it fits into CI. For web UI, Selenium and Playwright are common; for APIs, Postman or a code library; the right choice is the one the team can maintain. I am careful not to pick a fancy tool nobody on the team can support, because an unmaintainable framework is worse than none.

Automated tests run automatically whenever code is pushed, so the team gets fast feedback before changes merge. Typically a quick smoke or unit layer runs on every commit, and the fuller regression suite runs on a schedule or before deployment. If critical tests fail, the pipeline blocks the merge or the release. Tools like Jenkins, GitHub Actions, or GitLab CI trigger the runs, and the key is keeping the fast tests fast so developers are not tempted to skip them.

The pyramid is a guideline for how to balance your test types. The base is many fast, cheap unit tests; the middle is a smaller layer of integration and API tests; and the top is a thin layer of slow, expensive end-to-end UI tests. The point is to push as much coverage as possible down to the cheaper layers and keep the brittle UI layer small. Teams that invert this and rely mostly on UI tests end up with slow, flaky suites, which is called the ice-cream cone anti-pattern.

API testing checks the application's business logic directly at the service layer, without going through the user interface. You send requests to an endpoint and verify the response, the status code, the data, and the behaviour. It matters because it is faster and more stable than UI testing, it can catch bugs before the UI is even built, and it tests the logic where it actually lives. A lot of an app's real work happens in APIs, so testing them gives strong coverage with less brittleness.

REST is an architectural style for web APIs that uses standard HTTP and treats things as resources addressed by URLs. The main methods are GET to read data, POST to create, PUT to update or replace, PATCH to partially update, and DELETE to remove. GET should be safe and not change anything, while POST does. Knowing which method an endpoint uses tells me what to expect and verify, like making sure a GET never accidentally modifies data.

The families are 2xx for success, 3xx for redirects, 4xx for client errors, and 5xx for server errors. The specific ones I check most are 200 OK, 201 Created after a POST, 204 No Content, 400 Bad Request for invalid input, 401 Unauthorized when not logged in, 403 Forbidden when logged in but not allowed, 404 Not Found, and 500 Internal Server Error. A key test is confirming the API returns the right error code, for example 401 versus 403, because that difference matters to clients.

I check four things: the status code, the response body, the headers, and the response time. In the body I verify the data is correct, the schema and field types match the contract, and required fields are present. I check headers like content-type and any auth or caching headers, and I confirm the response comes back within an acceptable time. I also test the negative cases, like sending a bad payload and confirming a clean 400 with a helpful error message rather than a 500.

I start by reading the API documentation to understand the endpoint, its method, required parameters, auth, and expected responses. Then I run the positive case to confirm a valid request returns the right data and status. Next I hit the negative and edge cases: missing fields, wrong data types, invalid auth, boundary values, and large payloads. Finally I check non-functional aspects like response time and that protected endpoints reject unauthorised calls. I usually use Postman for exploration and then automate the stable checks.

Authentication proves who you are; authorization decides what you are allowed to do. For auth I test the common schemes, like API keys, basic auth, OAuth, or bearer tokens, and confirm a request with no token or an expired token is rejected with a 401. For authorization I test that a valid user cannot access another user's data or perform admin actions they should not, which should return 403. Testing the negative side here is critical, because broken authorization is a serious security bug.

SOAP is an older, stricter protocol that uses XML and has a rigid contract called WSDL, while REST is a lighter architectural style that usually uses JSON over plain HTTP. REST is simpler, faster, and far more common in modern web and mobile APIs, whereas SOAP still appears in older enterprise and banking systems where strict standards and built-in security matter. Most of my API testing is REST and JSON, but I know SOAP exists and uses XML payloads if a project needs it.

Path parameters identify a specific resource and live in the URL, like /users/123 where 123 is the user id. Query parameters filter, sort, or paginate and come after a question mark, like /users?status=active&page=2. The request body carries the actual payload of data for POST and PUT requests, usually as JSON. Knowing the difference helps me design tests, because I will fuzz the body for create and update, and check invalid or missing path and query params for read endpoints.

Integration testing checks that several services work together correctly, not just in isolation. A common pattern is chaining: I call one endpoint, grab a value from its response like a new order id, and feed it into the next request. I verify the data stays consistent across the whole flow, for example that creating an order actually reduces stock and appears in the user's history. I also test what happens when one service in the chain fails, to make sure the system degrades gracefully.