Glossary of Software Testing Terms:
This glossary of software testing
terms and conditions is a compilation of knowledge, gathered
over time, from many different sources. It is provided as-is
in good faith, without any warranty as to the accuracy or
currency of any definition or other information contained
herein. If you have any questions or queries about the contents
of this glossary, please contact
Project Realms directly.
Backus-Naur Form (BNF)
A metasyntax used to express context-free grammars: that is,
a formal way to describe formal languages.
BNF is widely used as a notation for the grammars of computer
programming languages, instruction sets and communication
protocols, as well as a notation for representing parts of
natural language grammars. Many textbooks for programming
language theory and/or semantics document the programming
language in BNF.
The point at which some deliverable produced during the software
engineering process is put under formal change control.
A sequence of one or more consecutive, executable statements
containing no branches.
Basis Path Testing
A white box
test case design technique that fulfills the requirements
of branch testing & also tests all of the independent paths
that could be used to construct any arbitrary path through the
A popular software engineering technique used to measure test
coverage. Known bugs are randomly added to a program source
code and the programmer is tasked to find them. The percentage
of the known bugs not found gives an indication of the real
bugs that remain.
The combination of input values and preconditions along with
the required response for a function of a system. The full specification
of a function would normally comprise one or more behaviors.
Benchmark testing is a normal part of the application development
life cycle. It is a team effort that involves both application
developers and database administrators (DBAs), and should be
your application in order to determine current performance and
improve it. If the application code has been written as efficiently
as possible, additional performance gains might be realized
from tuning the database and database manager configuration
parameters. You can even tune application parameters to meet
the requirements of the application better.
You run different types of benchmark tests to discover specific
kinds of information:
Benchmarking is helpful in understanding how the database manager
responds under varying conditions. You can create scenarios
that test deadlock handling, utility performance, different
methods of loading data, transaction rate characteristics as
more users are added, and even the effect on the application
of using a new release of the product.
- A transaction per second benchmark deter-mines the throughput
capabilities of the data-base manager under certain limited
- An application benchmark tests the same throughput capabilities
under conditions that are closer production conditions.
Benchmark Testing Methods
Benchmark tests are based on a repeatable environment so that
the same test run under the same conditions will yield results
that can be legitimately compared.
Benchmarking may begin by running the test application in
a normal environment. As a performance problem is narrowed
down, specialized test cases can be developed that limit the
scope of the function that is being tested. The specialized
test cases don't need to emulate the entire application in
order to obtain valuable information. Start with simple measurements,
and increase the complexity only when necessary.
Characteristics of good benchmarks or measurements include:
- Tests are repeatable
- Each iteration of a test starts in the same system state
- No other functions or applications are active in the system
unless the scenario includes some amount of other activity
going on in the system
- The hardware and software used for benchmarking match
your production environment
For benchmarking, a scenario is created and then applications
in the scenario several times, capturing key information during
each run. Capturing key information after each run is of primary
importance in determining the changes that might improve performance
of both the application and the database.
Comes after alpha testing. Versions of the software, known
as beta versions, are released to a limited audience outside
of the company. The software is released to groups of people
so that further testing can ensure the product has few faults
or bugs. Sometimes, beta versions are made available to the
open public to increase the feedback field to a maximal number
of future users.
An inappropriate approach to integration testing in which you
take the entire integrated system and test it as a unit. Can
work well on small systems but is not favorable for larger systems
because it may be difficult to pinpoint the exact location of
the defect when a failure occurs.
Binary Portability Testing
Testing an executable application for portability across system
platforms and environments, usually for conformation to an ABI
Black Box Testing
Black Box Testing performs testing based on previously understood
requirements (or understood functionality), without knowledge
of how the code executes. For example, when black box testing
is applied to software engineering, the tester would only know
the "legal" inputs and what the expected outputs should
be, but not how the program actually arrives at those outputs.
It is because of this that black box testing can be considered
testing with respect to the specifications, not other knowledge
of the program is necessary. For this reason, the tester and
the programmer can be independent of one another, avoiding programmer
bias toward his own work. For this testing, test groups are
In the Black box testing type, the items being tested are
viewed as a black box, and the internals of that black box
are unknown. The focus is on validating outputs in response
to the inputs provided via the human interface, or validation
of outputs as a result of processing inputs acquired through
means other than the human interface. The tests pass if the
output result matches what was expected.
Advantages of Black Box Testing:
Disadvantages of Black Box Testing:
- More effective on larger units of code than glass box
- Tester needs no knowledge of implementation
- Tester and programmer are independent of each other
- Tests are done from a user's point of view
- Will help to expose any ambiguities or inconsistencies
in the specifications
- Test cases can be designed as soon as the specifications
- Only a small number of possible inputs can actually be
tested, to test every possible input stream would take nearly
- Without clear and concise specifications, test cases are
hard to design
- There may be unnecessary repetition of test inputs if
the tester is not informed of test cases the programmer
has already tried
- May leave many program paths untested
- Cannot be directed toward specific segments of code which
may be very complex (and therefore more error prone)
- Most testing related research has been directed toward
glass box testing
Automated matching logic applied to data and transaction driven
websites to automatically detect block s of related data. This
enables repeating elements to be treated correctly in relation
to other elements in the block without the need for special
Bottom Up Testing
An approach to integration testing where the lowest level components
are tested first, then used to facilitate the testing of higher
Tests focusing on the boundary or limits of the software
An input value or output value which is on the boundary between
equivalence classes, or an incremental distance either side
of the boundary.
Boundary Value Analysis
In boundary value analysis, test cases are generated using the
extremes of the input domain, e.g. maximum, minimum, just inside/outside
boundaries, typical values, and error values.
Boundary Value Coverage
The percentage of boundary values
which have been exercised by a test case suite.
A conditional transfer of control from any statement to any
other statement in a component,
or an unconditional transfer of control from any statement to
any other statement in the component except the next statement,
or when a component has more than one entry point, a transfer
of control to an entry point of the component.
Branch Condition Combination Coverage
The percentage of combinations of all branch condition outcomes
in every decision that has been tested.
Branch Condition Combination Testing
A test case design technique in which test cases are designed
to execute combinations of branch condition outcomes.
Branch Condition Coverage
The percentage of branch condition outcomes in every decision
that has been tested.
Branch Condition Testing
A technique in which test cases are designed to execute branch
A test case design technique for a component in which test cases
are designed to execute branch outcomes.
A test suite that exercises the full functionality of a product
but does not test features in detail.
A fault in the program which causes the program to perform in
an unintended way. See also Fault
A build is the actual group of code that will be deployed to
a test environment.
Build Validation is a quick test used to validate a new build.
It validates that the configuration is available, functional,
and no gross defects are apparent. It is a form of Ad Hoc testing
to ensure a build of software or a configuration is ready for
functional testing. In the software industry, this type of validation
is also known as a smoke
Business Analyst Role
Business analysts gather requirements, analyze design options,
and document a well defined solution. There may be one or more
associates playing the role of Business Analyst on a project,
depending on the project's size and testing needs. This role
can be a collaborative effort between business area associates,
depending on team members' knowledge of business processes and
the systems involved.
A set of user actions performed in an application to accomplish
a business task.
| Contact us for more info