Please enable JavaScript.

Coggle requires JavaScript to display documents.

CHAPTER 3, The Generic Test Automation Architecture (gTAA) - Coggle Diagram

- - - - Structured scripting approach, data-driven approach, and keyword-driven approach, which can be
        used for option 2 or 3
        
        PRO: significant reduction in the maintenance changes required and the reduced cost of automating new tests
        
        CON Greater effort and skills required to create the scripts
      - Model-based testing (including the process-driven approach), which can be used for option 4
        
        PRO allows by abstraction to concentrate on the essence of testing
        
        CON Modeling expertise is required to run a model-based testing approach effectively
      - Capture/playback approach, which can be used for option
        
        CON: hard to maintain and evolve
        
        PRO: easy to setup and use.
- - - - Defining the concept space, layers, services, and interfaces of a TAS to enable the realization of
        TASs by in-house as well as by externally developed components
      - Supporting simplified components for the effective and efficient development of test automation
      - Re-using test automation components for different or evolving TASs for software product lines and
        families and across software technologies and tools
      - Easing the maintenance and evolution of TASs
      - Defining the essential features for a user of a TAS
  - - - definition and implementation of test suites and/or test
        cases
        
        Specifying test cases (at a high and/or low level)
        
        Defining test data for low-level test cases
        
        Specifying test procedures for a test case or a set of test cases
        
        Defining test scripts for the execution of the test cases
        
        Providing access to test libraries as needed
    - - supports the execution of test cases and test logging
        
        Executing test cases automatically
        
        Logging the test case executions
        
        Reporting the test results
    - - designing test cases
        
        Manually designing test cases
        
        Developing, capturing, or deriving test data
        
        Automatically generating test cases from models that define the SUT and/or its environment
    - - provides the necessary code to adapt the automated tests for the
        various components or interfaces of the SUT
        
        Interacting with the SUT
        
        Monitoring the SUT
        
        Controlling the test harness
        
        Simulating or emulating the SUT environment
- - - - (Parts of) test cases, test data, test procedures or test libraries themselves
      - The test engine and/or test report framework
      - (Parts of) test models of test goals, test scenarios, test components or test data
      - The adaptors to the SUT components and/or interfaces
  - - - Technologies, programming languages or operating systems used to implement the SUT
        components
      - Libraries and packages the SUT components are using
      - Environments (both software and hardware) on which the SUT components run
      - Tools used to implement the SUT components
      - Number and interconnection of SUT components