Free CTAL-AT practice test: 30 questions with answers

Risk-based selection with automated regression in the pipeline gives fast, repeated feedback on changed and critical areas. Starting the manual pass earlier keeps it slow, skipping unchanged modules ignores side effects, and unit tests alone do not catch integration-level regressions.

Holistic testing spreads quality activities across the whole lifecycle and the whole team, covering functional and non-functional aspects as part of everyday work. The other options describe a unit-only view, a separate formal test phase, or a narrow sprint-only scope, none of which show that integration.

Flaky UI tests waste effort and erode trust, so the team should find out why they fail and fix the causes. Moving checks that do not need the interface to lower levels also reduces the number of fragile end-to-end tests. Raising timeouts and retries hides the problem, while dropping automation or ignoring results loses coverage.

Confirmation testing re-executes tests to show that a specific fix works, while regression testing checks that unchanged functionality was not broken by the change. The other options swap these roles, limit them to certain teams, or wrongly treat them as the same activity.

End-to-end testing follows a complete flow across components and, where relevant, external systems, so verifying a full workflow and the gateway round trip both qualify. Isolated mocked unit tests, coverage measurement and story reviews are useful activities, but they are not end-to-end testing.

Whole-team quality means testers collaborate with developers from the start instead of receiving finished work at the end. The other options keep testing as a late, separate phase or add headcount without changing how the team works together.

In the whole-team approach everyone involved shares responsibility for quality and contributes testing skills. The other options place testing with one separate team, split it by role with the final check left to testers, or make a single person the decision maker.

Knowledge held by one person is a risk, so the whole team should share automation ownership through pairing and reviews. A wiki alone does not transfer skills, a contractor adds cost without building team capability, and stopping regression checks increases risk.

Testers in agile teams act as coaches and collaborators who help the whole team build quality into its work. Approving stories, owning the defect list alone, or signing the test report are roles that conflict with shared ownership of quality.

Psychological safety encourages people to raise problems, so the team should treat defects as shared process issues rather than personal blame. Hiding the discussion, filtering reports or publishing individual rankings all discourage the openness that agile teams need.

Agile test planning is continuous and light, focusing on strategy, risks and the current iteration, and it changes as the backlog changes. Freezing a large plan, replacing planning with ordered manual lists or dropping planning entirely do not meet those needs.

Test monitoring and control measures progress and quality against the plan and decides what corrective action to take. Implementation, analysis and process improvement are different activities, each with its own purpose in the test process.

Test reporting should give stakeholders what they need to decide, such as remaining risks, serious open defects and gaps in coverage. A combined score, a raw pass count or unfiltered logs hide that information from the decision maker.

Agile teams improve their testing mainly through regular retrospectives, agreeing on small changes and reviewing them in the next cycle. Yearly audits, extra test cases or formal change requests are slower, add effort, or do not address root causes.

Metrics help when they inform decisions about risk and remaining work, and they need context because a single number can mislead. Ranking testers by defects, treating test case counts as proof of coverage and hiding metrics from the team are common misuses.

Vague quality expectations weaken the test basis, so the team should turn them into measurable, agreed acceptance criteria before development. Deferring measurement, swapping the story for a design document or relying on impressions do not give testers a clear basis for judgment.

Shift-left testing brings testing activities such as reviewing requirements and designs earlier, so defects are caught when they are cheaper to correct. The other options move testing later, remove automation or give testers release control, which are not its purpose.

Example mapping brings developers, testers and the product owner together to clarify requirements before work starts, which improves the test basis. Finishing code before reviewing requirements, writing test cases late or removing acceptance criteria all move quality checks later or weaken them.

A Definition of Ready with testable acceptance criteria, and scenario-style criteria written as Given, When and Then steps, both make the test basis clearer before coding. Accepting unreviewed stories, deleting criteria or running regression on production do not improve the test basis.

Reviewing requirements or stories against a checklist is static testing, and it finds ambiguity and conflicts before work starts. Dynamic testing needs running software, while confirmation and regression testing both assume that code already exists.

Exploratory testing combines learning, test design and execution in one activity, often guided by a charter. Fully pre-designed fixed-order tests, generated tests and scripted checklists are the opposite of this approach.

Session-based test management uses charters, time boxes and debriefs to make exploratory work visible and reviewable. Unrecorded free exploration, converting exploration into fixed scripts or switching to unit test writing do not provide that visibility.

The tester stays in control of the investigation while a capture tool records and replays traffic, which is tool-assisted exploratory testing. Fixed automated replay, static code analysis and customer usability feedback are different practices.

Test smells are signs of poor test design, and hidden dependencies between tests are a classic smell because they make tests fragile and failures hard to diagnose. The other options describe focused, isolated or well-selected tests, which are healthy practices.

Fixed sleeps are a known smell that makes tests slow and intermittent, and waiting for an observable condition removes the timing guess. Longer sleeps still guess at timing, while excluding or retrying the test hides the defect in the test itself.

Running automated regression tests in the continuous integration pipeline gives feedback on each change while it is still cheap to fix. Running them only on one machine, in production or in a monthly window delays feedback and removes the fast, repeatable checks agile teams rely on.

Most checks belong at API and unit level, where they are faster and less sensitive to layout changes, while a few interface tests cover critical journeys. More interface tests, manual-only regression or hiding failures by running less often all make the feedback problem worse.

Tool selection in agile should prioritize pipeline integration and the team's ability to use and maintain the tool. Report polish, market popularity or vendor claims are weaker or irrelevant criteria for this team's needs.

Automating stable, valuable checks in the pipeline and maintaining test code to production-level standards both support fast, trustworthy feedback. Automating everything regardless of value, isolating automation from the team or delaying it until the end all reduce its benefit.

Tests that own their data are independent, which removes ordering and sharing problems in CI. Serializing the suite only hides the issue and slows it down, retries mask flakiness, and dropping database checks reduces what the tests verify.