[Automated-testing] Glossary words unfamiliar to enterprise testers

[Tim.Bird at sony.com]

Cyril,

In the recent summit, you mentioned that some of the terms in the glossary
that I sent with the survey were unfamiliar to you, and that you had to 
map them onto aspects of LTP that had different names (IIRC).

This may not be easy to do now that you know them, but could
you put an hash sign (#) before to the terms that were originally unfamiliar
to you, from the list below?  The reason for this request is that I would like to
identify the items that may not be obvious to non-embedded testers, and
either select a new term, or mark them, or put more information in the
description for these terms.

There was a good discussion at the summit about the "device under test"
terminology, and how different people interpreted this in different ways.

Thanks,
 -- Tim

P.S. Anyone else on the list who would like to mark terms that were originally
unfamiliar to them, can do so as well.  Just reply-all to this e-mail, and mark
the unfamiliar or problematic items with a hash sign.

Here is the originally-posted glossary:

* Bisection - automatic testing of SUT variations to find the source of a problem
* Boot - to start the DUT from an off state  (addition: point of time when a test can be started)
* Build artifact - item created during build of the software under test
* Build manager (build server) - a machine that performs builds of the software under test
* Dependency - indicates a pre-requisite that must be filled in order for a test to run (e.g. must have root access, must have 100 meg of memory, some program must be installed, etc.)
* Device under test (DUT) - the hardware or product being tested (consists of hardware under test and software under test) (also 'board', 'target')
* Deploy - put the test program or SUT on the DUT
** this one is ambiguous - some people use this to refer to SUT installation, and others to test program installation
* Device under Test (DUT) - a product, board or device that is being tested
* DUT controller - program and hardware for controlling a DUT (reboot, provision, etc.)
* DUT scheduler - program for managing access to a DUT (take online/offline, make available for interactive use)
** This is not shown in the CI Loop diagram - it could be the same as the Test Scheduler
* Lab - a collection of resources for testing one or more DUTs (also 'board farm')
* Log - one of the run artifacts - output from the test program or test framework
* Log Parsing - extracting information from a log into a machine-processable format (possibly into a common format)
* Monitor - a program or process to watch some attribute (e.g. power) while the test is running
** This can be on or off the DUT.
* Notification - communication based on results of test (triggered by results and including results)
* Pass criteria - set of constraints indicating pass/fail conditions for a test
* Provision (verb) - arrange the DUT and the lab environment (including other external hardware) for a test
** This may include installing the SUT to the device under test and booting the DUT.
* Report generation - collecting run data and putting it into a formatted output
* Request (noun) - a request to execute a test
* Result - the status indicated by a test - pass/fail (or something else) for a Run
* Results query - Selection and filtering of data from runs, to find patterns
* Run (noun) - an execution instance of a test (in Jenkins, a build)
* Run artifact - item created during a run of the test program
* Serial console - the Linux console connected over a serial connection
* Software under test (SUT) - the software being tested
* Test agent - software running on the DUT that assists in test operations (e.g. test deployment, execution, log gathering, debugging
** One example would be 'adb', for Android-based systems)
* Test definition - meta-data and software that comprise a particular test
* Test program - a script or binary on the DUT that performs the test
* Test scheduler - program for scheduling tests (selecting a DUT for a test, reserving it, releasing it)
* Test software - source and/or binary that implements the test
* Transport (noun) - the method of communicating and transferring data between the test system and the DUT
* Trigger (noun) - an event that causes the CI loop to start
* Variant - arguments or data that affect the execution and output of a test (e.g. test program command line; Fuego calls this a 'spec')
* Visualization - allowing the viewing of test artifacts, in aggregated form (e.g. multiple runs plotted in a single diagram)