Programming Portal: SOFTWARE BUGS

Showing posts with label SOFTWARE BUGS. Show all posts

REVIEWS IN SOFTWARE TESTING

Software reviews are a "filter" for the software engineering process. That is, reviews are applied at various points during software development and serve to uncover errors and defects that can then be removed.

Software reviews "purify" the software engineering activities that we have called analyssis , design, and coding. Freedman and Weinberg discuss the need for reviews this way:

Technical work needs reviewing for the same reason that pencils need erasers: To err is human. The second reason we need technical reviews is that although people are good at catching some of their own errors , large classes of errors escape the originator more easily than they escape anyone else. The review process is, therefore, the answer to the prayer of Robert Burns:

O wad some power the giftie give us to see ourselves as other see us

A review—any review—is a way of using the diversity of a group of people to:

1. Point out needed improvements in the product of a single person or team;

2. Confirm those parts of a product in which improvement is either not desired or not needed;

3. Achieve technical work of more uniform, or at least more predictable, quality than can be achieved without reviews, in order to make technical work more manageable.

Many different types of reviews can be conducted as part of software engineering. Each has its place. An informal meeting around the coffee machine is a forma review, if technical problems are discussed. A formal presentation of software design to an audience of customers, management, and technical staff is also a form of review.

A formal technical review is the most effective filter from a quality standpoint. Conducted by software engineers (and others) for software engineers, the FTR is an effective means for improving software quality.

Cost Impact of Software Defects

The IEEE Standard Dictionary of Electrical and Electronics Terms (IEEE Standard 100-1992) defines a defect as "a product anomaly." The definition for fault in the hardware context can be found in IEEE Standard 610.12-1990:

(a) A defect in a hardware device or component; for example, a short circuit or broken wire, (b) An incorrect step, process, or data definition in a computer program. Note: This definition is used primarily by the fault tolerance discipline. In common usage, the terms "error" and bug are used to express this meaning. See also: data-sensitive fault; program-sensitive fault; equivalent faults; fault masking; intermittent fault.

Within the context of the process, the terms defect and fault are synonymous. Both imply a quality problem that is discovered after the software has been released to end-users (or to another activity in the software process).

The primary objective of formal technical reviews is to find errors during the process so that they do not become defects after release of the software. The obvious benefit of formal technical reviews is the early discovery of errors so that they do not propagate to the next step in the software proess.

Need of testing

Testing can and should occur throughout the phases of a project.

Requirements Phase

· Determine the test strategy.

· Determine adequacy of requirements.

· Generate functional test conditions.

Design Phase

· Determine consistency of design with requirements.

· Determine adequacy of design.

· Generate structural and functional test conditions.

Program (Build) Phase

· Determine consistency with design.

· Determine adequacy of implementation.

· Generate structural and functional test conditions for programs/units.

Test Phase

· Determine adequacy of the test plan.

· Test application system.

Installation Phase

· Place tested system into production.

Maintenance Phase

· Modify and retest.

SOFTWARE QUALITY ASSURANCE AND CONTROL

SOFTWARE QUALITY AND COST ASPECT

STABLE PROCESS OF SOFTWARE TESTING

STABLE PROCESS OF SOFTWARE TESTING PART TWO

DEFECTS IN SOFTWARE TESTING

REDUCTION OF DEFECTS IN SOFTWARE TESTING

SOFTWARE TESTING AND EFFECTING FACTORS

SCOPE OF SOFTWARE TESTING

TESTING LIFE CYCLE PART ONE

TESTING LIFE CYCLE PART TWO

TESTING LIFE CYCLE PART THREE

SOFTWARE TESTING AND CONSTRAINTS WITH IN IT

TESTING CONSTRAINTS PART TWO

LIFE CYCLE TESTING

TEST METRICS

Independent Software Testing

Test Process

Testing verification and validation

Functional and structural testing

Static and dynamic testing

V model testing

Eleven steps of V model testing

Structural testing

Execution testing technique

Recovery Testing technique

Operation testing technique

Compliance software testing technique

Security testing technique

software bugs

Miscommunication or no communication - as to specifics of what an application should or shouldn't do (the application's requirements).

Software complexity - the complexity of current software applications can be difficult to comprehend for anyone without experience in modern-day software development. Windows-type interfaces, client-server and distributed applications, data communications, enormous relational databases, and sheer size of applications have all contributed to the exponential growth in software/system complexity. And the use of object-oriented techniques can complicate instead of simplify a project unless it is well-engineered.

Programming errors - programmers, like anyone else, can make mistakes.

Changing requirements - the customer may not understand the effects of changes, or may understand and request them anyway - redesign, rescheduling of engineers, effects on other projects, work already completed that may have to be redone or thrown out, hardware requirements that may be affected, etc. If there are many minor changes or any major changes, known and unknown dependencies among parts of the project are likely to interact and cause problems, and the complexity of keeping track of changes may result in errors. Enthusiasm of engineering staff may be affected.

In some fast-changing business environments, continuously modified requirements may be a fact of life. In this case, management must understand the resulting risks, and QA and test engineers must adapt and plan for continuous extensive testing to keep the inevitable bugs from running out of control - see 'What can be done if requirements are changing continuously?'

Time pressures - scheduling of software projects is difficult at best, often requiring a lot of guesswork. When deadlines loom and the crunch comes, mistakes will be made.

Egos - people prefer to say things like:

'no problem'
'piece of cake'
'I can whip that out in a few hours'
instead of:
'that adds a lot of complexity and we could end up making a lot of mistakes'
'we have no idea if we can do that; we'll wing it'
'I can't estimate how long it will take, until I take a close look at it'
'we can't figure out what that old spaghetti code did in the first place'

If there are too many unrealistic 'no problem's', the result is bugs.

Poorly documented code - it's tough to maintain and modify code that is badly written or poorly documented; the result is bugs. In many organizations management provides no incentive for programmers to document their code or write clear, understandable code. In fact, it's usually the opposite: they get points mostly for quickly turning out code, and there's job security if nobody else can understand it ('if it was hard to write, it should be hard to read').

Software development tools - visual tools, class libraries, compilers, scripting tools, etc. often introduce their own bugs or are poorly documented, resulting in added bugs.

Quality is a process of ensuring that all specified software processes have been properly executed.

(6.75)

Top Tabs

REVIEWS IN SOFTWARE TESTING

Need of testing

software bugs