LEARN. PRACTICE. GROW.Concept and mechanism
Before choosing a tool, identify the question needing an answer and how often that answer will be needed. One team may want to detect incompatible API changes before integrating services; another needs to confirm that an operator can complete a browser journey. The two needs may justify different mechanisms. The system under test, or SUT, is the object being investigated. The automation solution includes test code, libraries, data, environments, configuration, and reports producing evidence about that object. Confusing the two complicates diagnosis: a test-environment setup failure does not automatically demonstrate a product defect.
Guided application
In a fictional reconciliation project, the calculation rule is stable while screens change weekly. Checking every combination through the interface may make maintenance dominant. Consider checking the rule at a level offering direct access and reserving interface journeys for interaction and integration risks. Confirm that the team can maintain the code and interpret failures during APS transition. Automation can repeat checks quickly and support data preparation, but it does not remove human investigation or independently decide which risk the business accepts. Record limitations and recurring costs, including dependency upgrades, false-alarm diagnosis, and adaptation to new product versions.
A runner failure can prevent testing without demonstrating SUT failure.
Common pitfalls
Tool before purpose; all logic through the interface; confusing infrastructure and product.
Related topics: Testability and tool evaluation · Architecture, layers, and data · Pilot, fixtures, and maintenance
Define required evidence and its scope.
Reference: ISTQB CTAL-TAE syllabus · CTAL-TAE v2.0 (2024)