Free CT-FT practice test: 30 questions with answers

Domain knowledge lets testers understand the business rules and exceptions that a meaningful test must cover. Writing from the specification alone can miss business exceptions, automating before the rules are understood wastes effort, and reusing old cases without checking them against current rules gives false confidence.

Domain knowledge allows testers to check whether expected results match real business behaviour, which matters most when the specification is incomplete. It does not replace test design techniques, it is not limited to performance testing, and it is not solely a developer responsibility.

Available balance is normally the ledger balance plus any agreed overdraft limit, less pending debits and holds. Ignoring the limit, ignoring holds or using the limit alone gives a wrong expected result. Testers need this domain rule to set the oracle.

Whether a payment is settled before or after a cut-off changes its end-of-day status, so the expected results depend on that timing. Programming language choice and screen layout are unrelated to settlement, and settlement rules never remove the need for expected results.

A test oracle is the source of expected results, so the tester can decide whether the actual output is correct. Boundary value analysis is still needed, timing records are unrelated to correctness, and generating input data is a separate task from judging outputs.

A traceability matrix links each regulatory requirement to the rule, the test cases and the results, which is the evidence auditors look for. Keeping code without linked test records, an annual regression run, or verbal assurance does not show that each rule was tested against its requirement.

Compliance testing checks that the system conforms to laws, regulations and internal policies, and it is repeated as the system changes. Speed under load, user sign-off and a single release check are each only part of the picture.

Running suspicious transaction patterns through the system and checking that alerts are raised gives direct evidence that the rule is enforced. Defect counts, dashboard response times and a written confirmation in a design document do not prove that the rule works in operation.

Audit log content and required disclosures are both controls that compliance testing must verify against regulation or policy. Concurrent user capacity is a performance concern and colour palettes are a branding concern, so neither is compliance testing.

Automated compliance checks in the pipeline give evidence for each release continuously rather than once a year. An annual review, removing the checks, or unverified developer statements leave releases without evidence.

Product risk level is usually based on the likelihood that a failure occurs and the impact if it does. The number of test cases, the developer's seniority and the code size may influence effort but do not define the risk level itself.

Risk-based prioritisation puts the highest financial-impact area first. Visible but cosmetic changes carry lower risk, equal effort ignores risk, and alphabetical ordering has no connection to risk.

Risk-based testing directs effort toward the areas with the highest risk, so the amount and depth of testing follow the risk level. Equal allocation, limiting tests to features that have never failed, and identifying risks after testing all contradict this principle.

Product risks concern the quality of the delivered system, so incorrect repayment schedules and credit decisions that break affordability limits are product risks. Staff departures and late environments are project risks because they affect schedule and resources.

Risk-based test planning uses the assessed risk of each item to decide how deeply it is tested and in what order. Post-release triage, environment provisioning and archiving are activities that do not set test depth or priority.

Tracing the individual records behind a reconciliation difference is how the cause, such as a missing posting or a timing gap, is found. Hiding transactions, editing totals by hand or accepting the gap without investigation would conceal a real data defect.

Record counts and control totals such as amount sums show whether all records arrived, which a single sample record cannot prove. Fonts and colours are presentation concerns, and job duration says nothing about completeness.

Masking or anonymising personal fields protects customers while preserving realistic values and relationships for testing. Unchanged copies, renaming an environment and emailing extracts all expose personal data and do not remove the privacy risk.

Referential integrity and validation at entry and at integration points stop invalid or orphaned data from spreading between systems. Approximate floating-point storage of money can produce rounding errors, and unsynchronised copies of master data cause inconsistency.

Matching counts and totals show that records arrived, but a wrong currency shows that the meaning of the values was not checked. Claiming full verification, blaming the legacy data without retesting, or calling it cosmetic ignores a real calculation and reporting risk.

Equivalence partitioning and boundary values target the balance tiers and rounding points, where interest rules most often fail. Random clicking without expected results, logout checks and login load tests do not exercise the calculation logic.

Endurance testing applies a sustained load for an extended period and watches for memory growth or resource leaks, which matches the scenario. Spike testing uses a short burst, while usability and localisation testing address different quality characteristics.

Security testing covers activities such as penetration testing and vulnerability scanning that look for weaknesses an attacker could exploit. Passing functional tests does not establish security, encrypting button colours is not a security control, and testers can take part in security testing.

Failover testing and data centre loss simulation both test whether the service stays available or recovers within agreed targets. Text wrapping and decimal separator display are usability and localisation checks, not availability checks.

Human review against approved requirements catches hallucinated or incorrect expected results before they become test assets. Confidence scores are not a reliable quality measure, production records should not be given to an assistant, and publishing without review skips the check.

Automated regression suites produce repeatable evidence that can be rerun and linked to specific releases, which supports audit needs. Automation does not replace test design, passing scripts never guarantees zero defects, and execution records remain required.

Stabilising flaky scripts and investigating their failures keeps the evidence trustworthy. Retrying until green hides defects, deleting failing scripts creates false coverage, and weekend-only runs avoid the problem rather than resolve it.

Automation assets must be validated and controlled, and their results must be traceable to releases and approvals, which regulated environments require. Scripts always need maintenance, and automation cannot fully replace exploratory testing, so those two statements are wrong.

Data-driven automation runs one script over many input and expected-result sets, which suits a rule applied across many combinations. Manual single-account checks, layout-only pixel comparisons and replaying one unparameterised session do not cover the rule's combinations.

API checks exercise the same business logic faster and with less fragility than UI scripts, which makes them suited to rule checking. They do not replace acceptance testing of screens, UI scripts are not banned by default, and responses still need expected results.