Types of Testings and Their Strategies

Jagan Mohan Julooru Types of Testing & their Strategies
TYPES OF TESTINGS AND THEIR STRATEGIES
INDEX
1. Quality Assurance Activities 2
2. Structured Walkthroughs and Technical Reviews 3
3. The Testing Strategy 4
4. Testing strategy / test plan 5
5. Black Box Testing Strategy 7
6. White Box Testing Strategy 10
7. Testing Terminology 12
8. Automated Testing Terminology 17
9. Software Testing Dictionary 18
10. GUI Testing 38
11. Object-Oriented Testing: Myth and Reality 52
12. Keyword Based Test Automation 56
QUALITY ASSURANCE ACTIVITIES
The term "software quality" is used extensively in the world of applications development.
Software quality is an elusive term that has different meanings to different people.
For the purposes of this document, a high-quality application is one that:
• carries out the purpose intended by the user.

• is delivered on time and within budget.
• has no errors.
• can be maintained and modified to meet changing conditions at a minimal cost.
Quality cannot be tested into an application, it must be built into it. Software Quality Assurance
(SQA) is an "umbrella activity" applied throughout the development process to ensure that proper
quality controls are built into the development process. Software Quality Assurance
encompasses:
• standard analysis, design, and development techniques.

• formal technical reviews and walkthroughs.
• informal technical reviews and walkthroughs.
• testing strategies.
• configuration management and change control procedures.
• assessment and reporting mechanisms.
Software Quality Assurance begins with proven technical methods and techniques. These
"methods and techniques" are the tasks and deliverables comprising the System Development
Methodology. It is the responsibility of the Project Manager to ensure that all project activities and
work products are performed and developed in accordance with the System Development
Methodology. It is also there responsibility for supporting standards and guidelines for activities
and products.
STRUCTURED WALKTHROUGHS AND TECHNICAL REVIEWS
The two most effective techniques for assuring software quality are Structured Walkthroughs and
Technical Reviews. These project reviews occur many times throughout the development
process. The principle objective of these reviews is to use participants' "fresh look" at the product
(deliverable) to find as many errors, deficiencies, or problems as possible, so that they can be
fixed before additional work is performed. This technique is based on the fact that the earlier an
error is found, the cheaper it is to fix.
A Technical Review is an informal review by the project team of an intermediate deliverable (i.e.
data model, function hierarchy, procedure logic, etc.). The product is scrutinized for
completeness, correctness, consistency, technical feasibility, efficiency, and adherence to
established standards and guidelines by the Client Organization. Technical Reviews should be
performed for all deliverables outlined in CASE*Method.
The Structured Walkthrough is a review of the formal deliverables (i.e. those deliverables which
are reviewed and signed-off by the client organization) produced by the project team. Participants
of this review typically include end-users and management of the client organization,
management of the development organization, and sometimes auditors from the Comptroller's
office, as well as members of the project team. As such, these reviews are more formal in nature
with a predefined agenda, which may include presentations, overheads, etc. The Project
Manager determines the degree of formality.
The materials to be reviewed should be distributed to participants at least two days prior to the
review date to ensure adequate time for review and preparation. Structured Walkthroughs are
major milestones in the project and should be represented as such in the project plan and
schedule.
THE TESTING STRATEGY
An initial testing strategy is developed upon completion of the Analysis Stage and may be refined
and updated during the Design and Build stages by the project manager, the project team, and
the end-user organization.
Proper testing of the software is critical to the overall quality of the end-product application.
Historically, it is also the most neglected or over-looked component of the development process.
As such, the testing process must be properly planned and methodically executed to ensure
acceptable quality standards.
A testing strategy is formed during the Analysis Stage after system requirements have been
refined and stabilized. Test specifications are developed for each software module based on the
detailed module design specifications. A test specification outlines test objectives, provides test
cases and scenarios, the test data to be used, and expected test results.
At a minimum, the Testing Strategy should address the following:
• Module Testing: (also refered to unit testing) Focuses on verification of the smallest unit
of software design -- the module. Using the detailed design specification as a guide,
important control paths are tested to uncover errors within the boundary of the module.
The man to machine interfaces are tested to assure that information properly flows into
and out of the module, allowable boundary values are verified, and module-data structure
interface is tested to assure that data is properly stored according to established integrity
rules. Module testing is performed during the Build Stage.
• System Testing: (also referred to as integration testing) ensures that the system as a
whole satisfies input/output specifications and that interfaces between
modules/programs/subsystems are correct. Emphasis is placed on system access,
security, performance, and recovery capabilities. System Testing maybe be performed at
the closing of the Build Stage.
• Acceptance Testing: Acceptance testing is performed by the client organization with
support from the project team to ensure that the application satisfies established
acceptance criteria and that both manual procedures and automated functions perform
according to stated requirements. Acceptance testing is performed during the Transition
Stage. A detailed acceptance test package should be prepared identifying what is to be
tested and providing space for signoff and notation of problems. A sample is available
among the document templates.
TESTING STRATEGY / TEST PLAN
Purpose
It is the role of test management to ensure that new or modified service products meet the
business requirements for which they have been developed or enhanced.
The purpose of test management is to ensure that a testing strategy is both devised and applied
that is efficient, effective and economic.
The testing strategy should define the objectives of all test stages and the techniques that apply.
The testing strategy also forms the basis for the creation of a standardised documentation set,
and facilitates communication of the test process and its implications outside of the test discipline.
Any test support tools introduced should be aligned with, and in support of, the test strategy.
Test management is also concerned with both test resource and test environment management.
Key elements of test management include:
• Test organisation –the set-up and management of a suitable test organisational structure
and explicit role definition. The project framework under which the testing activities will be
carried out is reviewed, high level test phase plans prepared and resource schedules
considered. Test organisation also involves the determination of configuration standards
and the definition of the test environment.
• Test planning – the requirements definition and design specifications facilitate in the
identification of major test items and these may necessitate the test strategy to be
updated. A detailed test plan and schedule is prepared with key test responsibilities being
indicated.
• Test specifications – required for all levels of testing and covering all categories of test.
The required outcome of each test must be known before the test is attempted.
• Unit, integration and system testing – configuration items are verified against the
appropriate specifications and in accordance with the test plan. The test environment
should also be under configuration control and test data and results stored for future
evaluation.
• Test monitoring and assessment – ongoing monitoring and assessment of the integrity of
the development and construction. The status of the configuration items should be
reviewed against the phase plans and test progress reports prepared providing some
assurance of the verification and validation activities.
• Product assurance – the decision to negotiate the acceptance testing programme and the
release and commissioning of the service product is subject to the ‘product assurance’
role being satisfied with the outcome of the verification activities. Product assurance may
oversee some of the test activity and may participate in process reviews.
A common criticism of construction programmes is that insufficient time is frequently allocated to

the testing and commissioning of the building systems together with the involvement and
subsequent training of the Facilities Management team. Testing and commissioning is often
considered by teams as a secondary activity and given a lower priority particularly as pressure
builds on the programme towards completion.
Sufficient time must be dedicated to testing and commissioning as ensuring the systems function
correctly is fairly fundamental to the project’s success or failure. Traditionally the responsibility for
testing and commissioning is buried deep within the supply chain as a sub-contract of a sub-
contract. It is possible to gain greater control of this process and the associated risk through the
use of specialists such as Systems Integration who can be appointed as part of the professional
team.
The time necessary for testing and commissioning will vary from project to project depending
upon the complexity of the systems and services that have been installed. The Project Sponsor
should ensure that the professional team and the contractor consider realistically how much time
is needed.
BLACK BOX TESTING STRATEGY
Black Box Testing is not a type of testing; it instead is a testing strategy, which does not need any
knowledge of internal design or code etc. As the name "black box" suggests, no knowledge of internal logic
or code structure is required. The types of testing under this strategy are totally based/focused on the testing
for requirements and functionality of the work product/software application. Black box testing is sometimes
also called as "Opaque Testing", "Functional/Behavioral Testing" and "Closed Box Testing".
The base of the Black box testing strategy lies in the selection of appropriate data as per functionality and
testing it against the functional specifications in order to check for normal and abnormal behavior of the
system. Now a days, it is becoming common to route the Testing work to a third party as the developer of
the system knows too much of the internal logic and coding of the system, which makes it unfit to test the
application by the developer.
In order to implement Black Box Testing Strategy, the tester is needed to be thorough with the requirement
specifications of the system and as a user, should know, how the system should behave in response to the
particular action.
Various testing types that fall under the Black Box Testing strategy are: functional testing, stress testing,
recovery testing, volume testing, User Acceptance Testing (also known as UAT), system testing, Sanity or
Smoke testing, load testing, Usability testing, Exploratory testing, ad-hoc testing, alpha testing, beta testing
etc.
These testing types are again divided in two groups: a) Testing in which user plays a role of tester and b)
User is not required.
Testing method where user is not required:
Functional Testing:
In this type of testing, the software is tested for the functional requirements. The tests are written in order to
check if the application behaves as expected.
Stress Testing:
The application is tested against heavy load such as complex numerical values, large number of inputs,
large number of queries etc. which checks for the stress/load the applications can withstand.
Load Testing:
The application is tested against heavy loads or inputs such as testing of web sites in order to find out at
what point the web-site/application fails or at what point its performance degrades.
Ad-hoc Testing:
This type of testing is done without any formal Test Plan or Test Case creation. Ad-hoc testing helps in
deciding the scope and duration of the various other testing and it also helps testers in learning the
application prior starting with any other testing.
Exploratory Testing:
This testing is similar to the ad-hoc testing and is done in order to learn/explore the application.
Usability Testing:
This testing is also called as ‘Testing for User-Friendliness’. This testing is done if User Interface of the
application stands an important consideration and needs to be specific for the specific type of user.
Smoke Testing:
This type of testing is also called sanity testing and is done in order to check if the application is ready for
further major testing and is working properly without failing up to least expected level.
Recovery Testing:
Recovery testing is basically done in order to check how fast and better the application can recover against
any type of crash or hardware failure etc. Type or extent of recovery is specified in the requirement
specifications.
Volume Testing:
Volume testing is done against the efficiency of the application. Huge amount of data is processed through
the application (which is being tested) in order to check the extreme limitations of the system.
Testing where user plays a role/user is required:
User Acceptance Testing:
In this type of testing, the software is handed over to the user in order to find out if the software meets the
user expectations and works as it is expected to.
Alpha Testing:
In this type of testing, the users are invited at the development center where they use the application and the
developers note every particular input or action carried out by the user. Any type of abnormal behavior of the
system is noted and rectified by the developers.
Beta Testing:
In this type of testing, the software is distributed as a beta version to the users and users test the application
at their sites. As the users explore the software, in case if any exception/defect occurs that is reported to the
developers.
WHITE BOX TESTING STRATEGY
White box testing strategy deals with the internal logic and structure of the code. White box testing is also
called as glass, structural, open box or clear box testing. The tests written based on the white box testing
strategy incorporate coverage of the code written, branches, paths, statements and internal logic of the code
etc.
In order to implement white box testing, the tester has to deal with the code and hence is needed to possess
knowledge of coding and logic i.e. internal working of the code. White box test also needs the tester to look
into the code and find out which unit/statement/chunk of the code is malfunctioning.
Advantages of White box testing are:
i) As the knowledge of internal coding structure is prerequisite, it becomes very easy to find out which type
of input/data can help in testing the application effectively.
ii) The other advantage of white box testing is that it helps in optimizing the code
iii) It helps in removing the extra lines of code, which can bring in hidden defects.
Disadvantages of white box testing are:
i) As knowledge of code and internal structure is a prerequisite, a skilled tester is needed to carry out this
type of testing, which increases the cost.
ii) And it is nearly impossible to look into every bit of code to find out hidden errors, which may create
problems, resulting in failure of the application.
Types of testing under White/Glass Box Testing Strategy:
Unit Testing:
The developer carries out unit testing in order to check if the particular module or unit of code is working
fine. The Unit Testing comes at the very basic level as it is carried out as and when the unit of the code is
developed or a particular functionality is built.
Static and dynamic Analysis:
Static analysis involves going through the code in order to find out any possible defect in the code. Dynamic
analysis involves executing the code and analyzing the output.
Statement Coverage:
In this type of testing the code is executed in such a manner that every statement of the application is
executed at least once. It helps in assuring that all the statements execute without any side effect.
Branch Coverage:
No software application can be written in a continuous mode of coding, at some point we need to branch out
the code in order to perform a particular functionality. Branch coverage testing helps in validating of all the
branches in the code and making sure that no branching leads to abnormal behavior of the application.
Security Testing:
Security Testing is carried out in order to find out how well the system can protect itself from unauthorized
access, hacking – cracking, any code damage etc. which deals with the code of application. This type of
testing needs sophisticated testing techniques.
Mutation Testing:
A kind of testing in which, the application is tested for the code that was modified after fixing a particular
bug/defect. It also helps in finding out which code and which strategy of coding can help in developing the
functionality effectively.
Besides all the testing types given above, there are some more types which fall under both Black box and
White box testing strategies such as: Functional testing (which deals with the code in order to check its
functional performance), Incremental integration testing (which deals with the testing of newly added code in
the application), Performance and Load testing (which helps in finding out how the particular code manages
resources and give performance etc.) etc.
TESTING TERMINOLOGY
Testing Terminology can be somewhat ambiguous for both experienced testers and neophyte
testers alike. The following set of definitions is by no means the industry standard and should be
viewed as a guideline in forming an understanding of Testing Terminology. The terms used in this
Glossary are organized by subject matter.
Testing Levels / Phases
Testing levels or phases should be applied against the application under test when the previous
phase of testing is deemed to be complete. Or .complete enough. Any defects detected during
any level or phase of testing need to be recorded and acted on appropriately.
Design Review
"The objective of Design Reviews is to verify all documented design criteria before development
begins." The design deliverable or deliverables to be reviewed should be complete within
themselves. The environment of the review should be a professional examination of the
deliverable with the focus being the deliverable not the author (or authors). The review must
ensure each design deliverable for: completeness, correctness, and fit (both within the business
model, and system architecture).
Design reviews should be conducted by: system matter experts, testers, developers, and system
architects to ensure all aspects of the design are reviewed.
Unit Test
"The objective of unit test is to test every line of code in a component or module." The unit of
code to be tested can be tested independent of all other units. The environment of the test should
be isolated to the immediate development environment and have little, if any, impact on other
units being developed at the same time. The test data can be fictitious and does not have to bear
any relationship to .real world. business events. The test data need only consist of what is
required to ensure that the component and component interfaces conform to the system
architecture. The unit test must ensure each component: compiles, executes, interfaces, and
passes control from the unit under test to the next component in the process according to the
process model.
The developer in conjunction with a peer should conduct unit test to ensure the component is
stable enough to be released into the product stream.
Function Test
"The objective of function test is to measure the quality of the functional (business) components
of the system." Tests verify that the system behaves correctly from the user / business
perspective and functions according to the requirements, models, storyboards, or any other
design paradigm used to specify the application. The function test must determine if each
component or business event: performs in accordance to the specifications, responds correctly to
all conditions that may be presented by incoming events / data, moves data correctly from one
business event to the next (including data stores), and that business events are initiated in the
order required to meet the business objectives of the system.
Function test should be conducted by an independent testing organization to ensure the various
components are stable and meet minimum quality criteria before proceeding to System test.
System Test
"The objective of system test is to measure the effectiveness and efficiency of the system in the
"real-world" environment." System tests are based on business processes (workflows) and
performance criteria rather than processing conditions. The system test must determine if the
deployed system: satisfies the operational and technical performance criteria, satisfies the
business requirements of the System Owner / Users / Business Analyst, integrates properly with
operations (business processes, work procedures, user guides), and that the business objectives
for building the system were attained.
There are many aspects to System testing the most common are:
• Security Testing: The tester designs test case scenarios that attempt to subvert or bypass
security.
• Stress Testing: The tester attempts to stress or load an aspect of the system to the point of
failure; the goal being to determine weak points in the system architecture.
• Performance Testing: The tester designs test case scenarios to determine if the system
meets the stated performance criteria (i.e. A Login request shall be responded to in 1 second
or less under a typical daily load of 1000 requests per minute.)
• Install (Roll-out) Testing: The tester designs test case scenarios to determine if the
installation procedures lead to an invalid or incorrect installation.
• Recovery Testing: The tester designs test case scenarios to determine if the system meets
the stated fail-over and recovery requirements.
System test should be conducted by an independent testing organization to ensure the system is
stable and meets minimum quality criteria before proceeding to User Acceptance test.
User Acceptance Test
"The objective of User Acceptance test is for the user community to measure the effectiveness
and efficiency of the system in the "real-world" environment.". User Acceptance test is based on
User Acceptance criteria, which can include aspects of Function and System test. The User
Acceptance test must determine if the deployed system: meets the end Users expectations,
supports all operational requirements (both recorded and non-recorded), and fulfills the business
objectives (both recorded and non-recorded) for the system.
User Acceptance test should be conducted by the end users of the system and monitored by an
independent testing organization. The Users must ensure the system is stable and meets the
minimum quality criteria before proceeding to system deployment (roll-out).
Testing Roles
As in any organization or organized endeavor there are Roles that must be fulfilled within any
testing organization. The requirement for any given role depends on the size, complexity, goals,
and maturity of the testing organization. These are roles, so it is quite possible that one person
could fulfill many roles within the testing organization.
Test Lead or Test Manager
The Role of Test Lead / Manager is to effectively lead the testing team. To fulfill this role the Lead
must understand the discipline of testing and how to effectively implement a testing process while
fulfilling the traditional leadership roles of a manager. What does this mean? The manager must
manage and implement or maintain an effective testing process.
Test Architect
The Role of the Test Architect is to formulate an integrated test architecture that supports the
testing process and leverages the available testing infrastructure. To fulfill this role the Test
Architect must have a clear understanding of the short-term and long-term goals of the
organization, the resources (both hard and soft) available to the organization, and a clear vision
on how to most effectively deploy these assets to form an integrated test architecture.
Test Designer or Tester
The Role of the Test Designer / Tester is to: design and document test cases, execute tests,
record test results, document defects, and perform test coverage analysis. To fulfill this role the
designer must be able to apply the most appropriate testing techniques to test the application as
efficiently as possible while meeting the test organizations testing mandate.
Test Automation Engineer
The Role of the Test Automation Engineer to is to create automated test case scripts that perform
the tests as designed by the Test Designer. To fulfill this role the Test Automation Engineer must
develop and maintain an effective test automation infrastructure using the tools and techniques
available to the testing organization. The Test Automation Engineer must work in concert with the
Test Designer to ensure the appropriate automation solution is being deployed.
Test Methodologist or Methodology Specialist
The Role of the Test Methodologist is to provide the test organization with resources on testing
methodologies. To fulfill this role the Methodologist works with Quality Assurance to facilitate
continuous quality improvement within the testing methodology and the testing organization as a
whole. To this end the methodologist: evaluates the test strategy, provides testing frameworks
and templates, and ensures effective implementation of the appropriate testing techniques.
Testing Techniques
Overtime the IT industry and the testing discipline have developed several techniques for
analyzing and testing applications.
Black-box Tests
Black-box tests are derived from an understanding of the purpose of the code; knowledge on or
about the actual internal program structure is not required when using this approach. The risk
involved with this type of approach is that .hidden. (functions unknown to the tester) will not be
tested and may not been even exercised.
White-box Tests or Glass-box tests

White-box tests are derived from an intimate understanding of the purpose of the code and the
code itself; this allows the tester to test .hidden. (undocumented functionality) within the body of
the code. The challenge with any white-box testing is to find testers that are comfortable with
reading and understanding code.
Regression tests
Regression testing is not a testing technique or test phase; it is the reuse of existing tests to test
previously implemented functionality--it is included here only for clarification.
Equivalence Partitioning
Equivalence testing leverages the concept of "classes" of input conditions. A "class" of input
could be "City Name" where testing one or several city names could be deemed equivalent to
testing all city names. In other word each instance of a class in a test covers a large set of other
possible tests.
Boundary-value Analysis
Boundary-value analysis is really a variant on Equivalence Partitioning but in this case the upper
and lower end of the class and often values outside the valid range of the class are used for input
into the test cases. For example, if the Class in "Numeric Month of the Year" then the Boundary-
values could be 0, 1, 12, and 13.
Error Guessing
Error Guessing involves making an itemized list of the errors expected to occur in a particular
area of the system and then designing a set of test cases to check for these expected errors.
Error Guessing is more testing art than testing science but can be very effective given a tester
familiar with the history of the system.
Output Forcing
Output Forcing involves making a set of test cases designed to produce a particular output from
the system. The focus here is on creating the desired output not on the input that initiated the
system response.
AUTOMATED TESTING TERMINOLOGY
Category Definition
Error The difference between a computed, observed, or measured value or condition

and the true, specified, or theoretically correct value or condition.
Fault An incorrect step, process, or data definition in a computer program.
Debug To detect, locate, and correct faults in a computer program.
Failure The inability of a system or component to perform its required functions within
specified performance requirements. It is manifested as a fault.
Testing The process of analyzing a software item to detect the differences between
existing and required conditions (that is, bugs) and to evaluate the features of the
software items.
Static analysis The process of evaluating a system or component based on its form, structure,
content, or documentation.
Dynamic analysis The process of evaluating a system or component based on its behavior during
execution.
Correctness The degree to which a system or component is free from faults in its
specification, design, and implementation.
The degree to which software, documentation, or other items meet specified
requirements.
The degree to which software, documentation, or other items meet user needs
and expectations, whether specified or not.
Verification The process of evaluating a system or component to determine whether the

products of a given development phase satisfy the conditions imposed at the start
of that phase.
Formal proof of program correctness.
Validation The process of evaluating a system or component during or at the end of the
development process to determine whether it satisfies specified requirements.
SOFTWARE TESTING DICTIONARY
Acceptance Test. Formal tests (often performed by a customer) to determine whether or not a
system has satisfied predetermined acceptance criteria. These tests are often used to enable the
customer (either internal or external) to determine whether or not to accept a system.
Accessibility testing. Testing that determines if software will be usable by people with
disabilities.
Ad Hoc Testing. Testing carried out using no recognised test case design technique. [BCS]
Algorithm verification testing. A software development and test phase focused on the
validation and tuning of key algorithms using an iterative experimentation process.[Scott
Loveland, 2005]
Alpha Testing. Testing of a software product or system conducted at the developer's site by the
customer.
Artistic testing. Also known as Exploratory testing.
Assertion Testing. (NBS) A dynamic analysis technique which inserts assertions about the
relationship between program variables into the program code. The truth of the assertions is
determined as the program executes.
Automated Testing. Software testing which is assisted with software technology that does not
require operator (tester) input, analysis, or evaluation.
Audit.
(1) An independent examination of a work product or set of work products to assess

compliance with specifications, standards, contractual agreements, or other criteria. (IEEE)
(2) To conduct an independent review and examination of system records and activities in
order to test the adequacy and effectiveness of data security and data integrity procedures, to
ensure compliance with established policy and operational procedures, and to recommend any
necessary changes. (ANSI)
ABEND Abnormal END. A mainframe term for a program crash. It is always associated with a
failure code, known as an ABEND code.[Scott Loveland, 2005]
Background testing. Is the execution of normal functional testing while the SUT is exercised by
a realistic work load. This work load is being processed "in the background" as far as the
functional testing is concerned. [ Load Testing Terminology by Scott Stirling ]
Basis path testing. Identifying tests based on flow and paths of the program or system. [William
E. Lewis, 2000]
Basis test set. A set of test cases derived from the code logic which ensure that 100\% branch
coverage is achieved. [BCS]
Bug: glitch, error, goof, slip, fault, blunder, boner, howler, oversight, botch, delusion, elision. [B.
Beizer, 1990], defect, issue, problem
Beta Testing. Testing conducted at one or more customer sites by the end-user of a delivered
software product or system.
Benchmarks Programs that provide performance comparison for software, hardware, and
systems.
Benchmarking is specific type of performance test with the purpose of determining performance
baselines for comparison. [Load Testing Terminology by Scott Stirling ]
Big-bang testing. Integration testing where no incremental testing takes place prior to all the
system's components being combined to form the system.[BCS]
Black box testing. A testing method where the application under test is viewed as a black box
and the internal behavior of the program is completely ignored. Testing occurs based upon the
external specifications. Also known as behavioral testing, since only the external behaviors of the
program are evaluated and analyzed.
Blink testing. What you do in blink testing is plunge yourself into an ocean of data-- far too much
data to comprehend. And then you comprehend it. Don't know how to do that? Yes you do. But
you may not realize that you know how.[James Bach's Blog]
Bottom-up Testing. An approach to integration testing where the lowest level components are
tested first, then used to facilitate the testing of higher level components. The process is repeated
until the component at the top of the hierarchy is tested. [BCS]
Boundary Value Analysis (BVA). BVA is different from equivalence partitioning in that it focuses
on "corner cases" or values that are usually out of range as defined by the specification. This
means that if function expects all values in range of negative 100 to positive 1000, test inputs
would include negative 101 and positive 1001. BVA attempts to derive the value often used as a
technique for stress, load or volume testing. This type of validation is usually performed after
positive functional validation has completed (successfully) using requirements specifications and
user documentation.
read tutorial Boundary Value Analysis
Branch Coverage Testing. - Verify each branch has true and false outcomes at least once.
[William E. Lewis, 2000]
Breadth test. - A test suite that exercises the full scope of a system from a top-down perspective,
but does not test any aspect in detail [Dorothy Graham, 1999]
BRS - Business Requirement Specification
Capability Maturity Model (CMM). - A description of the stages through which software
organizations evolve as they define, implement, measure, control and improve their software
processes. The model is a guide for selecting the process improvement strategies by facilitating
the determination of current process capabilities and identification of the issues most critical to
software quality and process improvement. [SEI/CMU-93-TR-25]
Capture-replay tools. - Tools that gives testers the ability to move some GUI testing away from
manual execution by ï¿½capturingï¿½ mouse clicks and keyboard strokes into scripts, and then
ï¿½replayingï¿½ that script to re-create the same sequence of inputs and responses on
subsequent test.[Scott Loveland, 2005]
Cause Effect Graphing. (1) [NBS] Test data selection technique. The input and output domains
are partitioned into classes and analysis is performed to determine which input classes cause
which effect. A minimal set of inputs is chosen which will cover the entire effect set. (2)A
systematic method of generating test cases representing combinations of conditions. See:
testing, functional.[G. Myers]
Clean test. A test whose primary purpose is validation; that is, tests designed to demonstrate the
software`s correct working.(syn. positive test)[B. Beizer 1995]
Clear-box testing. See White-box testing.

Code audit. An independent review of source code by a person, team, or tool to verify
compliance with software design documentation and programming standards. Correctness and
efficiency may also be evaluated. (IEEE)
Code Inspection. A manual [formal] testing [error detection] technique where the programmer
reads source code, statement by statement, to a group who ask questions analyzing the program
logic, analyzing the code with respect to a checklist of historically common programming errors,
and analyzing its compliance with coding standards. Contrast with code audit, code review, code
walkthrough. This technique can also be applied to other software and configuration items.
[G.Myers/NBS] Syn: Fagan Inspection
Code Walkthrough. A manual testing [error detection] technique where program [source code]
logic [structure] is traced manually [mentally] by a group with a small set of test cases, while the
state of program variables is manually monitored, to analyze the programmer's logic and
assumptions.[G.Myers/NBS]
Coexistence Testing. Coexistence isn't enough. It also depends on load order, how virtual
space is mapped at the moment, hardware and software configurations, and the history of what
took place hours or days before. Itï¿½s probably an exponentially hard problem rather than a
square-law problem. [from Quality Is Not The Goal. By Boris Beizer, Ph. D.]
Comparison testing. Comparing software strengths and weaknesses to competing products
Compatibility bug A revision to the framework breaks a previously working feature: a new
feature is inconsistent with an old feature, or a new feature breaks an unchanged application
rebuilt with the new framework code. [R. V. Binder, 1999]
Compatibility Testing. The process of determining the ability of two or more systems to
exchange information. In a situation where the developed software replaces an already working
program, an investigation should be conducted to assess possible comparability problems
between the new software and other programs or systems.
Composability testing -testing the ability of the interface to let users do more complex tasks by
combining different sequences of simpler, easy-to-learn tasks. [Timothy Dyck, 'Easy' and other
lies, eWEEK April 28, 2003]
Condition Coverage. A test coverage criteria requiring enough test cases such that each
condition in a decision takes on all possible outcomes at least once, and each point of entry to a
program or subroutine is invoked at least once. Contrast with branch coverage, decision
coverage, multiple condition coverage, path coverage, statement coverage.[G.Myers]
Configuration. The functional and/or physical characteristics of hardware/software as set forth in

technical documentation and achieved in a product. (MIL-STD-973)
Configuration control. An element of configuration management, consisting of the evaluation,

coordination, approval or disapproval, and implementation of changes to configuration items after
formal establishment of their configuration identification. (IEEE)
Conformance directed testing. Testing that seeks to establish conformance to requirements or

specification. [R. V. Binder, 1999]
Cookbook scenario. A test scenario description that provides complete, step-by-step details
about how the scenario should be performed. It leaves nothing to change. [Scott Loveland, 2005]
Coverage analysis. Determining and assessing measures associated with the invocation of
program structural elements to determine the adequacy of a test run. Coverage analysis is useful
when attempting to execute each statement, branch, path, or iterative structure in a program.
Tools that capture this data and provide reports summarizing relevant information have this
feature. (NIST)
CRUD Testing. Build CRUD matrix and test all object creation, reads, updates, and deletion.
Data-Driven testing. An automation approach in which the navigation and functionality of the test
script is directed through external data; this approach separates test and control data from the
test script. [Daniel J. Mosley, 2002]
Data flow testing. Testing in which test cases are designed based on variable usage within the
code.[BCS]
Database testing. Check the integrity of database field values. [William E. Lewis, 2000]
Defect. The difference between the functional specification (including user documentation) and
actual program text (source code and data). Often reported as problem and stored in defect-
tracking and problem-management system
Defect. Also called a fault or a bug, a defect is an incorrect part of code that is caused by an
error. An error of commission causes a defect of wrong or extra code. An error of omission results
in a defect of missing code. A defect may cause one or more failures.[Robert M. Poston, 1996.]
Defect. A flaw in the software with potential to cause a failure.. [Systematic Software Testing by
Rick D. Craig and Stefan P. Jaskiel 2002]
Defect Age. A measurement that describes the period of time from the introduction of a defect
until its discovery. . [Systematic Software Testing by Rick D. Craig and Stefan P. Jaskiel 2002]
Defect Density. A metric that compares the number of defects to a measure of size (e.g., defects
per KLOC). Often used as a measure of defect quality. [Systematic Software Testing by Rick D.
Craig and Stefan P. Jaskiel 2002]
Defect Discovery Rate. A metric describing the number of defects discovered over a specified
period of time, usually displayed in graphical form. [Systematic Software Testing by Rick D. Craig
and Stefan P. Jaskiel 2002]
Defect Removal Efficiency (DRE). A measure of the number of defects discovered in an activity
versus the number that could have been found. Often used as a measure of test effectiveness.
[Systematic Software Testing by Rick D. Craig and Stefan P. Jaskiel 2002]
Defect Seeding. The process of intentionally adding known defects to those already in a
computer program for the purpose of monitoring the rate of detection and removal, and estimating
the number of defects still remaining. Also called Error Seeding. [Systematic Software Testing by
Rick D. Craig and Stefan P. Jaskiel 2002]
Defect Masked. An existing defect that hasn't yet caused a failure because another defect has
prevented that part of the code from being executed. [Systematic Software Testing by Rick D.
Craig and Stefan P. Jaskiel 2002]
Depth test. A test case, that exercises some part of a system to a significant level of detail.
[Dorothy Graham, 1999]
Decision Coverage. A test coverage criteria requiring enough test cases such that each decision
has a true and false result at least once, and that each statement is executed at least once. Syn:
branch coverage. Contrast with condition coverage, multiple condition coverage, path coverage,
statement coverage.[G.Myers]
Design-based testing. Designing tests based on objectives derived from the architectural or
detail design of the software (e.g., tests that execute specific invocation paths or probe the worst
case behaviour of algorithms). [BCS
Dirty testing Negative testing. [Beizer]
Dynamic testing. Testing, based on specific test cases, by execution of the test object or running
programs [Tim Koomen, 1999]
End-to-End testing. Similar to system testing; the 'macro' end of the test scale; involves testing
of a complete application environment in a situation that mimics real-world use, such as
interacting with a database, using network communications, or interacting with other hardware,
applications, or systems if appropriate.
Equivalence Partitioning: An approach where classes of inputs are categorized for product or
function validation. This usually does not include combinations of input, but rather a single state
value based by class. For example, with a given function there may be several classes of input
that may be used for positive testing. If function expects an integer and receives an integer as
input, this would be considered as positive test assertion. On the other hand, if a character or any
other input class other than integer is provided, this would be considered a negative test assertion
or condition.
Error: An error is a mistake of commission or omission that a person makes. An error causes a
defect. In software development one error may cause one or more defects in requirements,
designs, programs, or tests.[Robert M. Poston, 1996.]
Errors: The amount by which a result is incorrect. Mistakes are usually a result of a human
action. Human mistakes (errors) often result in faults contained in the source code, specification,
documentation, or other product deliverable. Once a fault is encountered, the end result will be a
program failure. The failure usually has some margin of error, either high, medium, or low.
Error Guessing: Another common approach to black-box validation. Black-box testing is when
everything else other than the source code may be used for testing. This is the most common
approach to testing. Error guessing is when random inputs or conditions are used for testing.
Random in this case includes a value either produced by a computerized random number
generator, or an ad hoc value or test conditions provided by engineer.
Error guessing. A test case design technique where the experience of the tester is used to
postulate what faults exist, and to design tests specially to expose them [from BS7925-1]
Error seeding. The purposeful introduction of faults into a program to test effectiveness of a test
suite or other quality assurance program. [R. V. Binder, 1999]
Exception Testing. Identify error messages and exception handling processes an conditions that
trigger them. [William E. Lewis, 2000]
Exhaustive Testing.(NBS) Executing the program with all possible combinations of values for
program variables. Feasible only for small, simple programs.
Exploratory Testing: An interactive process of concurrent product exploration, test design, and
test execution. The heart of exploratory testing can be stated simply: The outcome of this test
influences the design of the next test. [James Bach]
Failure: A failure is a deviation from expectations exhibited by software and observed as a set of
symptoms by a tester or user. A failure is caused by one or more defects. The Causal Trail. A
person makes an error that causes a defect that causes a failure.[Robert M. Poston, 1996]
Fix testing. Rerunning of a test that previously found the bug in order to see if a supplied fix
works. [Scott Loveland, 2005]
Follow-up testing, we vary a test that yielded a less-thanspectacular failure. We vary the
operation, data, or environment, asking whether the underlying fault in the code can yield a more
serious failure or a failure under a broader range of circumstances.[Measuring the Effectiveness
of Software Testers,Cem Kaner, STAR East 2003]
Formal Testing. (IEEE) Testing conducted in accordance with test plans and procedures that
have been reviewed and approved by a customer, user, or designated level of management.
Antonym: informal testing.
Framework scenario. A test scenario definition that provides only enough high-level information
to remind the tester of everything that needs to be covered for that scenario. The description
captures the activityâ€™s essence, but trusts the tester to work through the specific steps
required.[Scott Loveland, 2005]
Free Form Testing. Ad hoc or brainstorming using intuition to define test cases. [William E.
Lewis, 2000]
Functional Decomposition Approach. An automation method in which the test cases are
reduced to fundamental tasks, navigation, functional tests, data verification, and return
navigation; also known as Framework Driven Approach. [Daniel J. Mosley, 2002]
Functional testing Application of test data derived from the specified functional requirements
without regard to the final program structure. Also known as black-box testing.
Function verification test (FVT). Testing of a complete, yet containable functional area or
component within the overall software package. Normally occurs immediately after Unit test. Also
known as Integration test. [Scott Loveland, 2005]
Gray box testing. Tests involving inputs and outputs, but test design is educated by information
about the code or the program operation of a kind that would normally be out of scope of view of
the tester.[Cem Kaner]
Gray box testing. Test designed based on the knowledge of algorithm, internal states,
architectures, or other high -level descriptions of the program behavior. [Doug Hoffman]
Gray box testing. Examines the activity of back-end components during test case execution.
Two types of problems that can be encountered during gray-box testing are:
A component encounters a failure of some kind, causing the operation to be aborted. The user
interface will typically indicate that an error has occurred.
The test executes in full, but the content of the results is incorrect. Somewhere in the system,
a component processed data incorrectly, causing the error in the results.
[Elfriede Dustin. "Quality Web Systems: Performance, Security & Usability."]
Grooved Tests. Tests that simply repeat the same activity against a target product from cycle to
cycle. [Scott Loveland, 2005]
High-level tests. These tests involve testing whole, complete products [Kit, 1995]
Incremental integration testing. Incremental integration testing - continuous testing of an

application as new functionality is added; requires that various aspects of an application's
functionality be independent enough to work separately before all parts of the program are
completed, or that test drivers be developed as needed; done by programmers or by testers.
Inspection. A formal evaluation technique in which software requirements, design, or code are
examined in detail by person or group other than the author to detect faults, violations of
development standards, and other problems [IEEE94]. A quality improvement process for written
material that consists of two dominant components: product (document) improvement and
process improvement (document production and inspection).
Integration. The process of combining software components or hardware components or both

into overall system.
Integration testing - testing of combined parts of an application to determine if they function

together correctly. The 'parts' can be code modules, individual applications, client and server
applications on a network, etc. This type of testing is especially relevant to client/server and
distributed systems.
Integration Testing. Testing conducted after unit and feature testing. The intent is to expose
faults in the interactions between software modules and functions. Either top-down or bottom-up
approaches can be used. A bottom-up method is preferred, since it leads to earlier unit testing
(step-level integration) This method is contrary to the big-bang approach where all source
modules are combined and tested in one step. The big-bang approach to integration should be
discouraged.
Interface Tests. Programs that probide test facilities for external interfaces and function calls.
Simulation is often used to test external interfaces that currently may not be available for testing
or are difficult to control. For example, hardware resources such as hard disks and memory may
be difficult to control. Therefore, simulation can provide the characteristics or behaviors for
specific function.
Internationalization testing (I18N) - testing related to handling foreign text and data within the
program. This would include sorting, importing and exporting test and data, correct handling of
currency and date and time formats, string parsing, upper and lower case handling and so forth.
[Clinton De Young, 2003].
Interoperability Testing which measures the ability of your software to communicate across the
network on multiple machines from multiple vendors each of whom may have interpreted a
design specification critical to your success differently.
Inter-operability Testing. True inter-operability testing concerns testing for unforeseen

interactions with other packages with which your software has no direct connection. In some
quarters, inter-operability testing labor equals all other testing combined. This is the kind of
testing that I say shouldnÂ’t be done because it canï¿½t be done.[from Quality Is Not The Goal.
By Boris Beizer, Ph. D.]
Inspection. A formal evaluation technique in which software requirements, design, or code are
examined in detail by person or group other than the author to detect faults, violations of
development standards, and other problems [IEEE94].
Install/uninstall testing. Testing of full, partial, or upgrade install/uninstall processes.
Latent bug A bug that has been dormant (unobserved) in two or more releases. [R. V. Binder,
1999]
Lateral testing. A test design technique based on lateral thinking principals, to identify faults.
[Dorothy Graham, 1999]
Limits testing. See Boundary Condition testing.
Load testing. Testing an application under heavy loads, such as testing of a web site under a
range of loads to determine at what point the system's response time degrades or fails.
Load Â§Ò¡Ì³tress test. A test is design to determine how heavy a load the application can
handle.
Load-stability test. Test design to determine whether a Web application will remain serviceable
over extended time span.
Load Â§Ò¡Ì©solation test. The workload for this type of test is designed to contain only the
subset of test cases that caused the problem in previous testing.
Longevity testing. See Reliability testing.
Long-haul Testing. See Reliability testing.
Master Test Planning. An activity undertaken to orchestrate the testing effort across levels and
organizations.[Systematic Software Testing by Rick D. Craig and Stefan P. Jaskiel 2002]
Monkey Testing. (smart monkey testing) Input are generated from probability distributions that
reflect actual expected usage statistics -- e.g., from user profiles. There are different levels of IQ
in smart monkey testing. In the simplest, each input is considered independent of the other
inputs. That is, a given test requires an input vector with five components. In low IQ testing, these
would be generated independently. In high IQ monkey testing, the correlation (e.g., the
covariance) between these input distribution is taken into account. In all branches of smart
monkey testing, the input is considered as a single event.[Visual Test 6 Bible by Thomas R.
Arnold, 1998 ]
Monkey Testing. (brilliant monkey testing) The inputs are created from a stochastic regular
expression or stochastic finite-state machine model of user behavior. That is, not only are the
values determined by probability distributions, but the sequence of values and the sequence of
states in which the input provider goes is driven by specified probabilities.[Visual Test 6 Bible by
Thomas R. Arnold, 1998 ]
Monkey Testing. (dumb-monkey testing)Inputs are generated from a uniform probability

distribution without regard to the actual usage statistics.[Visual Test 6 Bible by Thomas R. Arnold,
1998 ]
Maximum Simultaneous Connection testing. This is a test performed to determine the number
of connections which the firewall or Web server is capable of handling.
Migration Testing. Testing to see if the customer will be able to transition smoothly from a prior
version of the software to a new one. [Scott Loveland, 2005]
Mutation testing. A testing strategy where small variations to a program are inserted (a mutant),
followed by execution of an existing test suite. If the test suite detects the mutant, the mutant is
'retired.' If undetected, the test suite must be revised. [R. V. Binder, 1999]
Multiple Condition Coverage. A test coverage criteria which requires enough test cases such
that all possible combinations of condition outcomes in each decision, and all points of entry, are
invoked at least once.[G.Myers] Contrast with branch coverage, condition coverage, decision
coverage, path coverage, statement coverage.
Negative test. A test whose primary purpose is falsification; that is tests designed to break the
software[B.Beizer1995]
Noncritical code analysis. Examines software elements that are not designated safety-critical
and ensures that these elements do not cause a hazard. (IEEE)
Orthogonal array testing: Technique can be used to reduce the number of combination and
provide maximum coverage with a minimum number of TC.Pay attention to the fact that it is an
old and proven technique. The OAT was introduced for the first time by Plackett and Burman in
1946 and was implemented by G. Taguchi, 1987
Orthogonal array testing: Mathematical technique to determine which variations of parameters

need to be tested. [William E. Lewis, 2000]
Oracle. Test Oracle: a mechanism to produce the predicted outcomes to compare with the actual
outcomes of the software under test [from BS7925-1]
Parallel Testing. Testing a new or an alternate data processing system with the same source
data that is used in another system. The other system is considered as the standard of
comparison. Syn: parallel run.[ISO]
Penetration testing. The process of attacking a host from outside to ascertain remote security
vulnerabilities.
Performance Testing. Testing conducted to evaluate the compliance of a system or component

with specific performance requirements [BS7925-1]
Performance testing can be undertaken to: 1) show that the system meets specified
performance objectives, 2) tune the system, 3) determine the factors in hardware or software that
limit the system's performance, and 4) project the system's future load- handling capacity in order
to schedule its replacements" [Software System Testing and Quality Assurance. Beizer, 1984, p.
256]
Postmortem. Self-analysis of interim or fully completed testing activities with the goal of creating
improvements to be used in future.[Scott Loveland, 2005]
Preventive Testing Building test cases based upon the requirements specification prior to the
creation of the code, with the express purpose of validating the requirements [Systematic
Software Testing by Rick D. Craig and Stefan P. Jaskiel 2002]
Prior Defect History Testing. Test cases are created or rerun for every defect found in prior
tests of the system. [William E. Lewis, 2000]
Qualification Testing. (IEEE) Formal testing, usually conducted by the developer for the
consumer, to demonstrate that the software meets its specified requirements. See: acceptance
testing.
Quality. The degree to which a program possesses a desired combination of attributes that
enable it to perform its specified end use.
Quality Assurance (QA) Consists of planning, coordinating and other strategic activities
associated with measuring product quality against external requirements and specifications
(process-related activities).
Quality Control (QC) Consists of monitoring, controlling and other tactical activities associated
with the measurement of product quality goals.
Our definition of Quality: Achieving the target (not conformance to requirements as used by
many authors) & minimizing the variability of the system under test
Race condition defect. Many concurrent defects result from data-race conditions. A data-race
condition may be defined as two accesses to a shared variable, at least one of which is a write,
with no mechanism used by either to prevent simultaneous access. However, not all race
conditions are defects.
Recovery testing Testing how well a system recovers from crashes, hardware failures, or other
catastrophic problems.
Regression Testing. Testing conducted for the purpose of evaluating whether or not a change to
the system (all CM items) has introduced a new failure. Regression testing is often accomplished
through the construction, execution and analysis of product and system tests.
Regression Testing. - testing that is performed after making a functional improvement or repair
to the program. Its purpose is to determine if the change has regressed other aspects of the
program [Glenford J.Myers, 1979]
Reengineering. The process of examining and altering an existing system to reconstitute it in a

new form. May include reverse engineering (analyzing a system and producing a representation
at a higher level of abstraction, such as design from code), restructuring (transforming a system
from one representation to another at the same level of abstraction), recommendation (analyzing
a system and producing user and support documentation), forward engineering (using software
products derived from an existing system, together with new requirements, to produce a new
system), and translation (transforming source code from one language to another or from one
version of a language to another).
Reference testing. A way of deriving expected outcomes by manually validating a set of actual
outcomes. A less rigorous alternative to predicting expected outcomes in advance of test
execution. [Dorothy Graham, 1999]
Reliability testing. Verify the probability of failure free operation of a computer program in a
specified environment for a specified time.
Reliability of an object is defined as the probability that it will not fail under specified conditions,
over a period of time. The specified conditions are usually taken to be fixed, while the time is
taken as an independent variable. Thus reliability is often written R(t) as a function of time t, the
probability that the object will not fail within time t.
Any computer user would probably agree that most software is flawed, and the evidence for this
is that it does fail. All software flaws are designed in -- the software does not break, rather it was
always broken. But unless conditions are right to excite the flaw, it will go unnoticed -- the
software will appear to work properly. [Professor Dick Hamlet. Ph.D.]
Range Testing. For each input identifies the range over which the system behavior should be the
same. [William E. Lewis, 2000]
Risk management. An organized process to identify what can go wrong, to quantify and access
associated risks, and to implement/control the appropriate approach for preventing or handling
each risk identified.
Robust test. A test, that compares a small amount of information, so that unexpected side
effects are less likely to affect whether the test passed or fails. [Dorothy Graham, 1999]
Sanity Testing - typically an initial testing effort to determine if a new software version is
performing well enough to accept it for a major testing effort. For example, if the new software is
often crashing systems, bogging down systems to a crawl, or destroying databases, the software
may not be in a 'sane' enough condition to warrant further testing in its current state.
Scalability testing is a subtype of performance test where performance requirements for

response time, throughput, and/or utilization are tested as load on the SUT is increased over
time. [Load Testing Terminology by Scott Stirling ]
Sensitive test. A test, that compares a large amount of information, so that it is more likely to
defect unexpected differences between the actual and expected outcomes of the test. [Dorothy
Graham, 1999]
Service test. Test software fixes, both individually and bundled together, for software that is
already in use by customers. [Scott Loveland, 2005]
Skim Testing A testing technique used to determine the fitness of a new build or release of an
AUT to undergo further, more thorough testing. In essence, a "pretest" activity that could form
one of the acceptance criteria for receiving the AUT for testing [Testing IT: An Off-the-Shelf
Software Testing Process by John Watkins]
Smoke test describes an initial set of tests that determine if a new version of application
performs well enough for further testing.[Louise Tamres, 2002]
Sniff test. A quick check to see if any major abnormalities are evident in the software.[Scott
Loveland, 2005 ]
Specification-based test. A test, whose inputs are derived from a specification.
Spike testing. to test performance or recovery behavior when the system under test (SUT) is
stressed with a sudden and sharp increase in load should be considered a type of load test.[
Load Testing Terminology by Scott Stirling ]
SRS. Business Requirement Specification.
STEP (Systematic Test and Evaluation Process) Software Quality Engineering's copyrighted
testing methodology.
State-based testing Testing with test cases developed by modeling the system under test as a
state machine [R. V. Binder, 1999]
State Transition Testing. Technique in which the states of a system are fist identified and then
test cases are written to test the triggers to cause a transition from one condition to another state.
Static testing. Source code analysis. Analysis of source code to expose potential defects.
Statistical testing. A test case design technique in which a model is used of the statistical
distribution of the input to construct representative test cases. [BCS]
Stealth bug. A bug that removes information useful for its diagnosis and correction. [R. V. Binder,
1999]
Storage test. Study how memory and space is used by the program, either in resident memory
or on disk. If there are limits of these amounts, storage tests attempt to prove that the program
will exceed them. [Cem Kaner, 1999, p55]
Streamable Test cases. Test cases which are able to run together as part of a large group.
[Scott Loveland, 2005]
Stress / Load / Volume test. Tests that provide a high degree of activity, either using boundary
conditions as inputs or multiple copies of a program executing in parallel as examples.
Structural Testing. (1)(IEEE) Testing that takes into account the internal mechanism [structure]
of a system or component. Types include branch testing, path testing, statement testing. (2)
Testing to insure each program statement is made to execute during testing and that each
program statement performs its intended function. Contrast with functional testing. Syn: white-box
testing, glass-box testing, logic driven testing.
System testing Black-box type testing that is based on overall requirements specifications;
covers all combined parts of a system.
System verification test. (SVT). Testing of an entire software package for the first time, with all
components working together to deliver the project's intended purpose on supported hardware
platforms. [Scott Loveland, 2005]
Table testing. Test access, security, and data integrity of table entries. [William E. Lewis, 2000]
Test Bed. An environment containing the hardware, instrumentation, simulators, software tools,
and other support elements needed to conduct a test [IEEE 610].
Test Case. A set of test inputs, executions, and expected results developed for a particular
objective.
Test conditions. The set of circumstances that a test invokes. [Daniel J. Mosley, 2002]
Test Coverage The degree to which a given test or set of tests addresses all specified test cases
for a given system or component.
Test Criteria. Decision rules used to determine whether software item or software feature passes
or fails a test.
Test data. The actual (set of) values used in the test or that are necessary to execute the test.
[Daniel J. Mosley, 2002]
Test Documentation. (IEEE) Documentation describing plans for, or results of, the testing of a
system or component, Types include test case specification, test incident report, test log, test
plan, test procedure, test report.
Test Driver A software module or application used to invoke a test item and, often, provide test
inputs (data), control and monitor execution. A test driver automates the execution of test
procedures.
Test Harness A system of test drivers and other tools to support test execution (e.g., stubs,
executable test cases, and test drivers). See: test driver.
Test Item. A software item which is the object of testing.[IEEE]
Test Log A chronological record of all relevant details about the execution of a test.[IEEE]
Test Plan. A high-level document that defines a testing project so that it can be properly
measured and controlled. It defines the test strategy and organized elements of the test life cycle,
including resource requirements, project schedule, and test requirements
Test Procedure. A document, providing detailed instructions for the [manual] execution of one or
more test cases. [BS7925-1] Often called - a manual test script.
Test Rig A flexible combination of hardware, software, data, and interconnectivity that can be
configured by the Test Team to simulate a variety of different Live Environments on which an
AUT can be delivered.[Testing IT: An Off-the-Shelf Software Testing Process by John Watkins ]
Test strategy. Describes the general approach and objectives of the test activities. [Daniel J.
Mosley, 2002]
Test Status. The assessment of the result of running tests on software.
Test Stub A dummy software component or object used (during development and testing) to
simulate the behaviour of a real component. The stub typically provides test output.
Test Suites A test suite consists of multiple test cases (procedures and data) that are combined
and often managed by a test harness.
Test Tree. A physical implementation of Test Suite. [Dorothy Graham, 1999]

Testability. Attributes of software that bear on the effort needed for validating the modified
software [ISO 8402]
Testability Hooks. Those functions, integrated in the software that can be invoked through
primarily undocumented interfaces to drive specific processing which would otherwise be difficult
to exercise. [Scott Loveland, 2005]
Testing. The execution of tests with the intent of providing that the system and application under
test does or does not perform according to the requirements specification.
(TPI) Test Process Improvement. A method for baselining testing processes and identifying
process improvement opportunities, using a static model developed by Martin Pol and Tim
Koomen.
Thread Testing. A testing technique used to test the business functionality or business logic of
the AUT in an end-to-end manner, in much the same way a User or an operator might interact
with the system during its normal use.[Testing IT: An Off-the-Shelf Software Testing Process by
John Watkins ]
Timing and Serialization Problems. A class of software defect, usually in multithreaded code, in
which two or more tasks attempt to alter a shared software resource without properly coordinating
their actions. Also known as Race Conditions.[Scott Loveland, 2005]
Translation testing. See internationalization testing.
Thrasher. A type of program used to test for data integrity errors on mainframe system. The
name is derived from the first such program, which deliberately generated memory thrashing (the
overuse of large amount of memory, leading to heavy paging or swapping) while monitoring for
corruption. [Scott Loveland, 2005]
Unit Testing. Testing performed to isolate and expose faults and failures as soon as the source
code is available, regardless of the external interfaces that may be required. Oftentimes, the
detailed design and requirements documents are used as a basis to compare how and what the
unit is able to perform. White and black-box testing methods are combined during unit testing.
Usability testing. Testing for 'user-friendliness'. Clearly this is subjective, and will depend on the
targeted end-user or customer.
Validation. The comparison between the actual characteristics of something (e.g. a product of a
software project and the expected characteristics).Validation is checking that you have built the
right system.
Verification The comparison between the actual characteristics of something (e.g. a product of a
software project) and the specified characteristics.Verification is checking that we have built the
system right.
Volume testing. Testing where the system is subjected to large volumes of data.[BS7925-1]
GUI TESTING
1 Introduction
1.1 GUIs as universal client
GUIs have become the established alternative to traditional forms-based user interfaces. GUIs
are the assumed user interface for virtually all systems development using modern technologies.
There are several reasons why GUIs have become so popular:
• GUIs provide the standard look and feel of a client operating system.
• GUIs are so flexible that they can be used in most application areas.
• The GUI provides seamless integration of custom and package applications.
• The user has a choice of using the keyboard or a mouse device.
• The user has a more natural interface to applications: multiple windows can be visible
simultaneously, so user understanding is improved.
• The user is in control: screens can be accessed in the sequence the user wants at will.
1.2 GUIs v forms
Lets look at the differences between GUIs and forms based interfaces.
Forms Based Applications
In forms-based applications, the forms are arranged in a hierarchical order. Most often, a top-
level menu is displayed which offers a selection of options and when one option is chosen, the
selected screen is displayed. Often, one menu calls another lower level menu to provide a further
level of selection. In large applications or packages, there might be three levels of menus to be
navigated, before the required functionality is presented to the user. A two level menu system
containing fifteen options per menu can provide rapid access to over two hundred screens.
With forms displayed on a screen, we can only display and therefore interact with one form at a
time. Usually, when a new form is displayed, it fills the screen and functionality on the old form is
now unavailable. The one-at-a-time mode is the main characteristic of forms-based systems. In
some applications navigation is achieved form-to form, by providing command-driven interfaces.
In this way, the user avoids having to navigate using the menu system.
Typically, expert users use such command-driven methods, while occasional users adopt the
menu-driven approach. In a sophisticated application, expert users may navigate to virtually any
system feature from any other, as long as they know what commands are available, wherever
they are. Occasional users are left with the problem of always having to navigate through menus.
In large, complex systems, this can be a major headache.
In application forms, the fields on the form have a predefined and unchangeable ‘tabbing order’.
That is, the user may only access the fields in a certain order, regardless of whether any data has
been entered into the form fields. Navigation is normally achieved through use of the tab key to
move forwards and the backspace key to go backwards.
GUIs
The most obvious characteristic of GUI applications is the fact that the GUI allows multiple
windows to be displayed at the same time. Displayed windows are ‘owned’ by applications and of
course, there may be more than one application active at the same time.
Access to features of the systems is provided via three mechanisms. Menu bars provide almost
continuous availability of the various features of the systems; buttons and keyboard shortcuts
enable the user to navigate and access the various functions of their application.
Windows provide forms-like functionality with fields in which text or numeric data can be entered.
But GUIs introduce additional objects such as radio buttons, scrolling lists, check boxes and other
graphics that may be displayed or directly manipulated.
The GUI itself manages the simultaneous presentation of multiple applications and windows.
Hidden windows in the same or different applications may be brought forward and used. There
are few, if any, constraints on the order in which users access GUI windows so users are free to
use the features of the system in the way they prefer, rather than the way the developers
architected it.
Fields within windows have a tabbing order, but the user is free to use the mouse to change the
focus of the application to any field on screen. There are no constraints on the order in which a
user may enter data on a screen. To the user, there are advantages in being able to access fields
directly (perhaps to avoid tabbing through many fields that will not change).
In short, GUIs free the user to access system functionality in their preferred way. They have
permanent access to all features and may use the mouse, the keyboard or a combination of both
to have a more natural dialogue with the system.
1.3 Some testing difficulties
GUIs have brought considerable benefits to developers. They release the developer from the
concerns of interface design – in most environments, GUI design standards impose conventions
which make one application look very much like another on the same platform.
However, the sophistication and simplicity of a GUI hides the complexity from the user and where
development frameworks are used, the programmers too. When testers are presented with a GUI
application to test, the hidden complexities become all too obvious. Consequently, testing GUIs is
made considerably more difficult. What are the reasons for this?
Event-driven software
The event-driven nature of GUIs presents the first serious testing difficulty. Because users many
click on any pixel on the screen, there are many, many more possible user inputs that can occur.
The user has an extremely wide choice of actions. At any point in the application, the users may
click on any field or object within a window. They may bring another window in the same
application to the front and access that. The window may be owned by another application. The
user may choose to access an operating system component directly e.g. a system configuration
control panel.
The large number of available options mean that the application code must at all times deal with
the next event, whatever it may be. In the more advanced development environments, where
sophisticated frameworks are being used, many of these events are handled ‘behind the scenes’.
With less advanced toolkits, the programmer must write code to handle these events explicitly.
Many errors occur because the programmer cannot anticipate every context in which their event
handlers are invoked.
Many events such as button clicks cause the focus of the application to move from one feature to
another completely unrelated feature. Not only does the selected feature have to deal with a
potentially unknown context, the previous feature may be ‘left hanging’ in a partially completed
state. The number of potential paths from feature to feature within the application is so high that
the scope for programmers to make errors is dramatically increased. The ‘infinite paths’ problem
also makes it extremely unlikely that they will all be tested.
Unsolicited events
Unsolicited events cause problems for programmers and testers. A trivial example would be when
a local printer goes off-line, and the operating system puts up a dialog box inviting the user to
feed more paper into the printer. A more complicated situation arises where message-oriented
middleware might dispatch a message (an event) to remind the client application to redraw a
diagram on screen, or refresh a display of records from a database that has changed.
Unsolicited events may occur at any time, so again, the number of different situations that the
code must accommodate is extremely high. Testing of unsolicited events is difficult because of
the number of test cases may be high but also special test drivers may be necessary to generate
such events within the operating systems.
Object oriented
GUIs map very well to the object-oriented paradigm. The desktop, windows and other graphical
elements are usually organised into a hierarchy of objects that deal with GUI events. Every object
has its own methods (event handlers) and attributes. Typical attributes define the object’s state
and usually include:
• Is the object active or inactive (reacts to mouse clicks to take the focus)?
• Appearance e.g. font type, font size, position on screen, dimensions, visible/invisible,
colour.
• Contents e.g. text, on/off, true/false, number and values of entries in a list box.
The number of attributes of objects on screen is large. Even for simple text boxes there may be
thirty or more attributes. For the majority of objects, these attributes are static: the appearance
attributes are defined once and do not change. However, screen objects that contain data
entered by the user must accommodate their changing contents but may also have their own
event handlers which may perform validation tasks.
Hidden synchronisation and dependencies
It is common for window objects to have some form of synchronisation implemented. For
example, if a check box is set to true, a text box intended to accept a numeric value elsewhere in
the window may be made inactive or invisible. If a particular radio button is clicked, a different
validation rule might be used for a data field elsewhere on the window.
Synchronisation between objects need not be restricted to objects in the same window. For
example, a visible window may present customer details including say, ‘date of last order’.
Another open window might be used to log customer orders, so if the user creates and confirms
an order for the same customer, should the ‘date of last order’ field on the first window be
updated? Most users would suggest it should be so the programmer must use the event handling
mechanisms to implement the synchronisation functionality. The problem for the tester is ‘where
are these dependencies?’
‘Infinite’ input domain
On any GUI application, the user has complete freedom to click with the mouse-pointing device
anywhere on the window that has the focus. Although objects in windows have a default tab
order, the user may choose to enter data values by clicking on an object and then entering data.
In principle, there may be 5,040 different sequences of entering data into seven data fields (this is
seven factorial or 7x6x5x4x3x2x1). For more complex screens the numbers grow dramatically.
Do we care as testers, through?
Consider the synchronisation situation above (the selected check box and greyed out numeric
field). If the user forgets to check the check box, but then proceeds to enter a value in the
numeric field, what should happen if the user then remembers to click on the check box? Should
the numeric field be cleared? If not, is the data in numeric field written to the database?
Many ways in, many ways out
An obvious consequence of the event-driven nature of GUIs is that for most situations in the
application, there may be ‘many ways in’ by which the user reached that point in the application.
How many ways in are there? Should they all be tested? In the majority of situations in GUI
applications, there may be ‘many ways out’ also - the user may use a keyboard shortcut, a button
click, a menu option, click on another window etc. How many of these should be tested?
For most options within GUI applications, there are three ways of selecting options or
implementing functionality: these are keyboard shortcuts, function keys, and mouse movements
(buttons or menus). Given that these three mechanisms are available for many options for most
of the time, does this mean we must test these features three times over?
Window management
In a GUI environment, users take the standard features of window management and control for
granted. These features include window movement, resizing, maximisation, minimisation and
closure. These are usually implemented by standard buttons and keyboard commands available
on every window. The programmer has control over which standard window controls are
available, but although the operating system handles the window’s behaviour, the programmer
must handle the impact on the application.
In some circumstances, closing a window before completing a transaction may leave the
application or the database in an inconsistent state. The programmer might avoid such
complications by disabling all of the standard window buttons and commands. But he might also
have made it impossible for the user to reverse or undo certain actions. From the tester’s point of
view, which standard window controls need to be tested? Where is the dividing line between
testing the application and testing the operating system? Do we need to test navigation paths
both forwards and backwards?
2 GUI Test Strategy
2.1 Test Principles Applied to GUIs

Our proposed approach to testing GUIs is guided by several principles, most of which should be
familiar. By following these principles we will develop a test process which is generally applicable
for testing any GUI application. Note that the proposed test approach does not cover white-box
testing of application code in any depth. This approach concentrates on GUI errors and using the
GUI to exercise tests so is very-oriented toward black-box testing.
Focus on errors to reduce the scope of tests
We intend to categorise errors into types and design test to detect each type of error in turn. In
this way, we can focus the testing and eliminate duplication.
Separation of concerns (divide and conquer)
By focusing on particular types of error and designing test cases to detect those errors, we can
break up the complex problem into a number of simpler ones.
Test design techniques where appropriate
Traditional black box test techniques that we would use to test forms based applications are still
appropriate.
Layered and staged tests
We will organise the test types into a series of test stages. The principle here is that we bring
tests of the lowest level of detail in components up front. We implement integration tests of
components and test the integrated application last. In this way, we can build the testing up in
trusted layers.
Test automation...wherever possible
Automation most often fails because of over-ambition. By splitting the test process into stages,
we can seek and find opportunities to make use of automation where appropriate, rather than
trying to use automation everywhere.
2.2 High Level Test Process
An outline test process is presented in Figure 1 - The high-level test process. We can split the
process into three overall phases: Test Design, Test Preparation and Test Execution. In this
paper, we are going to concentrate on the first stage: Test Design, and then look for opportunities
for making effective use of automated tools to execute tests.
Figure 1 - The high-level test process
2.3 Types of GUI errors
We can list some of the multifarious errors that can occur in a client/server-based application that
we might reasonably expect to be able to test for using the GUI. The list in Table 1 is certainly not
complete, but it does demonstrate the wide variety error types. Many of these errors relate to the
GUI, others relate to the underlying functionality or interfaces between the GUI application and
other client/server components.
• Correct window modality?

• Data validation
• Window system commands not
• Incorrect field defaults
available/don’t work
• Mis-handling of server process
• Control state alignment with state of
failures
data in window?
• Mandatory fields, not mandatory
• Focus on objects needing it?
• Wrong fields retrieved by queries
• Menu options align with state of data
• Incorrect search criteria
or application mode?
• Field order
• Action of menu commands aligns
• Multiple database rows returned,
with state of data in window
single row expected
• Synchronisation of window object
• Currency of data on screens
content
• Window object/DB field
• State of controls aligns with state of
correspondence
data in window?
Table 1 - The variety of errors found in GUI applications
By targeting different categories of errors in this list, we can derive a set of different test types that
focus on a single error category of errors each and provide coverage across all error types.
2.4 Four Stages of GUI Testing
This paper proposes a GUI test design process that fits into an overall test process. Test design
becomes a series of straightforward activities, each focusing on different types of error. The
question now is, ‘how does this fit into existing test processes?’ To help readers map GUI test
types to a more traditional test process, we have grouped the test types in four stages.
The four stages are summarised in Table 2 below. We can map the four test stages to traditional
test stages as follows:
• Low level - maps to a unit test stage.

• Application - maps to either a unit test or functional system test stage.
• Integration - maps to a functional system test stage.
• Non-functional - maps to non-functional system test stage.
The mappings described above are approximate. Clearly there are occasions when some ‘GUI
integration testing’ can be performed as part of a unit test. The test types in ‘GUI application
testing’ are equally suitable in unit or system testing. In applying the proposed GUI test types, the
objective of each test stage, the capabilities of developers and testers, the availability of test
environment and tools all need to be taken into consideration before deciding whether and where
each GUI test type is implemented in your test process.
The GUI test types alone do not constitute a complete set of tests to be applied to a system. We
have not included any code-based or structural testing, nor have we considered the need to
conduct other integration tests or non-functional tests of performance, reliability and so on. Your
test strategy should address all these issues.
Stage Test Types

Low Level • Checklist testing
• Navigation
Application • Equivalence Partitioning

• Boundary Values
• Decision Tables
• State Transition Testing
Integration • Desktop Integration

• C/S Communications
• Synchronisation
Non-Functional • Soak testing

• Compatibility testing
• Platform/environment
Table 2 - Proposed GUI test stages
The test types identified in the table above are described below.
3 Types of GUI Test
3.1 Checklist Testing
Checklists are a straightforward way of documenting simple re-usable tests. Not enough use is
made of checklist driven testing, perhaps because it is perceived to be trivial, but it is their
simplicity that makes them so effective and easy to implement. They are best used to document
simple checks that can be made on low-level components. Ideally, these checks can be made
visually, or by executing very simple or easily remembered series of commands. The types of
checks that are best documented in this way are:
• Programming/GUI standards covering standard features such as:

• window size, positioning, type (modal/non-modal)
• standard system commands/buttons (close, minimise, maximise etc.)
• Application standards or conventions such as:
• standard OK, cancel, continue buttons, appearance, colour, size, location
• consistent use of buttons or controls
• object/field labelling to use standard/consistent text.
These checks should be both simple to document and execute and can be used for standalone
components so that programmers may make these checks before they release the code for
integration.
3.2 Navigation Testing
In the context of a GUI, we can view navigation tests as a form of integration testing. Typically,
programmers create and test new windows in isolation. Integration of a new window into an
application requires that the application menu definition and invocations of the window from other
windows be correctly implemented. The build strategy determines what navigation testing can be
done and how. To conduct meaningful navigation tests the following are required to be in place:
• An application backbone with at least the required menu options and call mechanisms to
call the window under test.
• Windows that can invoke the window under test.
• Windows that are called by the window under test.
Obviously, if any of the above components are not available, stubs and/or drivers will be
necessary to implement navigation tests. If we assume all required components are available,
what tests should we implement? We can split the task into steps:
• For every window, identify all the legitimate calls to the window that the application
should allow and create test cases for each call.
• Identify all the legitimate calls from the window to other features that the application
should allow and create test cases for each call.
• Identify reversible calls, i.e. where closing a called window should return to the ‘calling’
window and create a test case for each.
• Identify irreversible calls i.e. where the calling window closes before the called window
appears.
There may be multiple ways of executing a call to another window i.e. menus, buttons, keyboard
commands. In this circumstance, consider creating one test case for each valid path by each
available means of navigation.
Note that navigation tests reflect only a part of the full integration testing that should be
undertaken. These tests constitute the ‘visible’ integration testing of the GUI components that a
‘black box’ tester should undertake.
3.3 Application Testing
Application testing is the testing that would normally be undertaken on a forms-based application.
This testing focuses very much on the behaviour of the objects within windows. The approach to
testing a window is virtually the same as would be adopted when testing a single form. The
traditional black-box test design techniques are directly applicable in this context.
Given the extensive descriptions already available (BEIZER, KANER, MYERS) no explanation of
these techniques is provided here. However, a very brief summary of the most common
techniques and some guidelines for their use with GUI windows are presented in the table below:
Technique Used to test

Equivalence Partitions and • Input validation
Boundary Value Analysis • Simple rule-based processing
Decision Tables • Complex logic or rule-based processing
State-transition testing • Applications with modes or states where

processing behaviour is affected
• Windows where there are dependencies
between objects in the window.
Table 3 - Traditional test techniques
3.4 Desktop Integration Testing
It is rare for a desktop PC or workstation to run a single application. Usually, the same machine
must run other bespoke applications or shrink wrapped products such as a word processor,
spreadsheet, electronic mail or Internet based applications. Client/server systems assume a
‘component based’ architecture so they often treat other products on the desktop as components
and make use of features of these products by calling them as components directly or through
specialist middleware.
We define desktop integration as the integration and testing of a client application with these
other components. Because these interfaces may be hidden or appear ‘seamless’ when working,
the tester usually needs to understand a little more about the technical implementation of the
interface before tests can be specified. The tester needs to know what interfaces exist, what
mechanisms are used by these interfaces and how the interface can be exercised by using the
application user interface.
To derive a list of test cases the tester needs to ask a series of questions for each known
interface:
• Is there a dialogue between the application and interfacing product (i.e. a sequence of
stages with different message types to test individually) or is it a direct call made once
only?
• Is information passed in both directions across the interface?

• Is the call to the interfacing product context sensitive?
• Are there different message types? If so, how can these be varied?
In principle, the tester should prepare test cases to exercise each message type in circumstances
where data is passed in both directions. Typically, once the nature of the interface is known,
equivalence partitioning, boundary values analysis and other techniques can be used to expand
the list of test cases.
3.5 Client/Server Communication Testing
Client/Server communication testing complements the desktop integration testing. This aspect
covers the integration of a desktop application with the server-based processes it must
communicate with. The discussion of the types of test cases for this testing is similar to section
3.4 Desktop Integration, except there should be some attention paid to testing for failure of
server-based processes.
In the most common situation, clients communicate directly with database servers. Here the
particular tests to be applied should cover the various types of responses a database server can
make. For example:
• Logging into the network, servers and server-based DBMS.

• Single and multiple responses to queries.
• Correct handling of errors (where the SQL syntax is incorrect, or the database server or
network has failed)
• Null and high volume responses (where no rows or a large number of rows are returned).
The response times of transactions that involve client/server communication may be of interest.
These tests might be automated, or timed using a stopwatch, to obtain indicative measures of
speed.
3.6 Synchronisation Testing
There may be circumstances in the application under test where there are dependencies between
different features. One scenario is when two windows are displayed, a change is made to a piece
of data on one window and the other window needs to change to reflect the altered state of data
in the database. To accommodate such dependencies, there is a need for the dependent parts of
the application to be synchronised.
Examples of synchronisation are when:
• The application has different modes - if a particular window is open, then certain menu
options become available (or unavailable).
• If the data in the database changes and these changes are notified to the application by
an unsolicited event to update displayed windows.
• If data on a visible window is changed and makes data on another displayed window
inconsistent.
In some circumstances, there may be reciprocity between windows. For example, changes on
window A trigger changes in window B and the reverse effect also applies (changes in window B
trigger changes on window A).
In the case of displayed data, there may be other windows that display the same or similar data
which either cannot be displayed simultaneously, or should not change for some reason. These
situations should be considered also. To derive synchronisation test cases:
• Prepare one test case for every window object affected by a change or unsolicited event
and one test case for reciprocal situations.
• Prepare one test case for every window object that must not be affected - but might be.
3.7 Non-Functional Testing
The tests described in the previous sections are functional tests. These tests are adequate for
demonstrating the software meets it’s requirements and does not fail. However, GUI applications
have non-functional modes of failure also. We propose three additional GUI test types (that are
likely to be automated).
Soak Testing
In production, systems might be operated continuously for many hours. Applications may be
comprehensively tested over a period of weeks or months but are not usually operated for
extended periods in this way. It is common for client application code and bespoke middleware to
have memory-leaks. Soak tests exercise system transactions continuously for an extended period
in order to flush out such problems.
These tests are normally conducted using an automated tool. Selected transactions are
repeatedly executed and machine resources on the client (or the server) monitored to identify
resources that are being allocated but not returned by the application code.
Compatibility Testing
Whether applications interface directly with other desktop products or simply co-exist on the same
desktop, they share the same resources on the client. Compatibility Tests are (usually)
automated tests that aim to demonstrate that resources that are shared with other desktop
products are not locked unnecessarily causing the system under test or the other products to fail.
These tests normally execute a selected set of transactions in the system under test and then
switch to exercising other desktop products in turn and doing this repeatedly over an extended
period.
Platform/Environment Testing
In some environments, the platform upon which the developed GUI application is deployed may
not be under the control of the developers. PC end-users may have a variety of hardware types
such as 486 and Pentium machines, various video drivers, Microsoft Windows 3.1, 95 and NT.
Most users have PCs at home nowadays and know how to customise their PC configuration.
Although your application may be designed to operate on a variety of platforms, you may have to
execute tests of these various configurations to ensure when the software is implemented, it
continues to function as designed. In this circumstance, the testing requirement is for a
repeatable regression test to be executed on a variety of platforms and configurations. Again, the
requirement for automated support is clear so we would normally use a tool to execute these
tests on each of the platforms and configurations as required.
4 Test Automation
4.1 Justifying Automation
Automating test execution is normally justified based on the need to conduct functional regression
tests. In organisations currently performing regression test manually, this case is easy to make -
the tool will save testers time. However, most organisations do not conduct formal regression
tests, and often compensate for this ‘sub-consciously’ by starting to test late in the project or by
executing tests in which there is a large amount of duplication.
In this situation, buying a tool to perform regression tests will not save time, because no time is
being spent on regression testing in the first place. In organisations where development follows a
RAD approach or where development is chaotic, regression testing is difficult to implement at all -
software products may never be stable enough for a regression test to mature and be of value.
Usually, the cost of developing and maintaining automated tests exceeds the value of finding
regression errors.
We propose that by adopting a systematic approach to testing GUIs and using tools selectively
for specific types of tests, tools can be used to find errors during the early test stages. That is, we
can use tools to find errors pro-actively rather than repeating tests that didn’t find bugs first time
round to search for regression errors late in a project.
4.2 Automating GUI Tests
Throughout the discussion of the various test types in the previous chapter, we have assumed
that by designing tests with specific goals in mind, we will be in a better position to make
successful choices on whether we automate tests or continue to execute them manually. Based
on our experience of preparing automated tests and helping client organisations to implement
GUI test running tools we offer some general recommendations concerning GUI test automation
below.
Pareto law • We expect 80% of the benefit to derive from the

automation of 20% of the tests.
• Don’t waste time scripting low volume complex scripts
at the expense of high volume simple ones.
Hybrid Approach • Consider using the tools to perform navigation and

data entry prior to manual test execution.
• Consider using the tool for test running, but perform
comparisons manually or ‘off-line’.
Coded scripts • These work best for navigation and checklist-type

scripts.
• Use where loops and case statements in code
leverage simple scripts.
• Are relatively easy to maintain as regression tests.
Recorded Scripts • Need to be customised to make repeatable.

• Sensitive to changes in the user interface.
Test Integration • Automated scripts need to be integrated into some

form of test harness.

• Proprietary test harnesses are usually crude so
custom-built harnesses are required.
Migrating Manual • Manual scripts document automated scripts

Test Scripts • Delay migration of manual scripts until the software is
stable, and then reuse for regression tests.
Non-Functional • Any script can be reused for soak tests, but they must
Tests exercise the functionality of concern.
• Tests of interfaces to desktop products and server
processes are high on the list of tests to automate.
• Instrument these scripts to take response time
measurements and re-use for performance testing.
From the discussion above, we are now in a position to propose a test automation regime that fits
the GUI test process. Table 4 - Manual versus automated execution presents a rough guideline
and provides a broad indication of our recommended approach to selecting tests to automate.
Test Types Manual or Automated?
Checklist testing Manual execution of tests of application conventions
Automated execution of tests of object states, menus

and standard features
Navigation Automated execution.
Equivalence Partitioning, Automated execution of large numbers of simple tests

Boundary Values, Decision of the same functionality or process e.g. the 256
Tables, State Transition combinations indicated by a decision table.
Testing
Manual execution of low volume or complex tests
Desktop Integration, C/S Automated execution of repeated tests of simple

Communications transactions
Manual tests of complex interactions
Synchronisation Manual execution.
Soak testing, Compatibility Automated execution.

testing,
Platform/environment
Table 4 - Manual versus automated execution
5 Improving the testability of GUI Applications

5.1 The GUI Testing Challenge
It is clear that GUIs present a challenge to testers because they appear to be inherently more
difficult to test. The flexibility of GUIs invites programmers to pass on this flexibility to end users in
their applications. Consequently, users can exercise the application code in ways never
envisaged by the programmers and which are likely to be released untested.
If testability is the ease with which a tester can specify, prepare, execute and analyse tests, it is
arguable that it is possible for programmers to build untestable systems using GUIs.
It is difficult to specify tests because much of the underlying functionality in a GUI application is
undocumented. Because of the event-driven nature of GUIs, a considerable amount of
programming effort is expended on dealing with hidden interactions that come to light during the
informal programmer testing so tend to go undocumented.
It is difficult to prepare tests because the number tests required to exercise paths through the
application which a user might follow has escalated dramatically. If we consider using menus,
function keys and mouse movements to exercise system features, the number of tests increased
further.
It is difficult to execute tests. Using a manual pointing device is virtually unrepeatable and
certainly error prone. Creating tests which stimulate hidden interactions, set or amend visible (or
invisible) GUI objects is troublesome. Separating tests of application code from the GUI elements
of the operating system is tricky.
It is difficult to analyse tests because there is constant change on the screen and behind the
screen. Windows on which results are displayed may appear and all other visible windows may
be refreshed simultaneously making visual inspection difficult. Expected results may not be
directly displayed but on hidden windows. Attributes of objects to be verified may be invisible or
difficult to detect by eye. Windows that display invalid results may be hidden by other windows or
on windows that are minimised.
OBJECT-ORIENTED TESTING: MYTH AND REALITY
A test process that complements object-oriented design and programming can significantly
increase reuse, quality, and productivity. Establishing such a process usually means dealing with
some common mis-perceptions (myths) about testing object-oriented software. This article is
about these perceptions. We'll explore these myths and their assumptions and then explain why
the myth is at odds with reality.
Myth: Testing is unnecessary -- objects and object-oriented development are different, after all.
Object-oriented development is iterative, so with each iteration, we'll find and reduce bugs -- this
is an easier and more effective way (than testing) to develop trustworthy classes. Reuse by itself
means that an object has been sufficiently exercised. Objects acquire stability through reuse; this
a "natural" way to obtain high quality. With iterative and incremental development we obviate the
need for a separate test activity, which was really only necessary in the first place because
conventional programming languages made it so easy to make mistakes.
Reality: Human error is as likely as ever. As with conventional languages, it results in simple
programming mistakes, unanticipated interaction, and incorrect or missing behavior. Reuse in no
way guarantees that a sufficient number of paths and states have been exercised to reveal all
faults. Reuse is limited to the extent that supplier classes are trustworthy. Debugging by reuse is
simply not an efficient strategy for rapid, large-scale development. As reusers, we would do well
to follow President Regan's SALT strategy: "Trust but verify."
Myth: Testing gets in the way. Class development is an exploratory process, not unlike
composing music or prose. Writing good software is like telling a good story -- it just flows and
grows. The idea of testing to find faults is fundamentally wrong -- all we need to do is to keep
"improving" our good ideas. The simple act of expression is sufficient to create trustworthy
classes. Testing is a destructive, rote process -- it isn't a good use of developer's creative abilities
and technical skills.
Reality: Testing can be a complementary, integral part of development. On a personal level,

this argument often boils down to simple distaste for what is perceived to be an unpleasant task
(see Testing is Trivial.) While poorly organized testing is usually an ineffective hassle, a good
testing strategy contributes. There are two sophisticated alternatives to unit testing: Mill's Clean
Room approach and Glib's inspections. Both assert that unit testing effort can be minimized if the
formal, defined, and repeatable development practices they recommend are used. Neither
advocates skipping integration and system testing.
Myth: Testing is structured/waterfall idea -- it can't be consistent with incremental object-

oriented development. Objects evolve -- they aren't just designed, thrown over the wall for coding,
and over another wall for testing. What's more, if you test each class in a system separately then
you have to do "big-bang" integration, which is an especially bad idea with object-oriented
systems.
Reality: Testing can be incremental and iterative. While the iterative and incremental nature of
object-oriented development is inconsistent with a simple, sequential test process (test each unit,
then try to integrate test all of them, then do system test), it does not mean that testing is
irrelevant. The boundary that defines the scope of unit and integration testing is different for
object-oriented development. Tests can be designed and exercised at many points in the
process. Thus "design a little, code a little" becomes "design a little, code a little, test a little." The
scope of testing corresponds to the collaborations necessary to accomplish the responsibility
under test. The appropriate goals and techniques shift with the scope of integration: very oo-
specific for a small scope and increasingly less oo-specific for a larger scope. If the system under
development is a library component (not an application system), then scope remains small. As
the scope of integration in an application system approaches all components in the system, the
appropriate testing techniques are very similar to conventional system testing.
Myth: Testing is trivial. Testing is simply poking around until you run out of time. All we need to
do is start the app, try each use-case, and try some garbage input. Testing is neither serious nor
challenging work -- hasn't most of it has already been automated?
Reality: Hunches about testing completeness are notoriously optimistic. Adequate testing
requires a sophisticated understanding of the system under test. You need to be able to develop
an abstract view of the dynamics of control flow, data flow, and state space in a formal model.
You need an understanding of system requirements at least as good as the designer's or user's.
You need to be able to define the expected results for any input and state you select as a test
case. This is interesting work for which little automation is available.
Myth: Automated GUI testing is sufficient. If a system is automatically exercised by trying

permutations of GUI commands supplied by a command playback tool, the underlying application
objects will be sufficiently tested.
Reality: GUI-based tests may be little more than automated testing-by-poking-around.

While there are many useful capture/playback products to choose from, the number of hours a
script runs has no direct or necessary correlation with the extent that the system under test has
been exercised. It is quite possible to retest the same application logic over and over, resulting in
an inflated confidence. Further, GUI test tools are typically of little use for objects in embedded
systems.
Myth: If programmers were more careful, testing would be unnecessary. Programming

errors can be eliminated by extra effort, extra pressure, or extra incentive. Bugs are simply an
indication of poor work habits. These poor work habits could be avoided if we'd use a better
management strategy.
Reality: Many bugs only surface during integration. There are many interactions among
components that cannot be easily forseen until all or most components of a system are integrated
and exercised. So, even if we could eliminate all individual sources of error, integration errors are
highly likely. Compared to conventional systems, object-oriented systems have more components
which must be integrated earlier in development. Since there are elements of a system that are
not present until the code has been loaded into the target machine and exercised, there is no way
that all faults could be removed by class or class-cluster testing alone, even if every method was
subjected to a formal proof of correctness. Static methods cannot reveal interaction errors with
the target or transient performance problems in hard real-time systems.
Myth: Testing is inconsistent with a commitment to quality. Testing assumes faults have
escaped the design and programming process. This assumption is really just an excuse for
sloppy development. All bugs are due to errors that could be avoided if different developer
behavior could be induced. This perception is often a restatement of the preceeding sloppy
programmer myth
Reality: Reliable software cannot be obtained without testing Testing activities can begin and
proceed in parallel with concept definition, OOA, OOD, and programming. When testing is
correctly interleaved with development, it adds considerable value to the entire development
process. The necessity of testing is not an indictment of anything more than the difficulty of
building large systems.
Myth: Testing is too expensive -- we don't have time. To test beyond testing-by-poking-
around takes too much time and costs too much. Test tools are an unnecessary luxury since all
we need are a few good pokes. Besides, projects always slip -- testing time gets squeezed
anyway.
Reality: Pay me now, or pay me much more later. The cost of finding and correcting errors is
always higher as the time between fault injection and detection increases. The lowest cost results
when you prevent errors. If a fault goes unnoticed, it can easily take hours or days of debugging
to diagnose, locate, and correct after the component is in widespread use. Failures in operational
systems can cause severe secondary problems. Proper testing is very cheap by comparison,
even when done manually. Efficient testing requires automated support. The typical testing tool
pays for itself after one or two projects by either increasing the number of tests that can be run
with a given budget or reducing the cost to achieve a reliability goal. Reduction of testing due to
schedule slippage is a frequent problem. The fact that it happens does not mean that testing is
unwise. This kind of schedule compression can usually be avoided by starting test activities
earlier in the project.
Myth: Testing is the same (as it is with conventional software). The only kind of testing that
matters is "black-box" system testing, where we define the externally observable behavior to be
produced from a given input. We don't need to use any information about the implementation to
select these tests and their test inputs.
Reality: OO code structure matters. Effective testing is guided by information about likely
sources of error. The combination of polymorphism, inheritance, and encapsulation are unique to
object-oriented languages, presenting opportunities for error that do not exist in conventional
languages. Our testing strategy should help us look for these new kinds of errors and offer criteria
to help decide when we've done enough looking. Since the "fundamental paradigm shift" often
touted for object-oriented development has lead to some new points of view and representations,
our techniques for extracting test cases from these representations must also change.
Myth: Conventional testing is useless for objects. Objects are so different, everything we
know about conventional testing is useless. Conventional testing deals with statement control
flow in modules; object methods are small and encapsulated, so control flow can be checked by
inspection. Conventional testing doesn't deal with state and collaborations.
Reality: Conventional testing techniques can be adapted. There is a large body of knowledge
about testing which is theoretically and practically proven. We know how to model paths, states,
data flow, and how to efficiently select test cases. While the kinds of errors we're likely to see in
object-oriented code are different than those in conventional software, basic testing techniques
continue to apply, with the necessary changes. For example, I've developed a technique for
testing all intra-class data flows which combines ideas from data-flow testing and state-machine
testing. It offers a systematic means to exercise all possible data flows over all possible method
activation sequences.
Myth: Inheritance means never having to say you're sorry. Specializing from trusted (or
tested) super classes means that their subclasses will also be correct -- we don't need to retest
inherited features.
Reality: Subclasses create new ways to misuse inherited features. Each subclass is a new
and different context for an inherited superclass feature. Different test cases are needed for each
context. Inherited features need to be exercised in the unique context of the subclass. We need
to retest inherited methods, even if they weren't changed. Although methods A and B may work
perfectly well in a superclass, the action and interaction of A, B, and C (an extension) in subclass
should be tested. We need to see that C uses A and B correctly and that C does not produce any
side effects which cause failures in A or B. None of this is assured by testing the superclass
containing only A and B, or by only testing method C in its subclass.
Myth: Reuse means never having to say you're sorry. Reusing a trusted class (either by
defining instance variables of its type or sending a message) means that the behavior of the
server object is trustworthy, and obviates the need for retesting the server.
Reality: Every new usage provides ways to misuse a server. Even if many server object of a
given class function correctly, nothing is to prevent a new client class from using it incorrectly.
Thus, all client class' use of a server needs to exercised. An interesting corollary is that we can't
automatically trust a server because it performs correctly for one client.
Myth: Black box testing is sufficient. If you do a careful job of test case design using the class
interface or specification, you can be assured that the class has been fully exercised. White-box
testing (looking at a method's implementation to design tests) violates the very concept of
encapsulation.
Reality: OO structure matters, part II. Many studies have shown that black-box test suites
thought to be excruciatingly thorough by developers only exercise from one-third to a half of the
statements (let alone paths or states) in the implementation under test. There are three reasons
for this. First, the inputs or states selected typically exercise normal paths, but don't force all
possible paths/states. Second, black-box testing alone cannot reveal surprises. Suppose we've
tested all of the specified behaviors of the system under test. To be confident there are no
unspecified behaviors we need to know if any parts of the system have not been exercised by the
black-box test suite. The only way this information can be obtained is by code instrumentation.
Third, it is often difficult to exercise exception and error-handling without examination of the
source code
.
Keyword Based Test Automaton
Keyword Concept
Keyword based test design and test automation is founded on the premise that the discrete
functional business events that make up any application can be described using a short text
description (Keyword) and associated parameter value pairs (arguments). For example, most
applications require the user to login; the Keyword for this business event could be "Logon User"
and the parameters could be "User Id" and "Password". By designing Keywords to describe
discrete functional business events the testers begin to build up a common library of Keywords
that can be used to create Keyword test cases. This is really a process of creating a language
(Keywords) to describe a sequence of events within the application (Test Case).
When properly implemented and maintained Keywords present a superior return on investment
because each business event is designed, automated, and maintained as a discrete entity. These
Keywords can then be used to design Keyword test cases but the design and automation
overhead for the Keyword itself has already been paid. When a change occurs within any given
Keyword the impacted test cases can easily be found and updated appropriately and once again
any design or automation updates to the Keyword itself are performed only once. Compare this to
the Record and Playback approach which captures a particular business event or part of the
business event each time a test case traverses it - if there are 100 test cases that start with
logging on, then this event will have automated 100 times and there will be 100 instances to
maintain.
Keyword Development
Development of Keywords should be approached in the same manner as any formal

development effort. Keywords must be designed, coded, implemented and maintained.
Design The Test Designer is responsible for Keyword design - at a minimum the design of a
Keyword should include: Keyword Name, Keyword Description, and Keyword parameters.
Keyword Name
A standard Keyword naming convention should be drafted and followed to allow designers to
efficiently share Keywords. The Keyword name should begin with the action being performed
<action> followed by the functional entity <entity> followed by descriptive text <text> (if required).
Here are several common examples:
• Logon User - Logon User

• Enter Customer Name - Enter Customer Name
• Enter Customer Address - Enter Customer Address
• Validate Customer Name - Validate Customer Name
• Select Customer Record - Select Customer Record
The Keyword name should be a shorthand description of what actions the Keyword performs.
Keyword Description
The Keyword description should describe the behavior of the Keyword and contain enough
information for the Test Automation Engineer to construct the Keyword. For Designers the
description is the Keyword definition, for Automation Engineers, the functional specification. This
should be a short but accurate description - here is an example for the Keyword "Logon User":
Logon User Description: On the Logon screen enter specified User Id and Password and then
press the OK button.
Keyword Parameters
The Keyword Parameters should capture all the business inputs that could impact the immediate
business event being defined by the Keyword. The simplest and most reliable method for getting
the appropriate list of parameters is to take a "capture what is displayed" approach. For the
Keyword "Logon User" the application displays three elements: "User Id", "Password", and OK
button - the two parameters required to support this Keyword are "User Id" and "Password". The
OK button does not require a parameter because the Keyword description states that the OK
button will always be pressed. If there were multiple buttons (i.e. OK, CANCEL, and EXIT) then a
third parameter "Press Button" would be required and the Keyword description would have to be
modified.
Code
The Test Automation Engineer takes the Keyword Name, Description, Parameters, Application
Under Test, and Keyword development standards and constructs the Keyword. If there are any
issues with the design aspects of the Keyword the Automation Engineer liaisons with the Test
Designer and the design is modified to clarify the intent of the Keyword. If there are any
automation / engineering challenges then the Automation Engineer liaisons with the Development
team and the Tool Vendor to find an appropriate automation solution that fits the automation
framework.
Implement
Keyword implementation follows the same path of any shareable project resource. At the
minimum the completed Keyword should be: reviewed by the Test Designer, Unit Tested by the
Automation Engineer, Function Tested, and migrated into the project Testware. This does not
need to be a complex or extensive process but it should ensure that any implemented Keyword is
published to the testing team and functions as expected.
Maintain
Keyword maintenance occurs when: a Keyword defect is detected, a business event changes, or
a when Keyword standards are modified. Keyword maintenance follows the same deployment
path as Keyword Development: Design, Code, and Implement.
Keyword Test Case
Keyword Test Cases are a sequence of Keywords designed to test or exercise one or more
aspects of the application or applications being tested. Keyword Test Cases must be: Designed,
Executed, and Maintained. Keyword Test Cases are the responsibility of the Test Designer /
Tester, the Automation Engineer only becomes involved if a defect occurs during Keyword Test
Case execution. It should be noted that the Keyword design paradigm is often used in the
absence of Keyword automation - it is an effective standalone test design paradigm.
Design
Keyword Test Case design involves planning the intent of the test case, building the test case
using Keywords, and testing the design against the application or applications being tested. At
first glance this does not appear to be any different than any other method for test case design
but there are significant differences between Keyword Test Case design and any freehand /
textual approach to test case design. Keyword test case designs are: Consistent - the same
Keyword is used to describe the business event every time, Data Driven - the Keyword contains
the data required to perform the test step, Self Documenting - the Keyword description contains
the details of the designers intent, Maintainable - with consistency comes maintainability, and
finally supports automation with no transformation from test design to automated script. Test
Designers gain the power of test automation without having to become Test Automation
Engineers.
Execution
The tester can perform keyword test case execution manually by performing the Keyword steps in
sequence - this should be performed as part of the Keyword verification process. Test Cases,
which are constructed using Automated Keywords, can be executed using the Test Automation
tool or by an integrated test management tool. Test Case execution should always be a
mechanical exercise whether automation is in use or not. The test case should contain all the
information necessary to execute the test case and determine its success or failure.
Maintenance
Test Case maintenance must occur when changes occur in the application behavior or in the
design of a Keyword that is being used in one or more test cases. A properly implemented
Keyword framework will allow the Tester to find all instances of a Keyword via some query
mechanism - reducing the often-painful process of finding the impacted test cases to one simple
step. Furthermore, a well-implemented Keyword framework should support global changes to
Keyword instances.
Keyword Implementations
GUI (graphical user interface)
Keyword solutions for GUI based applications are the easiest to understand and implement. Most
shareware, freeware, and commercial applications of Keyword testing deal with this space.
API (application programming interface)
Keyword solutions for API based applications appear more complex on the surface but once
these applications are broken down into their discrete functional business events their behavior is
much the same as an equivalent GUI application. If the business event were "Logon User" it
doesn't really matter what which application mechanism is used to implement the event, the
Keyword would look and behave the same if the business drivers were the same. There are
several Keyword solution vendors that deal with the API space and the same vendor often has a
solution for GUI applications.
Telecom (Telecommunication Protocols)
Keyword solutions for the Telecom space (example SS7) require an intimate understanding of
Telecommunication Protocols. There are vendors that offer Keyword solutions in this space.
Keywords and Test Phases
Unit Test
Keywords can be applied to Unit test but it is not recommended. The development group, using
the tools and techniques available in the development suite, should do unit test.
Function (Integration Test)
Keyword test solution focused on designing and implementing Keywords as discrete functional
business events offer one of the most cost effective and maintainable test frameworks for
Function test. In fact, if test automation of a GUI or API based application is required or desired
there are few frameworks that can match its short term or long term ROI (return on investment).
System Test
A Keyword based testing solution that leverages the Keywords from Function Test to the System
Test phase will help expedite the testing process. An effective Keyword framework will allow the
Test Designer to combine function level Keywords into System level Keywords. System level
Keywords deal with complete business events rather than the discrete functional business events
that make up a business thread. For example a System level Keyword could be "Complete
Customer Application" that could be made up of this chain of Function level Keywords: "Enter
Customer Name", "Enter Customer Contact Information", "Enter Customer Personal Information",
and "Save Customer Record".
User Acceptance Test
Keywords can be applied to User Acceptance Test but it is not recommended unless this is an
extensive phase of testing. The end user community using the tools, techniques, and processes
available in production best perform user Acceptance Test.

Types of Testings and Their Strategies

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Types of Testings and Their Strategies

Transféré par

Droits d'auteur :

Formats disponibles

Jagan Mohan Julooru Types of Testing & their Strategies

TYPES OF TESTINGS AND THEIR STRATEGIES

QUALITY ASSURANCE ACTIVITIES

For the purposes of this document, a high-quality application is one that:

• carries out the purpose intended by the user.

• standard analysis, design, and development techniques.

STRUCTURED WALKTHROUGHS AND TECHNICAL REVIEWS

THE TESTING STRATEGY

At a minimum, the Testing Strategy should address the following:

TESTING STRATEGY / TEST PLAN

Key elements of test management include:

A common criticism of construction programmes is that insufficient time is frequently allocated to

BLACK BOX TESTING STRATEGY

Testing method where user is not required:

Testing where user plays a role/user is required:

User Acceptance Testing:

WHITE BOX TESTING STRATEGY

Advantages of White box testing are:

Disadvantages of white box testing are:

Types of testing under White/Glass Box Testing Strategy:

Static and dynamic Analysis:

Testing Levels / Phases

User Acceptance Test

Test Lead or Test Manager

Test Designer or Tester

Test Automation Engineer

Test Methodologist or Methodology Specialist

White-box Tests or Glass-box tests

AUTOMATED TESTING TERMINOLOGY

Error The difference between a computed, observed, or measured value or condition

Fault An incorrect step, process, or data definition in a computer program.

Debug To detect, locate, and correct faults in a computer program.

Verification The process of evaluating a system or component to determine whether the

SOFTWARE TESTING DICTIONARY

Artistic testing. Also known as Exploratory testing.

(1) An independent examination of a work product or set of work products to assess

BRS - Business Requirement Specification

Clear-box testing. See White-box testing.

Comparison testing. Comparing software strengths and weaknesses to competing products

Configuration. The functional and/or physical characteristics of hardware/software as set forth in

Configuration control. An element of configuration management, consisting of the evaluation,

Conformance directed testing. Testing that seeks to establish conformance to requirements or

Dirty testing Negative testing. [Beizer]

Incremental integration testing. Incremental integration testing - continuous testing of an

Integration. The process of combining software components or hardware components or both

Integration testing - testing of combined parts of an application to determine if they function

Inter-operability Testing. True inter-operability testing concerns testing for unforeseen

Install/uninstall testing. Testing of full, partial, or upgrade install/uninstall processes.

Limits testing. See Boundary Condition testing.

Longevity testing. See Reliability testing.

Long-haul Testing. See Reliability testing.

Monkey Testing. (dumb-monkey testing)Inputs are generated from a uniform probability

Orthogonal array testing: Mathematical technique to determine which variations of parameters

Performance Testing. Testing conducted to evaluate the compliance of a system or component

Reengineering. The process of examining and altering an existing system to reconstitute it in a

Scalability testing is a subtype of performance test where performance requirements for

Specification-based test. A test, whose inputs are derived from a specification.

SRS. Business Requirement Specification.

Test Item. A software item which is the object of testing.[IEEE]

Test Status. The assessment of the result of running tests on software.

Test Tree. A physical implementation of Test Suite. [Dorothy Graham, 1999]

Translation testing. See internationalization testing.

1.1 GUIs as universal client