- CAST
- Cause-effect graphing
- Change
- Change order
- Change request
- Change management
- Class testing
- Code-based testing
- Component testing
- Condition determination coverage
- Configuration
- Configuration item
- Configuration management
- Constructive quality assurance
- Control flow
- Control flow anomaly
- Control-flow-based test
- Control flow graph
- Coverage
- Custom software (bespoke software)
- Cyclomatic complexity
CAST
CAST is an acronym for Computer Aided Software Testing. It descibes support for software tests using test tools for management purposes (e.g. Zeta Test). CAST should provide comfortable data capture, cataloging and management of test cases, as well as ways of prioritising and monitoring them.
Tools associated with test management include programs for requirements, management, failure management and configuration.
Cf. test automation in Wikipedia.
Cause-effect graphing
This is a function-oriented black-box testing method which is designed as a cause-effect graph; the graph is then used to produce test-cases.
Change
Reediting or rewriting a product that has already been released - e.g. program documentation or source code.Change order
This is the order, originating either from a client or internally, authorising either a change of or an extension to a product.Change request
A change request is a formal request made regarding an adjustment to the characteristics or behaviour of a product such as software. A change request is a written document; it is often shortened to CR or RFC (request for change).
A well-formulated CR includes not only a request but a description of the current situation. Planned costing and timeframe are also included.
Change management
The change management process in Systems Engineering is the process of requesting, determining the attainability of, planning, implementing and evaluating changes to a system. It has two main goals: supporting the processing of changes and enabling traceability of changes.
See also change management in Wikipedia.
Class testing
Refers to a method of testing object oriented projects (OOP) using classes.
For an explanation of classes in computer sciences, see class on Wikipedia.
Code-based testing
This refers to structural testing such as white-box testing.Component testing
Component tests, also called unit tests, are tests of a single component of an integrated software application. The test is carried out by using a pre-developed program code. Popular frameworks used here are JUnit or NUnit.
See also unit testing on Wikipedia.
Condition determination coverage
This is a part of white-box testing whereby single conditions in a given decision statement (i.e. a statement which is either true or false) are tested in exactly the combinations which affect a decision outcome.
Cf. code condition coverage on Wikipedia.
Configuration
The configuration is the number and nature of parts that make up a system or part of a system in a given version of a software application. Furthermore, configuration can also be used to refer to the state of the test object's environment required for a certain test case to be run.
For further information, see the software configuration management (SCM) entry on Wikipedia.
Configuration item
This is the object of a configuration management system.Configuration management
This refers to the methodology for managing configurations. It is based around defining and documenting the characterstics and processes of items in configurations.
Cf. Software configuration management (abbrev. SCM).
Constructive quality assurance
This is a form of quality assurance which relies on using methods, tools and guidelines to ensure that software application are developed with the characteristics requested and planned.
The aim is to reduce or even comprehensively eliminate faults and mistakes.
Cf. quality assurance on Wikipedia.
Control flow
Refers to the representation of a sequence of events such as statements, instructions and calls (known as paths) that occur as a software component or system is executed.
Cf. controll flow on Wikipedia.
Control flow anomaly
This term refers to an error which occurs while a test component is executed. An prime example of a control flow anomaly is if certain statements are not reached at all in the testing process.
Control-flow-based test
This is a dynamic testing method - also known as control-flow-oriented testing - in which the control flow of a component to be tested is used to design the test cases.
Control flow graphs are then used to test the completeness of the tests - cf. coverage ratio.
Control flow graph
Starting at the beginning of the execution of component or system, a control flow graph provides an abstract representation of how other nodes can be reached all the way through to the end of a flow.
Graphs are often used for ease when the structures of control flow paths are being shown.
For further information and example graphs, see control flow graph on Wikipedia.
Coverage
This is a criteria on which decisions as to whether to end or continue testing are often made. It is the degree, expressed in percent, to which test object code has been executed by testing. Depending on the testing method, the required percentage may be either high or low; software tools are usually used to define the ideal coverage per test object.
See the Wikipedia entry on code coverage for more detailed information.
Custom software (bespoke software)
This is software developed especially for individuals, companies or groups of customers. Often refered to as "custom solution", bespoke software is about adapting programs to fill customer requirements to the fullest extent.
The opposite of custom software is an off the shelf solution.
Cf. custom software on Wikipedia.
Cyclomatic complexity
This is a metric used to measure the complexity of control flow graphs. It is based on the number of possible independent paths through a program or a graphical representation of it.