Automation Engineer interview questions

A test is a good automation candidate when it is repeatable, valuable, and has an objective result.

• Regression and smoke checks run often, so automation saves repeated manual effort.
• Stable inputs and observable outputs let the script make a deterministic pass or fail decision.
• Data-heavy checks benefit because a script can cover many input combinations consistently.
• A one-time check on a changing prototype usually costs more to automate than to run manually.

Tests that depend on human judgment, change constantly, or run only once usually remain manual.

• Exploratory testing relies on observation and follow-up questions that a fixed script cannot predict.
• Usability, visual appeal, and wording quality need human judgment unless the acceptance rule is measurable.
• A rapidly changing prototype makes selectors and flows expensive to maintain.
• Rare checks with low business risk may never repay the cost of implementation and maintenance.

A deterministic test produces the same result whenever the code and controlled inputs are the same.

• It controls time, randomness, test data, and external dependencies instead of inheriting changing values.
• It waits for a measurable state, such as an element becoming visible, rather than sleeping for 5 seconds.
• It creates or resets its own data so another test cannot change the expected result.
• Repeating a deterministic test 20 times against the same build should not alternate between pass and fail.

The test pyramid recommends many fast unit tests, fewer integration tests, and a small number of end-to-end tests.

• Unit tests isolate small pieces of logic and should provide feedback in milliseconds.
• Integration tests verify real boundaries such as application code with a database or HTTP service.
• End-to-end tests cover critical user journeys but cost more to run and maintain.
• The shape keeps feedback fast while still checking that the assembled product works.

I would define the expected summary, file set, and file contents from a small controlled input before running the batch.

• The fixture would contain known records so expected counts, statuses, and assignment to each output file can be calculated independently of the implementation.
• I would parse the JSON and assert its schema and stable values instead of comparing raw text whose property order may vary.
• I would assert that the output directory contains exactly two completed files, then parse them and compare required rows, fields, and ordering only where ordering is part of the contract.
• Generated timestamps or IDs would be controlled or normalized, and temporary or unexpected files would fail the test.

Smoke testing checks that the build is basically usable, while regression testing checks that existing behavior still works broadly.

• A smoke suite covers a few critical paths such as startup, login, and one core transaction.
• It runs quickly after a deployment or build and stops deeper testing if the product is unusable.
• A regression suite covers many previously working features and usually takes longer.
• Both can be automated, but the smoke suite should remain small enough to give rapid feedback.

Functional testing checks what the system does, while non-functional testing checks qualities of how it operates.

• A functional check verifies behavior such as creating an order with valid data.
• Non-functional checks cover qualities such as response time, accessibility, security, and reliability.
• Both need measurable expectations, for example status 201 for creation or p95 latency below 500 ms.
• A feature can be functionally correct yet unacceptable because it is too slow or inaccessible.

A useful assertion checks one observable requirement with an exact and stable expectation.

• Verify a meaningful result such as status 201 and the created record ID, not merely that no exception occurred.
• Compare stable fields and ignore generated timestamps or random IDs unless the test controls them.
• Include expected and actual values in failure output so the cause is visible without rerunning locally.
• Avoid assertions tied to unrelated page text because harmless text changes would create false failures.

Lists, dictionaries, sets, tuples, and strings cover most basic test data and result handling.

• A list preserves order and can hold a sequence of test cases or returned records.
• A dictionary maps field names to values, which fits JSON payloads such as name and email.
• A set removes duplicates and supports quick membership checks, while a tuple represents a fixed group of values.
• Choosing the type by its behavior makes assertions clearer than forcing all data into strings.

Use the with statement so Python closes the file even when an error occurs.

• Open text files with an explicit encoding such as UTF-8 to avoid machine-dependent decoding.
• Choose the mode deliberately: r reads, w replaces content, and a appends.
• Read large files line by line instead of loading the entire file into memory.
• Handle expected exceptions such as FileNotFoundError and report the affected path.

pathlib represents paths as objects and keeps path operations readable and portable.

• Path(base) / results.xml joins components with the correct separator for the operating system.
• Methods such as exists, mkdir, read_text, and glob express common file work directly.
• resolve can produce an absolute path when a tool needs one.
• It avoids manual string concatenation that can introduce doubled or wrong separators.

Read environment-specific configuration at runtime and validate required variables before tests start.

• os.getenv can read values such as BASE_URL, BROWSER, or a test account name.
• Supply defaults only for safe optional settings, such as BROWSER defaulting to chromium.
• Fail with a clear message when a required value is absent instead of passing None deeper into the code.
• Never print or commit passwords, tokens, or API keys read from the environment.

Use subprocess.run with explicit arguments and inspect the process result.

• Pass an argument list such as git, status instead of building one shell string from untrusted input.
• Set check=True when a nonzero exit code should raise CalledProcessError.
• Use capture_output=True and text=True when the script needs readable stdout and stderr.
• Add a timeout so a stuck external tool cannot block the automation indefinitely.

An exit code communicates whether a command succeeded, with 0 conventionally meaning success and nonzero meaning failure.

• A shell, CI runner, or parent process uses the code to decide whether the next step should run.
• Different nonzero values can distinguish invalid input from a test failure or missing dependency.
• A script should print a useful error to stderr before returning a failure code.
• Swallowing an error and exiting with 0 can make a broken test job appear green.

Catch only exceptions you can handle or enrich, and let unexpected failures remain visible.

• Catch a specific type such as JSONDecodeError rather than a broad Exception when parsing a result file.
• Add context such as the file path or command name, then preserve the original cause when re-raising.
• Use finally for cleanup that must happen on both success and failure.
• Never use an empty except block because it turns a real failure into misleading test output.

Reliable Bash scripts quote variables, check command failures, and make pipeline behavior explicit.

• Use double quotes around expansions such as $file so spaces do not split one path into several arguments.
• A pipeline connects stdout from one command to stdin of the next, as in a producer followed by grep.
• set -e exits on many unhandled nonzero statuses, but conditions, command lists, and parts of pipelines have contextual exceptions, so expected failures should be handled explicitly and set -o pipefail should expose failures inside pipelines.
• Send diagnostics to stderr and return a nonzero exit code when the script cannot complete.

Create a focused branch, make small commits, and submit the change for review before merging.

• Start from an updated main branch so the test change is based on current code.
• Use git status and git diff to inspect exactly which files and lines will be committed.
• Write a concise commit message that states what behavior the change adds or fixes.
• Push the branch and open a pull request so tests and review run before main changes.

A merge conflict occurs when Git cannot safely combine competing changes and needs a human decision.

• Git marks the conflicting sections from the current branch and the incoming branch in the file.
• Read both versions, keep the intended final content, and remove all conflict markers.
• Run the relevant tests after editing because a syntactically resolved file can still be logically wrong.
• Stage the resolved file and complete the merge or rebase according to the team's workflow.

pytest finds tests by naming conventions and then collects matching functions and classes.

• By default it searches files named test_*.py or *_test.py.
• It collects functions named test_* and methods named test_* inside classes named Test*.
• Test classes should not define an __init__ method because pytest instantiates them itself.
• pytest --collect-only shows what would run without executing the tests.

A pytest fixture provides reusable setup data or resources to tests through function arguments.

• Mark a provider with pytest.fixture and request it by using its name as a test parameter.
• A fixture can return test data, a configured API client, or a browser page.
• Code after yield performs teardown, such as closing a connection after the test.
• Fixtures reduce duplicated setup while keeping dependencies visible in each test signature.