1. Preface
    1. About MarathonITE
    2. Supported Platforms
      1. Java/Swing™
      2. Java/FX™
      3. Web Applications
    3. What's New in MarathonITE 5.0
    4. Change Log a.k.a Version History
    5. System Requirements
    6. Copyright Notice
  2. Getting Started
    1. Introduction to Test Automation
      1. Unattended Testing
      2. Semi Automated Testing
      3. Exploratory Testing
    2. MarathonITE Projects
    3. Your First Project
      1. Java/Swing™ Test Project
        1. Application Under Test - SwingSet3
        2. Creating a Project
        3. Recording a Test
        4. Anatomy of a Test Script
        5. Running Tests
        6. Looking at Results
      2. Java/FX™ Test Project
        1. Application Under Test - Ensemble
        2. Creating a Project
        3. Recording a Test
        4. Anatomy of a Test Script
        5. Running Tests
        6. Looking at Results
      3. Web Application Test Project
        1. Application Under Test - DuckDuckGo Search
        2. Creating a Project
        3. Recording a Test
        4. Anatomy of a Test Script
        5. Running Tests
        6. Looking at Results
    4. MarathonITE Sample Projects
  3. User Guide
    1. Installation and Startup
    2. MarathonITE User Interface
      1. Views
      2. Editors
      3. Output Views
    3. Creating Marathonite Test Projects
    4. Recording Tests
    5. Managing Checklists
    6. Exploratory Tests
    7. Semi Automated Tests
    8. Executing Tests
      1. Executing a Test from Editor
        1. Debugging Scripts
        2. Using Script Console
      2. Executing Tests from Test Runner
      3. Executing Tests in Batch Mode
    9. Organizing Tests
      1. Organizing Tests in Folder Heirarchy
      2. Organizing Tests as Features and Stories
      3. Organizing Tests in Suites
      4. Linking Tests to TMS and Issue Manager
    10. Modularizing Test Scripts
      1. Module Methods
      2. Extract Method Refactoring
      3. Using Data Loops
      4. Convert to Data Loop Refactoring
    11. Data Driven Tests
      1. Convert to DDT Refactoring
  4. Advanced Scripting
    1. Ruby Programming Language
    2. Marathon and Ruby
    3. Selenium/WebDriver Bindings
      1. Java/Swing™ Components
      2. Java/FX™ Controls

2.1.1.Unattended Testing

When we talk about test automation, usually we refer to unattended testing. However, test automation tools like MarathonITE can also be used to reduce the effort required for executing other types of testing – semi automated or manual/exploratory tests.

You get the best results from a test automation effort when you can run your test suites unattended. You can achieve this by integrating test automation with external systems like your source control system or a continuous integration server.

Planning for Unattended Testing

Identify a Trigger Point
When do you want the test suites to be executed? The simplest solution may be to trigger a test run at some specific time every day. Another way is to schedule a test run whenever developers update your source control system. If you go this way, you may want to schedule the run only when a specific action is taken – like a feature complete option of git-flow. You may also use a CI server and use its functionality to schedule the test run.

Nothing in the above precludes you from using multiple strategies together. You can schedule a test run every day at 2AM as well as whenever a module is updated in the code repository. You can be creative and flexible in identifying the trigger points.

Remove Interdependencies
If your test scripts are interdependent, then you will be forced to run the tests in a particular sequence. Besides being a bad practice, this will preclude you from executing the tests in parallel for reducing the .

Most interdependent test scripts can be made independent of each other using Fixtures to setup a known environment for each of the test scripts.

Dedicated Resources
Run your tests on dedicated machines to avoid disruptions by other users.

Easily accessible reports
Ensure that the test results are available in a central repository accessible to all the stake holders. It is a good practice to send a message to all the team members with the test result – specifically if they are errors.

Setup a Process to fix the issues
If you do not work and fix the issues raised by the test execution as soon as possible – the failures rolls over. Over a period of time the failures overwhelm your team and the reports gets ignored. Ensure that you have a process in place for working on the test failures.

One of the teams I worked on used to give it the highest priority. Any failures identified by the CI Server used to be worked on and any other work is kept pending till all the failures are resolved.

Suggest Edit