The definition of the results is expected from the test cases used for acceptance testing. The product must meet these criteria before implementation can be approved.
Formal testing conducted to determine wheter or not a system or component satisfies its acceptance criteria and to enable the client to determine wheter or not to accept that system or component.
Describes the steps the client will use to verify that theconstructed system meets the acceptance criteria. It defines the approach to be taken for acceptance testing activities. The plan identifies the items to be tested, the test objectives, the acceptance criteria, the testing to be performed, test schedules, entry/exit criteria, staff requirements, reporting requirements, evaluation criteria, and any risks requiring contingency planning.
Goal oriented passing through the product. Sometimes to prove or
disprove a notion of how the product will behave. A loosely structured
testing approach that allows test developers to be creative in their
test selection and execution. Ad-hoc testing is targeted as known or
suspected problem areas.
The part of the Test Phase of the PLC where code is complete and the product has achieved a degree of stability. The product is fully testable (determined by QA). All functionality has been implemented and QA has finished the implementation of the test plans/cases. Ideally, this when development feels the product is ready to be shipped.
A functional type of test that verifies the adequacy and effectiveness of controlsand completeness of data processing results.
A test focus area defined as the ability to provide supporting evidence to trace processing of data.
Creation of individual tests created to run without direct tester intervention.
A structural type of test that verifies the capability of the application to be restarted after a failure.
British Computer Society Information Systems Examination Board
The part of the Test Phase of the PLC where integration testing plans are finished, depth testing coverage goals met; Ideally, QA says product is ready to ship. The product is stable enough for external testing (determined by QA).
Tests in which the software under test is treated as a black box. You can't "see" into it. The test provides inputs and responds to outputs without considering how the software works.
Approach to integration testing where the lowest level components are tested first then used to facilitate the testing of higher level components. This process is repeated until the component at the top of the heirachy is tested. See "Top-down".
Test which focus on the boundary or limit conditions of the software being tested. (Some of these tests are stress tests).
A test case selection technique that selects test data that lie among "boundaries" or extremes among input and output possibilities. Boundary Value Analysis can apply to parameters, classes, data structures, variables, loops, etc.
A white box testing technique that requires each branch or decision point to be taken once.
Matrix tests which generally cover all product components and functions on an individual basis. These are usually the first automated tests available after the functional specifications have been completed and test plans have been drafted.
Generally a good thing to do after eating garlic and before going out into public. Or you may have to take a breath test if you're DUI.
(1) An operational version of a system or component that
incorporates a specified subset of the capabilites that the final
product will provide. Builds are defined whenever the complete system
cannot be developed and delivered in a single increment.
(2) A
collection of programs within a system that are functionally
independent. A build can be tested as a unit and can be installed
independent of the rest of the system.
A phenomenon with an understanding of why it happened.
A set of related activities that compromise a stand-alone unit of business. It may be defined as a process that results in the achievement of a business objective. It is characterised by well-defined start and finish activities and a workflow or pattern.
A model of the stages through which software organisations progress as they define, implement, evolve, and improve their software process. This model provides a guide for selecting process improvement strategies by determining current process capabilities and identifying the issues most critical to software quality and process improvement. This concept was developed by the Software Engineering Institute (SEI) at Carnegie Mellon University.
The evaluation of the cause of major errors, to determine actions that will prevent reoccurence of similar errors.
The process, by which a change is proposed, evaluated, approved or rejected, scheduled, and tracked.
A process methodology to identify the configuration of a release and to manage all changes through change control, data recording, and updating of baselines.
A documented proposal for change of one or more work items or work item parts.
Phase of the PLC where functionality is coded in entirety; bug fixes are all that are left. All functions found in the Functiona l Specifications have been implemented.
When development has finished all new functional code. This is when development is in a "bug fixing" stage.
Phase of the PLC where development is coding product to meet Functional/Architectural Specifications. QA develops test tools and test cases during this phase.
Tests that check for compatibility of other software or hardware with the software being tested.
The first level of dynamic testing and is the verification of new or changed code in an individual component (module, program, object, etc.) to determine whether all new and/or modified logic functions correctly. Also known as Unit testing.
Phase of the PLC where an idea for a new product is developed and a preliminary definition of the product is established. Research plans should be put in place and an initial analysis of the competition should be completed. The main goal of this phase is to determine product viability and obtain funding for further research.
A white box test method that requires all decision conditons be executed once for true and once for false.
(1) The process of identifying and defining the configuration items
in a system, controlling the release and change of these items
throughout the system life cycle, recording and reporting the status of
configuration items and change requests, and verifying the completeness
and correctness of configuration items.
(2) A discipline applying
technical and administrative direction and surveillance to (a) identify
and document the functional and physical characteristics of a
configuration items, (b) control changes to those characteristics, and
(c) record and report change processing and implementation status.
A functionaltype of test that verifies the compatability of converted programs, data and procedures with the "old" ones that are being converted or replaced. Also known as Migration Testing.
The extent to which tests exercise a program's functions, parameters, inputs, paths, branches, statements, conditions, modules or data flow paths.
Documentation procedure to indicate the testing coverage of test cases compared to possible elements of a program environment (i.e. inputs, outputs, parameters, paths, cause-effects, equivalence partitioning, etc.)
A test focus area defined as the ability to continue processing if problems occur. Included is the ability to backup and recover after a failure.
A test focus area defined as the ability to process data according to prescribed rules. Controls over transactions and data field edits provide an assurance on accuracy and completeness of data.
Shows which functions (i.e., GUI and C code level) have been touched and which have not.
The comma-separated values (or CSV; also known as a comma-separated list or comma-separated variables) file format is a file type that stores tabular data. The format dates back to the early days of business computing. For this reason, CSV files are common on all computer platforms.
CSV is one implementation of a delimited text file,
which uses a comma to separate values (where many implementations of
CSV import/export tools allow an alternate separator to be used; as is
shown in the MS Access screen shot, below). However CSV differs from
other delimiter separated file formats in using a " (double quote)
character around fields that contain reserved characters (such as
commas or newlines). Most other delimiter formats either use an escape
character such as a backslash, or have no support for reserved
characters.
In computer science terms, this type of format is
called a "flat file" because only one table can be stored in a CSV
file. Most systems use a series of tables to store their information,
which must be "flattened" into a single table, often with information
repeated over several rows, to create a delimited text file.
Testing in which test cases are designed basedon variable usage within the code
Verification of data to assure that it is still correct.
For date dependant applications.
DB2 is IBM's brand name for their database products. Each platform supports a slightly different set of features from the others.
Data and Communications Centre
To search for and eliminate malfunctioning elements or errors in the software.
Percentage of decision outcomes that have been exercised through (white box) testing.
See Fault.
A set of processes to manage the tracking and fixing of defects found during testing and to perform casual analysis.
See Design Phase.
This is when a component of a product is dependent on an outside group. The delivery of the product or the reaching a certain milestone is affected.
Encompasses Integration testing, real world testing, combinatorial testing, I nteroperability and compatibility testing.
Phase of the PLC where functions of the product are written down. Features and requirements are defined in this phase. Each department develops their departments' plan and resource requirements for the product during this phase.
(1) A formal meeting at which the preliminary or detailed design of
a system is presented to the user, customer or other interested parties
for comment and approval.
(2) The formal review of an existing or
proposed design for the purpose of detection and remedy of design
deficiencies that could attract fitness-for-use and environmental
aspects of the product, process or service, and/or for identification
of potential improvements of performance, safety and economic aspects.
Testing of software by the manual simulation of its execution. It is one of the static testing techniques.
The detailed plan for a specific level of dynamic testing. It defines what is to be tested and how it is to be tested. The plan typically identifies the items to be tested, the test objectives, the testing to be performed, test schedules, personnel requirements, reporting requirements, evaluation criteria, and any risks requiring contingency planning. It also includes the testing tools and techniques, test environment set up, entry and exit criteria, and administrative procedures and controls.
A functional type of test that verifies that the interface between the system and the people works and is usable. It also verifies that the instruction guides are helpful and accurate.
A major update to a product.
A program that exercises a system or system component by simulating the activity of a higher level component. Will either form a Test Harness, or be part of one.
Testing that is carried out by executing the code. Dynamic testing is a means of validating a work product by observing its behaviour in response to inputs.
Putting the components together and making sure they work.
A checklist of activities or work items that must be complete or exist, respectively, before the start of a given task within an activity or sub-activity.
See Test Environment.
Portion of the component's input or output domains for which the component's behaviour should be the same according to its specification.
(1) A discrepancy between a computed, observed or measured value or
condition and the true specified or theoretically correct value or
condition.
(2) A human action that results in software containing a
fault. This includes omissions or misinterpretations, etc. See Variance.
A test case selection process that identifies test cases based on knowledge and ability of the individual to anticipate problem errors.
A sequence of manual or automated steps required to carry out part of or all of a test design or execute a set of test cases.
(1) Actions that must happen before an activity is considered complete.
(2)
A checklist of activities or work items that must be complete or exist,
respectively, prior to the end of a given process stage, activity, or
sub-activity.
Predicted output data and file conditions associated with a particular test case. Expected results, if achieved, will indicate whether the test was successful or not. Generated and documented with the test case prior to execution of the test.
Deviation of the software from its expected delivery or servicev (BS 7925-1, after Fenton).
A manifestation of an error in software. A fault if encountered may cause a failure. Also known as defect, or bug.
A bug that no one wants to admit to.
A
flat file is a file that contains records, and in which each record is
specified in a single line. Fields from each record may simply have a
fixed width with padding, or may be delimited by whitespace, tabs,
commas (CSV) or other characters. Extra formatting may be needed to
avoid delimiter collision. There are no structural relationships. The
data are "flat" as in a she
et of paper, in contrast to more complex models such as arelational
database.
The
classic example of a flat file database is a basic name-and-address
list, where the database consists of a small, fixed number of fields:
Name, Address, and Phone Number. Another example is a simple HTML
table, consisting of rows and columns. This type of database is
routinely encountered, although often not expressly recognized as a
database.
The center of interest or activity. In software, focus refers to the area of the screen where the insertion point is active.
The process of verifying the consistency, completeness, and correctness of software and related work products (such as documents and processes) at each stage of the development life cycle.
(1) A specific purpose of an entity or its characteristic action.
(2) A set of related control statements that perform a related operation. Functions are sub-units of modules.
A functional type of test, which verifies that each business function operates according to the detailed requirements, the external and internal design specifications.
Phase of the PLC defining modules.
All of these have to be across different versions - that would be across development, production, system testing, and repair and all of these then have new releases.
Those kinds of test used to assure that the system meets the business requirements, including business functions, interfaces, usability, audit & controls, and error handling etc. See also Structural Test Types
See Green Master.
Phase of the PLC where the certification stage begins. All bugs, regressed against the product, must pass. Every build is a release candidate (determined by development).
Graphical User Interface.
Institute for Electrical and Electronical Engineering
(1) A realisation of an abstraction in more concrete terms; in particular, in terms of hardware, software, or both.
(2) The process by which a software release is installed in production and made available to end users.
An incident is an event which occurs during testing that requires subsequent investigation or correction. Usually, the event is a mismatch between the actual and expected results of a test. The cause can be one of a number of things:
- a defect in the software
- a fault in the test e.g. expected result was wrong
- the environment was wrong
- the test was run incorrectly e.g. enteredthe wrong input
- a documentation or specification fault i.e. the specification is wrong
Phase of the PLC after shipping (STM) where bugs are fixed for interim release. Maintenance of the product involves cleaning up bugs that are found after STM. Inlines are created to address these problems.
(1) A group review quality improvement process for written material,
consisting of two aspects: product (document itself) improvement and
process improvement (of both document production and inspection).
(2)
A formal evaluation technique in which software requirements, design,
or code are examined in detail by a person or group other than the
author to detect faults, violations of devolpment standards, and other
problems. Contrast with walk-through.
A non-functional type of test which verifies that the hardware, software and applications can be easily installed and run in the target environment.
Depth testing which covers groups of functions at the subsystem level.
Tests that verify operability between software and hardware.
Information Technology
An acronym for Joint Application Design. Formal session(s) involving clients and developers used to develop and document consensus on work products, such as client requirements, design specifications, etc.
Refers to the progression of software testing through static and dynamic testing.
Examples
of static testing levels are: Project Objectives Review, Requirements
Walkthrough, Design (External and Internal) Review, and Code
Inspection.
Examples of dynamic testing levels are: Unit
Testing, Integration Testing, System Testing, Acceptance Testing,
Systems Integration Testing and Operability Testing.
Also known as test level.
The software development process stages. Requirements, Design, Construction (Code/Program, Test), and Implementation.
A level of dynamic testing which verifies that individual components of an application or sub-system will communicate satisfactorily with one another; does not require that the application under test interface with other applications. Also known as Small-scale Integration Testing, or String testing.
Load tests study the behavior of the program when it is working at its limits. Types of load tests are Volume tests, Stress tests, and Storage tests.
This term refers to making software specifically designed for a specific locality.
A path that begins at an entry or decision statement and ends at a decision statement or exit.
A test focus area defined as the ability to locate and fix an error in the system. Can also be the ability to make dynamic changes to the system environment without making system changes.
See Inline.
A plan that addresses testing from a high-level system viewpoint. It
ties togetherall levels of testing (unit test, integration test, system
test, acceptance test, systems integration, and operability). It
includes test objectives, test team organisation and responsibilities,
high-level schedule, test scope, test focus, test levels and types,
test facility requirements, and test management procedures and
controls.
Metadata
is data about data. An item of metadata may describe an individual
datum, or content item, or a collection of data including multiple
content items.
Metadata (sometimes written 'meta data') is used
to facilitate the understanding, use and management of data. The
metadata required for effective data management varies with the type of
data and context of use. In a library, where the data is the content of
the titles stocked, metadata about a title would typically include a
description of the content, the author, the publication date and the
physical location. In the context of a camera, where the data is the
photographic image, metadata would typically include the date the
photograph was taken and details of the camera settings. On a portable
music player such as an Apple iPod, the album names, song titles and
album art embedded in the music files are used to generate the artist
and song listings, and are metadata. In the context of an information
system, where the data is the content of the computer files, metadata
about an individual data item would typically include the name of the
field and its length. Metadata about a collection of data items, a
computer file, might typically include the name of the file, the type
of file and the name of the data administrator.
A standard of measurement. Software metrics are the statistics describing the structure or content of a program. A metric should be a real objective measurement of something such as number of bugs per lines of code.
Events in the Product Life Cycle which define particular goals.
Microsoft Corporation
Master Test Plan
A functional type of test that verifies that the system does not do anything other than those things which it is supposed to do. As a by-product, this will exercise the system function for detecting and responding to execption conditions, thus verifying that incorrect transactions are properly handled.
Non - Functional
Non - Functional Requirements
Operational Acceptance Testing
This was a term coined by E.F. Codd & Associates who published a white paper in 1994, commissioned by Arbor Software (now Hyperion Solutions), entitled ‘Providing OLAP (On-line Analytical Processing) to User-Analysts: An IT Mandate’.
OLAP stands for ‘On-Line
Analytical Pr
ocessing’. But that is not only not a definition, it’s not even a clear
description of what OLAP means. It certainly gives no indication of why
you would want to use an OLAP tool, or even what an OLAP tool actually
does. And it gives you no help in deciding if a product is an OLAP tool
or not.
Online
Analytical Processing, or OLAP (IPA), is an approach to quickly provide
answers to analytical queries that are multidimensional in nature. OLAP
is part of the broader category business intelligence, which also
includes Extract transform load (ETL), relational reporting and data
mining.
The typical applications of OLAP are in business
reporting for sales, marketing, management reporting, business process
management (BPM), budgeting and forecasting, financial reporting and
similar areas. The term OLAP was created as a slight modification of
the traditional database term OLTP (Online Transaction Processing).
Databases configured for OLAP employ a multidimensional data mod
el, allowing for complex analytical and ad-hoc queries with a rapid execution time.
Nigel
Pendse has suggested that an alternative and perhaps more descriptive
term to describe the concept of OLAP is Fast Analysis of Shared
Multidimensional Information (FASMI). They borrow aspects of
navigational databases and hierarchical databases that are speedier
than their relational kin.
The output of an OLAP query is
typically displayed in a matrix (or pivot) format. The dimensions form
the row and column of the matrix; the measures, the values.
Sometimes sending your work off shore.
A test focus area defined as the effort required (of support personnel) to learn and operate a manual or automated system. Contrast with Usability.
A type of dynamic testing in which the operations of the system are validated in the real or closely simulated production environment. This includes verification of production JCL, installation procedures and operations procedures. Operability Testing considers such factors as resource consumption and adherence to standards. It is normally performed by Operations to assess the readiness of the system for the implementation in the production environment.
A functional type of test, which verifies that the same input to "old" and "new" systems produces the same results.
A white box testing technique that requires all code or logic paths to be executed once. Complete path testing is usually impractical and often uneconomical.
A test focus area defined as the ability of the system to perform certain functions within a prescribed time.
Test that measures how long it takes to do a function.
A structural type of test which verifies that the application meets the expected level of performance in a production-like environment.
A test focus area defined as ability for a system to operate in multiple operating environments.
A flaw without an understanding.
Product Life Cycle - see Software Product Life Cycle.
Pre-build 1; product definition phase. (Functional Specification may still be in proces s of being created).
(1) A call or report from a user. The call or report may or may not be defect orientated.
(2) A software or process deficiency found during development.
(3) The inhibitors and other factors that hinder an organisation's ability to achieve its goals and critical success factors.
(4) An issue that a project manager has the authority to resolve without escalation. Compare to 'defect' or 'error'.
The stages a product goes through from conception to completion. Phases of product development includes: Definition Phase, Functional/Architectural Specification Phase, Coding Phase, Code Complete Phase, Alpha, Beta, Zero Bug Build Phase, Green Master Phase, STM, and Maintenance/Inline Phase.
Phase of the PLC where the product must be defined with a prioritized feature list and system and compatibility requirements.
A general test plan given at the macro level which defines the activities of the test team through the stages of the Product Life Cycle.
A document which decribes the organisation, activities, and project factors that have been put in place to achieve the target level of quality for all work products in the application domain. It defines the approach to be taken when planning and tracking the quality of application development work products to ensure conformance to specified requirements and to ensure the client's expectations are met.
Integration testing which attempt to create environments which mirror how the product will be used in the "real world".
Retesting bugs in the system which had been identified as fixed, usually starting from Alpha on. Test ing is focussed on making sure none of the existing functionality has been broken by the new applications, this is often the final phase of the testing that is automated.
A test focus area defined as the extent to which the system will provide the intended function without failing.
(1) A condition or capability needed by the user to solve a problem or achieve an objective.
(2) A condition or capacbility that must be met or possesed by a system or system component to satisfy a contract, standard,
specification, or other formally imposed document. The set of all
requirements forms the basis for subsequent development of the system
or system component.
People, software, hardware, tools, etc. that have unique qualities and talents that can be utilized for a purpose.
Something that could potentially contribute to failing to reach a milestone.
A process or meeting during which a work product, or set of work products, is presented to project personnel, managers, users or other interested parties for comment or approval.
See Causal Analysis.
See Test Harness.
The
structure of a database system, described in a formal language
supported by the database management system (DBMS). In a relational
database, the schema defines the tables, the fields in each table, and
the relationships between fields and tables.
Schemas are
generally stored in a data dictionary. Although a schema is defined in
text database language, the term is often used to refer to a graphical
depiction of the database structure.
Service Delivery.
A test focus area defined as the assurance that the system/data resources will be protected against accidental and/or intentional modification or misuse.
A test which verifies that the application provides an adeqaute level of protection for confidential information and data belonging to other systems.
(1) The totatily of features and characteristics of a software product that bear on its ability to satisfy given needs; for example, conform to specifications.
(2) The degree to which software posseses a desired combination of attributes.
(3) The degree to which a customer or user perceives that software meets his or her composite expectations.
(4)
The composite characteristics of software that determine the degree to
which the software in use will meet the expectations of the customer.
(1) The probability that software will not cause the failure of a
system for a specified time under specified conditions. The probability
is a function of the inputs to and use of the system as well as a
function of the existence of faults in the software. The inputs to the
system determine whether existing faults, if any, are encountered.
(2) The ability of a program to perform a required function under stated conditions for a stated period of time.
Their implementation requirements and approach, and exposed API. Eac h function is specified here. This includes the expected results of each function.
A white box testing technique that requiresall code or logic statements to be executed at least once.
(1) The detailed examination of a work product's
characteristics to an expected set of attributes, experiences and
standards. The product under scrutiny is static and not exercised and
therefore its behaviour to changing inputs and environments cannot be
assessed.
(2) The process of evaluating a program without executing the program. See also desk checking, inspection, walk-through.
See Ship To Manufacturing.
Test how memory and space is used by the program, either in resident memory or on disk.
Determining the durability of a system by pushing it to its limits. Software stress testing is done by feeding the program erroneous data as well as activating all interface options in all possible sequences.
Structural functions describe the technical attributes of a system.
Evaluation techniques that are executed with the knowledge of the structure of the product under test. At component level, the objective of structural testing is to test the component's statements, code paths, conditions, or data flow paths at the level of technical design and implementation. At higher levels, some non-funcational tests may be structural in nature e.g. performance and security tests. Also known as White Box Testing or Glass Box Testing.
(1) A dummy program element or module used during the development and testing of a higher level element or module.
(2)
A program statement substituting for the body of a program unit and
indicating that the unit is or will be defined elsewhere.
The inverse of a Test Harness
A test that works in harmony with other tests. The timing is such that both tests work together, but yet independently.
A collection of components organised to accomlplish a specific function or a det of functions.
A dynamic level of testing which verifies that the application or sub-system under test integrates satisfactorily with its target infrastructure platforms and with the other applications/sub-systems with which it should interface. Also known as Large-scale Integration Testing, or Interface Testing.
A dynamic level of testing in which all the components thay compromise a system are tested to verify that the system functions together as a whole.
(1) A test environment containing the hardware, instrumental tools,
simulators, and other support software necessary for testing a system
or system component.
(2) A set of test files, (including databases
and reference files), in a known state, used with input test data to
test one or more test conditions, measuring against expected results.
(1) A set of test inputs, execution conditions, and expected results
developed for a particular objective, such as to exercise a particular
program path ot to verify compliance with a specified requirement.
(2) The detailed objectives, data, procedures, and expected results to conduct a test or part of a test.
A functional or structural attribute of an application, system, network, or component thereof to be tested.
A worksheet that is used for planning and for illustrating that all test conditions are covered by one or more test cases. Each test set has a Test Conditions Coverage Matrix. Rows are used to list the test conditions and columns are used to list all test cases in the test set.
A worksheet usedto formulate the test conditions that, if met, will produce the expected result. It is a tool used to assist in the design of test cases.
A worksheet used to plan and cross check to ensure all requirements and functions are covered adequately by test cases.
The input data and file conditions associated with a specific test case.
The external conditions or factors that can directly or indirectly influence the execution and results of a test. This includes the physical as well as operational environments. Examples of what is included in a test environment are: I/O and storage devices, data files, programs, JCL, communication lines, access control and security, databases, reference tables and files (version controlled), etc.
Those attributes of an application that must be tested in order to assure that the business and structural requirements are satisfied.
A program provided specifically to aid in the testing of another component or sub-system in isolation, by simulating the environment in which it will execute (e.g. by creating input messages for it). Also known as Scaffolding.
See Level of Testing.
A chronological record of all relevant details of a testing activity.
A collection of tables and matrices used to relate functions to be tested with the test cases that do so. Worksheets used to assist in the design and verification of test cases.
The tangible goals for assuring that the Test Focus areas previously selected as being relevant to a particular Business or Structural Function are being validated by the test.
Phase of the PLC where the entire product is tested, both internally and externally. Alpha and Beta Tests occur during this phase.
A specific plan that breakdown testing approaches on a functional area basis. The plan typically identifies the items to be tested, the test objectives, the testing to be performed, test schedules, entry/exit criteria, personnel requirements, reporting requirements, evaluation criteria, and any risks requiring contingency planning.
Detailed instructions for the set-up, operation, and evaluation of results for a given test. "A document providing detailed instructions for the execution of one or more test cases" [BS7925-1]
A document describing the conduct and results of the testing carried out for a system or system component.
A dated, time-stamped execution of a set of test cases.
A high-level description of how a given business or technical requirement will be tested, including the expected outcome; later decomposed into sets of test conditions, each in turn, containing test cases.
A sequence of actions that executes a test case. Previously synonymous with Test Procedure, but now has specialised use in automated testing. One or more test scripts may be part of a Test Procedure.
A collection of test consitions. Test sets are created for purposes of test execution only. A test set is created such that its size is manageable to run and its grouping of test conditions facilitates testing. The grouping reflects the application build strategy.
A worksheet that relates the test conditions to the test set in which the condition is to be tested. Rows list the test conditions and columns list the test sets. A checkmark in a cell indicated the test set will be used for the corresponding test condition.
A set of documents that define and describe the actual test architecture, elements, approach, data and expected results. Test Specification uses the various functional and non-functional requirement documents along with the quality and test plans. It provides the complete set of test cases and all supporting detail to achieve the objectives documented in the detailed test plan.
A high level description of major system-wide activities which collectively achieve the overall desired result as expressed by the testing objectives, given the constraints of time and money and the target level of quality. It outlines the approach to be used to ensure that the critical attributes of the system are tested adequately.
A set of test cases.
See Type of Testing.
(1) The extent to which software facilitates both the establishment
of test criteria and the evaluation of the software with respect to
those criteria.
(2) The extent to which the definition of requirements facilitates analysis of the requirements to establish test criteria.
The process of exercising or evaluating a program, product, or system, by manual or automated means, to verify that it satisfies specified requirements, to identify differences between expected and actual results.
The elements that are produced as part of the testing process. Testware includes plans, designs, test cases, test logs, test reports, etc.
Approach to integration testing where the component at the top of the component hierachy is tested first, with lower level components being simulated by stubs. Tested components are then used to test lower level components. The process is repeated until the lowest level components have been tested.
A functional type of test that verifies the proper and complete processing of a transaction from the time it enters the system to the time ofits completion or exit from the system.
Technology Solutions
Tests a functional or structural attribute of the system. E.g. Error Handling, Usability. Also known as test type.
See Component Testing.
The degree to which the intended target users can accomplish their intended goals.
(1) A functional type of test which verifies that the final product is user-friendly and easy to use.
(2) A test focus area defined as the end-user effort required to learn and use the system. Contrast with Operability Testing.
The final trial often undertaken by the users or customers themselves. Is the system or application "fit for use" by the intended user? See Acceptance Testing.
(1) The act of demonstrating that a work item is in compliance with
the original requirement. For example, the code of a module would be
validated against the input requirements it is intended to implement.
Validation answers the question "Is it the right system to build?"
(2)
Confirmation by examination and provision of objective evidence that
the particular requirements for a specific intended use have been
fulfilled. See also "Verification".
A mismatch between the actual and expected results occuring in testing. It may result from errors in the item being tested, incorrect expected results, invalid test data, etc. See "Error".
(1) The act of demonstrating that a work item is satisfactorily by
using its predecessor work item. For example, code is verified against
module level design. Verification answers the question "Is the system
being built right?"
(2) Confirmation by examination and provision of
objective evidence that specified requirements have been fulfilled. See
also "Validation".
Test the largest tasks a program can deal with.
A review technique characterised by the author of the object under review guiding the progression of the review. Observations made in the review are documented and addressed. Less formal evaluation technique that an inspection.
It is used to test areas that cannot be reached from a black box level. (Sometimes called Glass Box testing).
A software development lifecycle work product.
The Extensible Markup Language (XML) is a general-purpose markup language. It is classified as an extensible language because it allows its users to define their own tags. Its primary purpose is to facilitate the sharing of structured data across different information systems, particula rly via the Internet. It is used both to encode documents and serialize data.
Phase of the PLC where the product has stabilized in terms of bugs found and fixed. Development is fixing bugs as fast as they are found, the net resulting in zero bugs on a daily basis. This is usually determined when after a few builds have passed. This is the preliminary stage before Green Master.