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

draw and explain state and activity diagram of library management system
Prashant Reply
hii
Sonu
explain association and generalisation with library system diagram
Prashant Reply
what do you mean by functional and non functional requirements
RICHA Reply
functional - describes what a software system should do . non functional - place constraints on how the will do so
rubi
non functional requirement include: quility . reliability . response time . security . privacy . effectiveness . maintainability . robustness scalability . fault tolerance . extensibility . efficiency . portability . resilience ... .
rubi
🙏🙏🙏🙏🙏
Sonu
🙏🙏🙏🙏🙏
Sonu
hello
Akhand
🇨🇮🇨🇮🇨🇮
Sonu
What does encapsulation mean?
Sravanthi Reply
Encapsulation in Java is a process of wrapping code and data together into a single unit, for example, a capsule which is mixed of several medicines. ... Now we can use setter and getter methods to set and get the data in it. The Java Bean class is the example of a fully encapsulated class.
Hello
What is software Engineering
Jakisay Reply
Sofyware engineering is the application of principles used in the field of engineering which usually deals with phsical systems to the design, testing, development, deployment and management of software systems
Remie
what is cocomo model
Shrudhi Reply
The Constructive Cost Model is a procedural software cost estimation model developed by Barry W. Boehm. The model parameters are derived from fitting a regression formula using data from historical projects
Tilak
Please is there any scholarship for African students undergraduate for now
Awal Reply
4 generation technology
RICHA Reply
Richa, what is your question?
Darrell
what is the work of software engineer
mercy Reply
DilipDas
Dili
steps of developing a software
latest Reply
Present
win
bamori project
Rajendra
which approach used to reduce number of test cases
Harshdeep Reply
I wish to ask what is the mean of a data model
Ateke Reply
explanation of working of computer
Gulfam Reply
Hi
Yaw
hello.
Martins
hi
Naeem
How are u guys
Ato
What is software engineering
parfait Reply
explain basic path testing for triangle problem?
Janavi Reply

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