Manual testing to automatic testing A formal training programme for testers at Bands 3 to 7

2.1.1 Describe the Configuration Needs of an Infrastructure that Enable Implementation of Test Automation

Part of 2 Preparing for Test Automation, 2.1 Understand the Configuration of an Infrastructure to Enable Test Automation.

Learning objective: TAE-2.1.1 (K2).

In short

Automation needs a testable system: one that lets tests see what it is doing (observability), make it do things (controllability), and understand how it is built (architecture transparency). Testability should be designed in from the start.

Key ideas

Testability is a non-functional requirement. It is usually the software architect's job, with a test automation engineer pointing out where it can improve, and it should be built at the same time as the features.

Ways to make a system easier to automate:

  • Accessibility identifiers: stable ids on elements, generated by the framework or set by developers.
  • System environment variables: application settings that can be changed to make testing easier.
  • Deployment variables: like environment variables, but set before deployment.

Three aspects of design for testability:

  • Observability: interfaces that show what the SUT is doing, so a test can compare actual and expected results.
  • Controllability: interfaces that let a test act on the SUT: user interface elements, function calls, protocols, or signals.
  • Architecture transparency: documentation that shows the components and interfaces clearly, at every test level.

In this programme

The testingexamples fixture site is designed for testability: every element has a stable id, such as select-example-1-id, so tests never depend on page layout. When your team's product lacks ids, ask developers to add them: it is the single biggest improvement to browser automation.

Teach it (30 minutes)

Open your team's product in the browser's developer tools. Find five elements a test would need. For each, note whether it has a stable id or test id. Write a short request to the developers for the ones that do not.

Check yourself

  1. Who is usually responsible for testability, and when should it be built?
  2. Explain observability and controllability, with one example of each.
  3. Why do stable element ids make automation more reliable?

Previous: 2.1 Understand the Configuration of an Infrastructure to Enable Test Automation · Contents · Next: 2.1.2 Explain How Test Automation is Leveraged within Different Environments

Based on the ISTQB Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) syllabus, version 2.0, section 2.1.1. The syllabus is © International Software Testing Qualifications Board (ISTQB®); ISTQB® is a registered trademark of the ISTQB. Copyright © 2024 the authors of the syllabus: Andrew Pollner (Chair), Péter Földházi, Patrick Quilter, Gergely Ágnecz, and László Szikszai. This page explains its concepts in our own words, for teaching, and is not an accredited course or a substitute for the syllabus.

View this document on GitHub materials/modules/module-5-istqb-certified-tester-advanced-level-test-automation-engineer/syllabus/2-1-1-describe-the-configuration-needs-of-an-infrastructure-that-enable-implementation-of-test-automation.md