Please enable JavaScript.

Coggle requires JavaScript to display documents.

CHAPTER 4, Deployment Risks and Contingencies - Coggle Diagram

- - - - Create a procedure for maintaining the TAS and its infrastructure
      - Create the infrastructure for the TAS
      - Create a procedure for maintaining the test suite that the TAS will execute
      - Define the infrastructure in which the TAS will run
      - Risks
        
        Total execution time of the test suite may be longer than the planned execution time for the test
        cycle.
        
        Installation and configuration issues with test environment exist (e.g., database setup and initial
        load, services start/stop).
    - - Test the TAS for both new functionality and regressions
      - Check if the test suite needs to be adapted to the new version of the TAS
      - Make an assessment of the changes in the new version of the TAS compared to the old one
      - Risks
        
        Stubs, drivers and interfaces used in testing need to change to fit with the updated TAS
        
        The infrastructure needs to change to accommodate the updated TAS
        
        The test suite needs to change to run on the updated TA
        
        The updated TAS has additional defects or performance issues
- - - - Changes are made to correct failures of the TAS
    - - The TAS is optimized and non-functional issues are fixed
    - - Changes are made to make the TAS support more test types, test on multiple interfaces, test multiple versions of the SUT or support test automation for a new SUT.
    - - As new software systems are launched in the market (operating systems, database managers, web browsers, etc.), it may be required that the TAS supports them
  - - - It is easier to introduce new people to the test automation project when standard naming
        conventions are used.
      - The naming standards can refer to variables and files, test scenarios, keywords and keyword
        parameters
      - he test suite and the
        TAS itself has to be easy to read, understand, change and maintain
      - All the standards and conventions must be agreed upon and documented when starting a test
        automation project
    - - all the design, components, integrations with third parties, dependencies and deployment
        procedures need to be documented by someone.
      - It is a good practice to introduce the writing of documentation as part of the development process.
      - The need for good and current documentation for both the test scenarios and the TAS is quite clear,
        but there are two issues related to this: someone has to write it and someone has to maintain it.
    - - For each of the third party components, it is necessary to get information about updates and new
        versions.
      - There must be documentation regarding the license under which the third party components are
        used, so that there is information on whether they can be modified, to what degree and by whom.
      - It is necessary to have a plan in case these external components need to be modified or fixed
      - All the
        third party component parts of the TAS must be documented and under configuration management
    - - maintenance of the training material consists of initially writing it and then reviewing it periodically
      - training material is a combination of functional specifications of the TAS, design and architecture of the TAS, deployment and maintenance of the TAS, usage of the TAS (user manual), practical examples and exercises, and tips and tricks
      - If the documentation for the TAS is well-written, it can be used as a basis for the training material
        of the TAS
- - - - Plan the pilot
      - Conduct the pilot
        
        Does the TAS provide the functionality as expected (and promised by the vendor)?
        
        Do the TAS and the existing process support each other?
      - Identify a suitable project
        
        Do not select a trivial project
        
        Involve the necessary stakeholders (including management) in the selection process.
        
        Do not select a critical project
        
        The SUT of the pilot project should be a good reference for the other projects
      - Evaluate the pilot
    - - Monitor and evaluate the TAS in projects after a pre-defined period
      - Rollout to the rest of the organization/projects
      - Deploy the TAS in the selected projects
      - Identify initial target project(s
      - Success factors for deployment include
        
        Implementing a way to gather information about the actual use
        
        Monitoring TAS use, benefits and costs
        
        Defining usage guidelines
        
        Providing support for the test and development teams for a given TAS
        
        Providing training and coaching/mentoring for new users
        
        Gathering lessons learned from all teams
        
        Adapting and improving processes to fit with the use of the TAS
        
        Identifying and implementing improvements
        
        An incremental rollout