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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.