Test Automation Basics Flashcards

Question 1

What does the term test automation mean in software development?

Accepted Answer

Test automation is the use of scripts and tools to run tests, compare actual results with expected results, and report outcomes without a person performing each step by hand. It speeds up repeated checks, supports frequent releases, and frees testers to focus on exploratory work and design of new tests.

Question 2

Which kinds of checks are the best candidates for test automation?

Accepted Answer

Good candidates are stable, repetitive checks that run often and have clear expected results, such as regression tests for core workflows, smoke tests after each build, and data validation rules. Tests that depend on subjective judgment, such as visual appeal or usability, usually remain manual because a script cannot judge them well.

Question 3

What is a regression test and why do teams automate it?

Accepted Answer

A regression test confirms that existing behavior still works after a code change, bug fix, or new feature. Teams automate these tests because they repeat across every release, and manual repetition is slow and error prone. Automated regression suites give fast feedback, which helps developers catch breakage close to the change that caused it.

Question 4

What is the difference between a test case and a test script?

Accepted Answer

A test case describes what to verify, including its preconditions, steps, and expected result, in a readable form. A test script is the executable code that carries out those steps automatically. One test case may map to one script, and the case stays useful as documentation even when the script changes.

Question 5

What does it mean for an automated test to be deterministic?

Accepted Answer

A deterministic test produces the same result every time it runs against the same code and environment. Determinism matters because a test that sometimes passes and sometimes fails hides real problems and erodes trust in the suite. Common causes include timing dependencies, shared data, and reliance on the current time or random values.

Question 6

What is the purpose of a smoke test in an automated pipeline?

Accepted Answer

A smoke test is a small set of checks that confirms the most important functions of a build work. If a smoke test fails, the build is considered broken and deeper testing stops, saving time. Smoke tests are quick, run on each new build, and cover basics like starting the application and logging in.

Question 7

What is a test oracle and why does it matter?

Accepted Answer

A test oracle is the source of truth a test uses to decide whether observed behavior is correct, such as a specification, a stored expected value, or a reference system. Automated tests are only as good as their oracles, because a check with a wrong expectation can pass broken software or fail healthy software.

Question 8

What is the difference between verification and validation in software testing?

Accepted Answer

Verification asks whether the product was built correctly, meaning it matches its specifications and design. Validation asks whether the right product was built, meaning it meets the real needs of users. Automated checks mostly support verification, while validation often needs human review and user feedback.

Question 9

What is a unit test and what does it typically cover?

Accepted Answer

A unit test checks a small piece of code, such as a single function or method, in isolation from the rest of the system. Unit tests are fast and cheap to run, so teams usually have the largest number of them. They help pinpoint exactly where a defect lives.

Question 10

What is an integration test and how does it differ from a unit test?

Accepted Answer

An integration test checks that two or more components work together correctly, such as a service reading from a database or a module calling an external interface. Unlike a unit test, it exercises the real connections between parts, so it is slower and more likely to fail for environmental reasons.

Question 11

What is an end-to-end test and what makes it valuable?

Accepted Answer

An end-to-end test follows a complete user journey through the application, such as signing up, adding an item to a cart, and paying. It is valuable because it confirms the parts work together from the user's point of view. They are slow, costly to maintain, and can fail for many unrelated reasons.

Question 12

What is the testing pyramid and what shape does it recommend?

Accepted Answer

The testing pyramid is a model that suggests a large base of fast unit tests, a smaller layer of integration tests, and only a few end-to-end tests at the top. The goal is fast feedback at low cost, reserving slow, broad tests for critical paths. It is a guideline rather than a strict rule.

Question 13

What are non-functional tests, and which quality attributes do they measure?

Accepted Answer

Non-functional tests check how well software performs rather than what it does, covering attributes such as speed, load handling, security, accessibility, and reliability. Teams can automate many of them, for example by measuring response times under simulated load. Results are often compared against agreed thresholds to detect slowdowns early.

Question 14

What is exploratory testing and how does it complement automated tests?

Accepted Answer

Exploratory testing is simultaneous learning, test design, and execution, in which a tester investigates the product without a fixed script. It complements automation by finding surprising behavior and usability problems that scripted checks were never written to look for. Findings often become new automated checks once the issue is understood.

Question 15

What is a test double and when would you use one?

Accepted Answer

A test double is a stand-in object that replaces a real dependency during a test, such as a database, payment service, or clock. Common kinds include stubs with fixed answers, mocks that verify calls, and fakes with simplified logic. Doubles keep unit tests fast and isolated, but overusing them can hide integration problems.

Question 16

Why do teams sometimes run only a subset of tests on each commit?

Accepted Answer

Teams run a subset because a full suite can take too long on every commit, so they select tests likely affected by the change. The full suite still runs on a schedule or before release, since subset choices can miss some side effects.

Question 17

What is the arrange, act, assert pattern in automated tests?

Accepted Answer

Arrange, act, assert is a structure for writing tests in three phases. The arrange phase sets up data and preconditions, the act phase performs the one action being tested, and the assert phase checks the outcome against the expected result. Keeping these phases distinct makes each test easier to read and debug.

Question 18

Why is it generally better for each automated test to check one behavior?

Accepted Answer

A test focused on one behavior fails for one clear reason, so the failure message points directly to the problem. When a test checks many behaviors, an early failure can hide later results and make it unclear which change broke what. Focused tests are also easier to name, maintain, and reuse.

Question 19

What is a locator in user interface test automation?

Accepted Answer

A locator is an expression that identifies a specific element on a web page or screen, such as a button, text field, or heading. Stable locators rely on attributes meant for testing, like dedicated test identifiers, rather than fragile details such as exact position or long styling chains. Good locators reduce breakage from cosmetic changes.

Question 20

What is an assertion and what happens when one fails?

Accepted Answer

An assertion is a statement in a test that compares an actual value with an expected value and fails the test when they differ. A failed assertion shows which check broke and the values seen. Specific assertions, such as checking one field, are more useful than broad checks that pass for the wrong reasons.

Question 21

Why does test data management matter for reliable automated tests?

Accepted Answer

Automated tests need data that is known and isolated, so each run starts from a predictable state. If tests share records or rely on leftovers from earlier runs, their results depend on order and timing, which creates false failures. Teams often create data within each test or reset it afterward to keep runs independent.

Question 22

What is the page object pattern in UI test automation?

Accepted Answer

The page object pattern places the locators and actions for one screen inside a dedicated class, so tests call meaningful methods instead of raw interface steps. When the page changes, the team updates one class rather than every test that touches it. This separation keeps tests readable and reduces duplicated code.

Question 23

What is a data-driven test and what advantage does it offer?

Accepted Answer

A data-driven test runs the same test logic several times with different input values and expected results, usually read from a table, file, or data source. Its main advantage is broader coverage without copying the test code for each case. A new case then needs only a new row of data.

Question 24

What is the purpose of a test fixture?

Accepted Answer

A test fixture is the fixed setup and teardown code that prepares a known environment before a test runs and cleans it up afterward. Fixtures let several tests share common setup without repeating it, and teardown prevents one test's leftovers from affecting the next. Poorly designed fixtures can create hidden dependencies between tests.

Question 25

What is a test framework and what does it provide to a team?

Accepted Answer

A test framework is a structured set of libraries, conventions, and runtime support that organizes how tests are written, discovered, executed, and reported. It provides shared utilities such as assertions, setup hooks, and report generation, so each team member does not reinvent them. Frameworks also give tests a consistent shape that newcomers learn quickly.

Question 26

What is a test runner and what does it do?

Accepted Answer

A test runner is the component that finds test files, executes the tests in a defined order, and collects their pass or fail results. It usually offers options to run a subset of tests, run tests in parallel, and rerun failed tests. Some frameworks bundle a runner, while others let teams choose one.

Question 27

What is a test environment and why should it resemble production?

Accepted Answer

A test environment is the set of hardware, software, configuration, and data where tests run. It should resemble production closely in versions, settings, and integrations, because differences can cause tests to pass in testing but fail in production. Teams narrow gaps by using infrastructure definitions and realistic but anonymized data.

Question 28

What does it mean to keep test code under version control?

Accepted Answer

Keeping test code under version control means storing it in a repository that records every change and its reason. This lets teams review test changes like app changes, roll back faulty edits, and see which change caused a failure. Test code deserves the same care as production code, since it guards product quality.

Question 29

What is parallel test execution and what risk does it introduce?

Accepted Answer

Parallel test execution runs several tests at the same time across multiple workers or machines to shorten total run time. The risk is that tests sharing state, such as a database row, a file, or a login session, can interfere with one another. Teams avoid this by isolating data for each test.

Question 30

What is a headless browser and why do teams use one for tests?

Accepted Answer

A headless browser is a web browser that runs without a visible window, rendering and executing pages through code instead of on a screen. Teams use it to run UI tests faster and on servers that have no display. Some visual details can differ from a normal browser, so occasional visible runs still help.

Question 31

What are environment variables and why do test suites use them?

Accepted Answer

Environment variables are named values set outside the code, such as a base address, a username, or a timeout. Test suites use them so the same tests can run against a local machine or a staging server without editing the code. Secrets such as passwords belong in such variables, not in test files.

Question 32

What should a useful automated test report show a team?

Accepted Answer

A useful automated test report shows which tests passed, failed, or were skipped, along with the error message, stack trace, and any logs or screenshots captured at failure. It should also show trends over time, such as rising failure counts. Clear reports help people tell real defects from test problems.

Question 33

What is a flaky test and why is it harmful?

Accepted Answer

A flaky test is one that passes and fails on different runs without any change to the code under test. It is harmful because people start ignoring failures, rerunning until green, and missing real bugs. Even a small rate of flakiness can make a large suite untrustworthy.

Question 34

Why do waits based on fixed sleep times make tests unreliable?

Accepted Answer

Fixed sleeps guess how long the application needs, so they are too short and fail on slow runs, or too long and waste time. Explicit waits instead poll for a specific condition, such as a button becoming clickable, and continue as soon as it holds. This makes tests faster and steadier.

Question 35

Why are automatic retries a risky fix for flaky tests?

Accepted Answer

Automatic retries can hide flakiness by turning an unstable failure into a pass, so the underlying cause never gets fixed. They also lengthen run times and can mask real bugs that only fail occasionally. Retries may serve as a temporary measure, but they should be tracked and never treated as a cure.

Question 36

What is continuous integration and where do automated tests fit in it?

Accepted Answer

Continuous integration is the practice of merging code changes into a shared branch frequently and building and testing each change automatically. Automated tests act as the gatekeeper, running on every change so that broken code is caught within minutes rather than days. A failing run usually blocks the merge until the problem is fixed.

Question 37

What is a quality gate in an automated delivery pipeline?

Accepted Answer

A quality gate is a checkpoint in a delivery pipeline that must be passed before code moves to the next stage, such as merging or deploying. Test results are a common gate, with rules like all smoke tests must pass and no critical failures may remain. Gates make quality rules explicit and enforced.

Question 38

What should a team do first when an automated test fails in the pipeline?

Accepted Answer

First, determine whether the failure reflects a real defect in the application or a problem with the test, environment, or data. Check the error message, logs, and recent changes. If it is a real defect, fix it promptly, and if it is a test problem, repair or quarantine the test so the suite stays trustworthy.

Question 39

Why does the maintenance cost of automated tests tend to grow over time?

Accepted Answer

Automated tests depend on the application's screens, interfaces, and data, so every product change can require matching test updates. As the suite grows, more tests touch shared components, and small changes ripple through many scripts. Designing tests around stable interfaces, shared helpers, and clear naming keeps this cost under control.

Question 40

Which measures help a team judge whether its automation suite is healthy?

Accepted Answer

Useful measures include the pass rate over recent runs, the number of flaky or quarantined tests, average suite duration, and the time from a failing build to its fix. Trends matter more than single numbers, since a slowly rising run time signals trouble early. Metrics should guide improvement, not become targets to game.

Test Automation Basics Flashcards

1Foundations of test automation

2Test types and the testing pyramid

3Writing maintainable automated tests

4Frameworks, runners, and environments

5Reliability, maintenance, and pipelines

Learning Resources