Begriffserklärung - Versionsgeschichte

Cg: /* Abbreviations */

2023-08-10T08:41:29Z

Abbreviations

← Nächstältere Version		Version vom 10. August 2023, 08:41 Uhr
Zeile 132:		Zeile 132:
	* RPC - Remote Procedure Call		* RPC - Remote Procedure Call
	* SO - Shared Object (a synonym for DLL)		* SO - Shared Object (a synonym for DLL)
			* SOAP - Simple Object Access Protocol (a not so simple protocol)
			* SSDP - Simple Service Discovery Protocol
	* SUT - System Under Test		* SUT - System Under Test
	* UI - User Interface (often actually meaning: Graphical-UI)		* UI - User Interface (often actually meaning: Graphical-UI)

Cg: /* Abbreviations */

2023-08-10T08:39:28Z

Abbreviations

← Nächstältere Version		Version vom 10. August 2023, 08:39 Uhr
Zeile 124:		Zeile 124:
	* DCE - Distributed Computing Environment (an RPC mechanism)		* DCE - Distributed Computing Environment (an RPC mechanism)
	* DLL - Dynamic Link Library (a synonym for SO - shared object)		* DLL - Dynamic Link Library (a synonym for SO - shared object)
			* DUT - Device Under Test
	* EB - Elementary Block		* EB - Elementary Block
	* ".elf" - Expecco Log File (file suffix)		* ".elf" - Expecco Log File (file suffix)

Cg: /* SUT (System Under Test) */

2023-08-10T08:38:45Z

SUT (System Under Test)

← Nächstältere Version		Version vom 10. August 2023, 08:38 Uhr
Zeile 67:		Zeile 67:

	Technically, black box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.		Technically, black box tests interact with the SUT via (more or less official) external interfaces, such as messages, documents, communication interfaces, GUI interaction etc.
	White box tests can access data structures and interfaces internal to the SUT.		<br>White box tests can access data structures and interfaces internal to the SUT.

	In expecco, White Box Tests are done by implanting code into the SUT via code injection techniques. Depending on the type of technology and environment used, this injection (or instrumentation) may be possibly dynamically (Java or .NET) or has to be done statically by linking expecco-support libraries to the program (C, C++)		In expecco, White Box Tests are done by implanting code into the SUT via code injection techniques. Depending on the type of technology and environment used, this injection (or instrumentation) may be possibly dynamically (Java or .NET) or has to be done statically by linking expecco-support libraries to the program (C, C++).

	== Syntactic Sugar ==		== Syntactic Sugar ==

Cg: /* DUT (Device under Test) */

2023-08-10T08:37:33Z

DUT (Device under Test)

← Nächstältere Version		Version vom 10. August 2023, 08:37 Uhr
Zeile 21:		Zeile 21:

	== DUT (Device under Test) ==		== DUT (Device under Test) ==
	See [[#~~SUT/en~~\|SUT (~~Szstem~~ under Test)]]		See [[#SUT_.28System_Under_Test.29\|SUT (''System under Test'')]]

	== [[ElementaryBlock Element\|Elementary Block]] ==		== [[ElementaryBlock Element\|Elementary Block]] ==

Cg: /* Compound Step */

2023-08-10T08:36:47Z

Compound Step

← Nächstältere Version		Version vom 10. August 2023, 08:36 Uhr
Zeile 19:		Zeile 19:
	A step inside an activity diagram, whose action definition is a compound block. When triggered, such a step will execute another activity diagram.		A step inside an activity diagram, whose action definition is a compound block. When triggered, such a step will execute another activity diagram.
	See [[CompoundBlock Element/en\|Compound Block]] in the [[Tree Elements]] documentation.		See [[CompoundBlock Element/en\|Compound Block]] in the [[Tree Elements]] documentation.

			== DUT (Device under Test) ==
			See [[#SUT/en\|SUT (Szstem under Test)]]

	== [[ElementaryBlock Element\|Elementary Block]] ==		== [[ElementaryBlock Element\|Elementary Block]] ==

Cg: /* SUT (System Under Test) */

2023-08-10T08:35:33Z

SUT (System Under Test)

← Nächstältere Version		Version vom 10. August 2023, 08:35 Uhr
Zeile 59:		Zeile 59:

	== SUT (System Under Test) ==		== SUT (System Under Test) ==
	The tested system.		The tested system; often also called DUT ("''Device under Test''").

	Expecco interacts with this either in a pure black box (only talking to external interfaces), or gray to white box fashion (some or a lot of knowledge about internals of the SUT are known).		Expecco interacts with this either in a pure black box (only talking to external interfaces), or gray to white box fashion (some or a lot of knowledge about internals of the SUT are known).

Cg: /* Syntactic Sugar */

2023-08-10T08:34:41Z

Syntactic Sugar

← Nächstältere Version		Version vom 10. August 2023, 08:34 Uhr
Zeile 69:		Zeile 69:

	== Syntactic Sugar ==		== Syntactic Sugar ==
	A feature of (typically) a programming language, which does not give you more semantic features, but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "groovy" steps could be also defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively.		A feature of (typically) a programming language, which does not give you more semantic features, but instead exists for the convenience of the user. Typically "''syntactic sugar''" designates a feature which is easier to use or shorter to write, but which could also be defined in terms of other features of the language - albeit possibly more clumsy. In expecco, a number of syntactic sugar constructs are available, which could also be described in terms of regular action blocks. For example, the "attachment step", "shell step" and even "groovy" steps could also be defined in terms of regular elementary blocks which read a file, start a shell or talk to a JVM respectively.

	== Verdict ==		== Verdict ==

Cg: /* Verdict */

2023-08-10T08:33:35Z

Verdict

← Nächstältere Version		Version vom 10. August 2023, 08:33 Uhr
Zeile 90:		Zeile 90:
	:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.		:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

	Notice, that ~~many~~ test systems/frameworks only provide PASS/NOT PASS information as final verdict. ~~If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (eg. when running under the control of Jenkins, QC, Polarion etc.)~~		Notice, that most other test systems/frameworks only provide PASS/NOT PASS information as final verdict.
			<br>If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (eg. when running under the control of Jenkins, QC, Polarion etc.)

			If expecco is executed under the control of expeccoALM/Aidymo, the responsible person is chosen as per verdict and informed.

	== VersionID ==		== VersionID ==

Cg: /* Verdict */

2023-08-10T08:30:24Z

Verdict

← Nächstältere Version		Version vom 10. August 2023, 08:30 Uhr
Zeile 86:		Zeile 86:
	The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASS:		The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASS:
	* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.		* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
	* for an ERROR, ~~(s)he has to inform~~ the test-developer/analyst, to fix the problem in the test-case		* for an ERROR, the test-developer/analyst has to be informed, to fix the problem in the test-case
	* for INCONCLUSIVE, ~~(s)he has to check for the availability of required devices and possibly inform~~ the network administrator or test-lab-manager. ~~After~~ ~~that,~~ he ~~can rerun~~ the ~~test~~ ~~without~~ a ~~need~~ ~~to contact either the product-development~~, ~~nor~~ ~~the~~ ~~test-development~~ ~~team.~~		* for INCONCLUSIVE, the network administrator or test-lab-manager has to check for the availability of required devices, connections, power supply etc.
			:After that, the test can be rerun without a need to contact either the product-development, nor the test-development team.

	Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict. If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (eg. when running under the control of Jenkins, QC, Polarion etc.)		Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict. If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (eg. when running under the control of Jenkins, QC, Polarion etc.)

Cg: /* Verdict */

2023-08-10T08:28:39Z

Verdict

← Nächstältere Version		Version vom 10. August 2023, 08:28 Uhr
Zeile 75:		Zeile 75:
	The execution's summary-outcome-status from running a test plan, test case or individual action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always generate one of 4 values as a summary status:		The execution's summary-outcome-status from running a test plan, test case or individual action. In addition to detail information (traces, data, execution time, log-messages), every execution in expecco will always generate one of 4 values as a summary status:
	* PASSED<br>if all went well, and the execution did not encounter any problems		* PASSED<br>if all went well, and the execution did not encounter any problems
	* FAIL<br>the execution detected an error in the System Under Test (SUT)~~. For example, it measured a wrong value, detected invalid behavior of the SUT, invalid protocol behavior etc~~.		* FAIL<br>the execution detected an error in the System Under Test (SUT).
			:For example, it measured a wrong value, detected invalid behavior of the SUT, invalid protocol behavior etc.
⚫	* ERROR<br>the test itself ran into some error. This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks~~. For example, if a file containing test-data could not be found, if a division by zero occurred etc~~.
			* ERROR<br>the test itself ran into some error.
⚫	* INCONCLUSIVE<br>the test had no chance to perform its testing operations. For example, if a machine could not be reached in the network, if a resource (operator, measurement device, test-device etc.) was not available, etc.
		⚫	:This means that during the test's execution, an error occurred inside expecco or one of the user-defined action blocks.
			:For example, if a file containing test-data could not be found, if a division by zero occurred etc.
			* INCONCLUSIVE<br>the test had no chance to perform its testing operations.
			:This means that no information on the SUT's behavior could be provided.
		⚫	:For example, if a machine could not be reached in the network, if a resource (operator, measurement device, test-device etc.) was not available, etc.

	The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASS:		The distinction is very useful as it should be kept in mind, that a test-manager/tester has to react differently depending on the reason for a test not resulting in a PASS:
	* for a FAIL, he has to inform the developer of the SUT, to fix the problem in the product.		* for a FAIL, (s)he has to inform the developer of the SUT, to fix the problem in the product.
	* for an ERROR, he has to inform the test-developer/analyst, to fix the problem in the test-case		* for an ERROR, (s)he has to inform the test-developer/analyst, to fix the problem in the test-case
	* for INCONCLUSIVE, he has to check for the availability of required devices and possibly inform the network administrator or test-lab-manager. After that, he can rerun the test without a need to contact either the product-development, nor the test-development team.		* for INCONCLUSIVE, (s)he has to check for the availability of required devices and possibly inform the network administrator or test-lab-manager. After that, he can rerun the test without a need to contact either the product-development, nor the test-development team.

	Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict. If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (eg. when running under the control of Jenkins, QC, Polarion etc.)		Notice, that many test systems/frameworks only provide PASS/NOT PASS information as final verdict. If expecco is to be integrated into such a framework, FAIL, ERROR and INCONCLUSIVE will all be treated as NON-PASS (eg. when running under the control of Jenkins, QC, Polarion etc.)