Browse Prior Art Database

Test Automation Scheduling Optimization

IP.com Disclosure Number: IPCOM000248967D
Publication Date: 2017-Jan-24
Document File: 6 page(s) / 435K

Publishing Venue

The IP.com Prior Art Database

Abstract

As software becomes more and more complex, the requirement to test that software also grows.  With that growth in testing demand comes a growth in the physical hardware required to test it.  The method disclosed solves this problem by allowing flexible test scheduling that optimizes the use of the testing hardware for both automated tests and user requests.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 35% of the total text.

1

Test Automation Scheduling Optimization

As software becomes more and more complex, the requirement to test that software also grows. With that growth in testing demand comes a growth in the physical hardware required to test it. The method disclosed solves this problem by allowing flexible test scheduling that optimizes the use of the testing hardware for both automated tests and user requests.

The core of the disclosed method has 2 innovative points: A read-only mode concept where an automated test (or a person) needs to check some1. data from a particular system which has a specific software level and is in a specific state

This allows a person or automated test to tag-along with an existing test suite run, in essence enabling multiple tests to be run in parallel on the same hardware

Analytics based pairing of test suites to optimize the hardware2. Give the innovation above, the test scheduling software can optimize which tests cases are paired on which hardware configurations For example, if test suites x,y,z all have a test case which requires state A, we could combine them onto the same hardware run Also, if tests are designated to run at a given state, and don't impact each other, they can be run in parallel

Determine each test cases system impact(s) and record in database

Recording the noted data in the boxes above is key for many reasons:

Recording system config changes: If two different test cases change the same configuration1. policy, or more broadly speaking, related configuration policies, the scheduling algorithm will attempt to place these testcases on different machines to ensure they do not create a conflict Recording all persistent file change: Similar to above, if two different test cases alter the2. same persistent file, then that can lead to conflicts when those tests run in parallel -and-

2

they could even create lingering conflicts even if serialized on the same machine. The scheduling algorithm should attempt to locate the tests on different machines Recording all application failures: If the dependency matrix of an application is known and3. application failures can be detected, then it's possible to calculate cases where a testcase or application dependency cannot be met on a given test environment, causing the test scheduler to divert an affected test case to a machine without such a failure Recording all system state changes: If a test case runs in a particular state or is determined4. to be the cause of a system state change, that information can be used to find other test cases that are either sensitive or agnostic to the given state changes, and depending on the answer, scheduled to the appropriate hardware.

Determine optimal assignment of test cases to each test system

We'll now look at 3 different examples showing the value of this patent.

1. 1 System, 2 Test Suites, 3 Tests in each Test Suite

Test Case 1 Test Case 2 Test Case 3

Test Suite 1 A B C

Test Suite 2 D E F

3

For simplicity we'll just assume 3 d...