<< Chapter < Page
  Software engineering     Page 1 / 15
Chapter >> Page >
This module provides an introduction to software testing. Topics covered include basic definitions of testing, validation and verification; the levels of testing from unit testing through to acceptance testing; the relationship with requirements and design specifications; and test documentation.

Introduction

Software Testing is the process of executing a program or system with the intent of finding errors. Or, it involves any activity aimed at evaluating an attribute or capability of a program or system and determining that it meets its required results. Software is not unlike other physical processes where inputs are received and outputs are produced. Where software differs is in the manner in which it fails. Most physical systems fail in a fixed (and reasonably small) set of ways. By contrast, software can fail in many bizarre ways. Detecting all of the different failure modes for software is generally infeasible.

Unlike most physical systems, most of the defects in software are design errors, not manufacturing defects. Software does not suffer from corrosion, wear-and-tear, generally it will not change until upgrades, or until obsolescence. So once the software is shipped, the design defects, or bugs, will be buried in and remain latent until activation.

Software bugs will almost always exist in any software module with moderate size: not because programmers are careless or irresponsible, but because the complexity of software is generally intractable, and humans have only limited ability to manage complexity. It is also true that for any complex systems, design defects can never be completely ruled out.

Discovering the design defects in software, is equally difficult, for the same reason of complexity. Because software and any digital systems are not continuous, testing boundary values are not sufficient to guarantee correctness. All the possible values need to be tested and verified, but complete testing is infeasible. Exhaustively testing a simple program to add only two integer inputs of 32-bits (yielding 2^64 distinct test cases) would take hundreds of years, even if tests were performed at a rate of thousands per second. Obviously, for a realistic software module, the complexity can be far beyond the example mentioned here. If inputs from the real world are involved, the problem will get worse, because timing and unpredictable environmental effects and human interactions are all possible input parameters under consideration.

A further complication has to do with the dynamic nature of programs. If a failure occurs during preliminary testing and the code is changed, the software may now work for a test case that it didn't work for previously. But its behavior on pre-error test cases that it passed before can no longer be guaranteed. To account for this possibility, testing should be restarted. The expense of doing this is often prohibitive.

An interesting analogy parallels the difficulty in software testing with the pesticide (known as the Pesticide Paradox): Every method you use to prevent or find bugs leaves a residue of subtler bugs against which those methods are ineffectual. But this alone will not guarantee to make the software better, because the Complexity Barrier principle states: Software complexity (and therefore that of bugs) grows to the limits of our ability to manage that complexity. By eliminating the (previous) easy bugs you allowed another escalation of features and complexity, but his time you have subtler bugs to face, just to retain the reliability you had before. Society seems to be unwilling to limit complexity because we all want that extra bell, whistle, and feature interaction. Thus, our users always push us to the complexity barrier and how close we can approach that barrier is largely determined by the strength of the techniques we can wield against ever more complex and subtle bugs.

Questions & Answers

which sdlc mode l is suitable for atm banking system
Rakesh Reply
HUAWEI.ABBULLAG.45720891
Abdula Reply
how to build apps
Andreas Reply
what is memory?
Hausa Reply
memory is billions of consecutive data storage cell where each of the cell has its own particular address of identification.
Shariful
what are the major difference in the external environment of an office automation system and that of an embedded systems
juma Reply
What is software engineering
Zohaib Reply
what is salary of a software engineer
Akash Reply
understand wllhi 😭am language somali bro 😇😣😣😣
what is agile
Qais Reply
what do you want
help
Billy
how to U download
Adam Reply
hi is there any mobile spy app best you know?
muddy Reply
what is software engineer
Soumen Reply
Who make the software he is the software engineer.
thando
i don't
Al
mobile spy android need it any one help me
muddy
🤔
I want to create a game
Rohith Reply
Requirements to create game
Rohith
yes i also
GURPREET
want to knoe about the reqirements
GURPREET
Yes
Rohith
what are software evolution processes
Software Evolution is a term which refers to the process of developing software initially, then timely updating it for various reasons, i.e., to add new features or to remove obsolete functionalities etc. ... If the proposed changes are accepted, a new release of the software system is planned
Fenkil

Get the best Software engineering course in your pocket!





Source:  OpenStax, Software engineering. OpenStax CNX. Jul 29, 2009 Download for free at http://cnx.org/content/col10790/1.1
Google Play and the Google Play logo are trademarks of Google Inc.

Notification Switch

Would you like to follow the 'Software engineering' conversation and receive update notifications?

Ask