Abstract: A test can include a combination of data and instructions encoded in a programming-language source file. The data can embedded within one or more programming constructs that are not subject to execution such as comments. The instructions can operate on the data. Additionally, various metadata can be included within one or both of a data portion and an instruction portion to facilitate specification of instructions that interact with data, among other things. The test can be subject to pre-processing to at least extract data and compile instructions. The compiled instructions can be executed over the data loaded on a system-under-test, and a determination can be made based thereon as to whether the system is operating correctly.

Abstract: A test case can be run with actions from the test case being executed in multiple execution paths. This can be done with the aid of an action broker. For example, the broker may identify available automation implementations for the actions and use a priority list to select between available automation implementations for executing an action from the test case. The broker may also perform conversions of results of actions for use by implementations executing other actions in different execution paths, as well as passing results between implementations in different execution paths.

Abstract: A test case is abstracted into a re-useable script or other declarative form that expresses the intent of a task rather that defining how the test will be performed. Tools translate the declarative test into a series of steps corresponding to code that implements the action indicated in the declarative test. The schema for the tests can be dynamic. New forms of test cases can take advantage of new actions so that the library of actions can be extended. Libraries are interchangeable. Test cases can be generated using a state machine. New test cases can be composed dynamically using a state machine to create new test cases.

Abstract: A test case can be run with actions from the test case being executed in multiple execution paths. This can be done with the aid of an action broker. For example, the broker may identify available automation implementations for the actions and use a priority list to select between available automation implementations for executing an action from the test case. The broker may also perform conversions of results of actions for use by implementations executing other actions in different execution paths, as well as passing results between implementations in different execution paths.

Abstract: A test case is abstracted into a re-useable script or other declarative form that expresses the intent of a task rather that defining how the test will be performed. Tools translate the declarative test into a series of steps corresponding to code that implements the action indicated in the declarative test. The schema for the tests can be dynamic. New forms of test cases can take advantage of new actions so that the library of actions can be extended. Libraries are interchangeable. Test cases can be generated using a state machine. New test cases can be composed dynamically using a state machine to create new test cases.

Abstract: Software failures are processed by categorizing images associated with the failures into groups based on similarities in the images. The categorizing of the images may be performed by a software failure analysis tool. The images may include full or partial screenshots of a computer at the time of the software failure. An image may be part of the output of a test, or may be part of a report of a software failure from an end user of the software. The software failure analysis tool may be part of a larger software test management system.