Showing posts with label INTRODUCTIONS. Show all posts

Programming C Language Introduction

C programming language is said to be a middle level language because it combines the best elements of high-level languages with the control and flexibility of assembly language .

As a middle-level language, C allows the manipulation of bits, bytes, and addresses the basic elements with which the computer functions and C code is also very portable.Portability means that it is easy to adapt software written for one type of computer or operating system to another type.

All high level programming languages support the concept of data types. A data type defines a set of values that a variable can store along with a set of operations that can be performed on that variable. Common data types are integer, character, and floating-point. Although C has several built in data types, it is not a strongly typed language, as are Pascal and Ada. C permits almost all type conversions.

C specifies almost no run time error checking. For example, no check is performed to ensure that array boundaries are not overrun. and these types of checks are the responsibility of the programmer.

C does not demand strict type compatibility between a parameter and an argument.C allows an argument to be of any type so long as it can be reasonably converted into the type of the parameter and C provides all of the automatic conversions to accomplish this.

C allows the direct manipulation of bits, bytes, words, and pointers. This makes it well suited for system-level programming, where these operations are common.

C has only a small number of keywords, which are the commands that make up the C language. For example, C89 defined 32 keywords, and C99 adds only 5 more. High-level languages typically have many more keywords.

C is a structured language. The distinguishing feature of a structured language is compartmentalization of code and data. This is the ability of a language to section off and hide from the rest of the program all information and instructions necessary to perform a specific task. One way that you achieve compartmentalization is by using subroutines that employ local (temporary) variables.

By using local variables, you can write subroutines so that the events that occur within them cause no side effects in other parts of the program. This capability makes it very easy for your C programs to share sections of code. If you develop compartmentalized functions, you need to know only what a function does, not how it does it.

Structured languages typically support several loop constructs, such as while, do-while, and for. In a structured language, the use of goto is either prohibited or discouraged and is not the common form of program control . A structured language allows you to place statements anywhere on a line and does not require a strict field concept.

In C, functions are the building blocks in which all program activity occurs. They allow you to define and code individually the separate tasks in a program, thus allowing your programs to be modular.

After you have created a function, you can rely on it to work properly in various situations without creating side effects in other parts of the program. Being able to create stand alone functions is extremely important in larger projects where one programmer's code must not accidentally affect another's.

Related posts

Software testing prospective
INTRODUCTION TO C PROGRAMMING

Programming with C an introduction part two

Data types for C programming

C PROGRAMMING CHARACTER SET

CONSTANTS IN C PROGRAMMING

PROGRAMMING C VARIABLES

C PROGRAM INSTRUCTIONS

COMPILATION AND EXECUTION OF C PROGRAM

C PROGRAMMING RULES PART ONE

C PROGRAMMING RULES PART TWO

COMPILATION AND EXECUTION OF C PROGRAM

INSTRUCTIONS TO WRITE C PROGRAM

ARITHMETIC INSTRUCTIONS TO WRITE C PROGRAM

CONVERSION OF CONSTANTS IN C PROGRAM

PRIORITY OF AR THEMATIC OPERATIONS IN C

OPERATORS ASSOCIATIVITY IN C

IF STATEMENT

MULTIPLE STATEMENTS IN IF

IF AND ELSE

NESTED IF AND ELSE

BREAK

CONTINUE AND DO WHILE IN C LANGUAGE

SWITCH IN C PROGRAMMING

FUNCTIONS IN C PROGRAMMING

Functions and usage in C part two

Coding in C functions

SoftwareTesting Perspective

The testing perspective is a way of looking at any development product and questioning its validity. The person examining work products from this perspective utilizes a thorough investigation of the software and all its representations to identify faults. The search for faults is guided by both systematic thinking and intuitive insights.

It is a perspective that makes reviews and inspections just as powerful a tool as execution-based testing. A review will almost never find something that is missing—that is, a review typically only seeks to validate what exists and does not systematically search to determine if all things that should be in the software actually are in it.

The testing perspective requires that a piece of software demonstrate that it not only performs according to its specification, but performs only to that specification. Thus, a product is tested to determine that it will do what it is supposed to do, and it is also tested to ensure that it does not do what it is not supposed to do.

Software testing is typically accomplished by a combination of inspections, reviews, and test executions. The purpose of these activities is to observe failures.

An inspection is an examination of software based on a checklist of typical problems. Most items on a checklist are based on programming language semantics and/or coding conventions—for example, ensuring that each program variable is initialized before its first use and that pointers or references have been set to reasonable values before they are used. Modern compilers for object-oriented programming languages can detect many of the problems called out on traditional inspection checklists.

A review is an examination of software with the purpose of finding errors and faults even before the software is executed. Reviews are made in the context of the system being developed and have a deeper interest in the software than do inspections.

A review delves into the meaning of each part of a program and whether it is appropriate for meeting some or all of the application's requirements. A review is intended to uncover errors such as missed or misunderstood requirements or faults in a program's logic. Some reviews examine programming details such as whether variable names are well chosen and whether algorithms are as efficient as they could be.

Test execution is testing software in the context of a running program. Through executing the software, a tester tries to determine whether it has the required behavior by giving the program some input and verifying that the resulting output is correct. Among the challenges to testers are identifying suitable inputs, determining correct outputs, and determining how to observe the outputs.

The testing perspective is

Skeptical: Wants proof of quality.
Objective: Makes no assumptions.
Thorough: Doesn't miss important areas.
Systematic: Searches are reproducible.

Functions in c programming
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

Testability of a Software

In ideal circumstances, a software engineer designs a computer program, a system, or a product with “testability” in mind. This enables the individuals charged with testing to design effective test cases more easily. But what is testability? James Bach² describes testability in the following manner.

Software testability is simply how easily [a computer program] can be tested. Since testing is so profoundly difficult, it pays to know what can be done to streamline it. Sometimes programmers are willing to do things that will help the testing process and a checklist of possible design points, features, etc., can be useful in negotiating with them.

There are certainly metrics that could be used to measure testability in most of its aspects. Sometimes, testability is used to mean how adequately a particular set of tests will cover the product. It’s also used by the military to mean how easily a tool can be checked and repaired in the field. Those two meanings are not the same as software testability. The checklist that follows provides a set of characteristics that lead to testable software.

The paragraphs that follow are copyright 1994 by James Bach and have been adapted from an Internet posting that first appeared in the newsgroup comp.software-eng. This material is used with permission.

Operability. “The better it works, the more efficiently it can be tested.”

• The system has few bugs (bugs add analysis and reporting overhead to the test process).

• No bugs block the execution of tests.

• The product evolves in functional stages (allows simultaneous development and testing).

Observability. “What you see is what you test.”

• Distinct output is generated for each input.

• System states and variables are visible or queriable during execution.

• Past system states and variables are visible or queriable (e.g., transaction logs).

• All factors affecting the output are visible.

• Incorrect output is easily identified.

• Internal errors are automatically detected through self-testing mechanisms.

• Internal errors are automatically reported.

• Source code is accessible.

Controllability. “The better we can control the software, the more the testing can be automated and optimized.”

• All possible outputs can be generated through some combination of input.

• All code is executable through some combination of input.

• Software and hardware states and variables can be controlled directly by the test engineer.

• Input and output formats are consistent and structured.

• Tests can be conveniently specified, automated, and reproduced.

Decomposability. “By controlling the scope of testing, we can more quickly isolate problems and perform smarter retesting.”

• The software system is built from independent modules.

• Software modules can be tested independently.

Simplicity. “The less there is to test, the more quickly we can test it.”

• Functional simplicity (e.g., the feature set is the minimum necessary to meet requirements).

• Structural simplicity (e.g., architecture is modularized to limit the propagation of faults).

• Code simplicity (e.g., a coding standard is adopted for ease of inspection and maintenance).

Stability. “The fewer the changes, the fewer the disruptions to testing.”

• Changes to the software are infrequent.

• Changes to the software are controlled.

• Changes to the software do not invalidate existing tests.

• The software recovers well from failures.

Understandability. “The more information we have, the smarter we will test.”

• The design is well understood.

• Dependencies between internal, external, and shared components are well understood.

• Changes to the design are communicated.

• Technical documentation is instantly accessible.

• Technical documentation is well organized.

• Technical documentation is specific and detailed.

SOFTWARE TESTING FUNDAMENTALS

Testing presents an interesting anomaly for the software engineer. During earlier software engineering activities, the engineer attempts to build software from an abstract concept to a tangible product. Now comes testing.

The engineer creates a series of test cases that are intended to “demolish” the software that has been built. In fact testing is the one step in the software process that could be viewed (psychologically at least) as destructive rather than constructive.

Software engineers are by their nature constructive people. Testing requires that the developer discard preconceived notions of the “correctness” of software just developed and overcome a conflict of interest that occurs when errors are uncovered.

Beizer describes this situation effectively when he states:

There’s a myth that if we were really good at programming, there would be no bugs to catch If only we

could really concentrate, if only everyone used structured programming, top-down design, decision tables, if programs were written in SQUISH, if we had the right silver bullets, then there would be no bugs. So goes the myth. There are bugs, the myth says because we are bad at what we do; and if we are bad at it, we should feel guilty about it. Therefore, testing and test case design is an admission of failure, which instills a goodly dose of guilt.

Testing Objectives

What are primary objectives when we test software?

In an excellent book on software testing, Glen Myers states a number of rules that can serve well as testing objectives:

1. Testing is a process of executing a program with the intent of error.

2. A good test case is one that has a high probability of finding an as-yet-undiscovered error.

3. A successful test is one that uncovers an as-yet-undiscovered error.

These objectives imply a dramatic change in viewpoint. They move counter to the commonly held view that a successful test is one in which no errors are found. Our objective is to design tests that systematically uncover different classes of errors and to do so with a minimum amount of time and effort.

If testing is conducted successfully (according to the objectives stated previously), it will uncover errors in the software. As a secondary benefit, testing demonstrates that software functions appear to be working according to specification, that behavioral and performance requirements appear to have been met.

In addition, data collected as testing is conducted provide a good indication of software reliability and some indication of software quality as a whole. But testing cannot show the absence of errors,, it can show only that software errors and defects are present. It is important to keep this (rather gloomy) statement in mind as testing is being conducted.

Testing Principles

Before applying methods to design effective test cases, a software engineer must understand the basic principles that guide software testing. Davis suggests a set of testing principles that have been adapted for use in this book:

• All tests should be traceable to customer requirements.

• Tests should be planned long before testing begins.

Test planning can begin as soon as the requirements model is complete. Detailed definition of test cases can begin as soon as the design model has been solidified. Therefore, all tests can be planned and designed before any code has been generated.

• The Pareto principle applies to software testing.

Stated simply, the Pareto principle implies that 80 percent of all errors uncovered during testing will likely be traceable to 20 percent of all program components. The problem, of course, is to isolate these suspect components and to thoroughly test them.

• Testing should begin “in the small” and progress toward testing “in the large.”

The first tests planned and executed generally focus on individual components. As testing progresses, focus shifts in an attempt to find errors in integrated clusters of components and ultimately in the entire system .

• Exhaustive testing is not possible.

The number of path permutations for even a moderately sized program is exceptionally large . For this reason, it is impossible to execute every combination of paths during testing. It is possible, however, to adequately cover program logic and to ensure that all conditions in the component-level design have been exercised.

• To be most effective, testing should be conducted by an independent third party.

By most effective, we mean testing that has the highest probability of finding errors (the primary objective of testing).

ERROR CHECK LIST FOR INSPECTIONS

WALK THROUGHS IN TESTING

TESTING FOR SPECIALIZED ENVIRONMENTS PART ONE

TESTING FOR SPECIALIZED ENVIRONMENTS PART TWO

VALIDATION TESTING

SYSTEM TESTING

DEBUGGING AND TESTING

DEFECT AMPLIFICATION AND REMOVAL

ITERATIVE SPIRAL MODEL

STANDARD WATER MODEL

CONFIGURATION MANAGEMENT

CONTROLLED TESTING ENVIRONMENT

RISK ANALYSIS PART ONE

RISK ANALYSIS PART TWO

BACK GROUND ISSUES

SOFTWARE REVIEWS PART ONE

SOFTWARE REVIEWS PART TWO

SOFTWARE RELIABILITY

SAFETY ASPECTS

MISTAKE PROOFING

SCRIPT ENVIRONMENT

V MODEL IN TESTING

SOFTWARE TESTING TECHNIQUES INTRODUCTION

The importance of software testing and its implications with respect to software quality cannot be overemphasized.

The development of software systems involves a series of production activities where opportunities for injection of human fallibilities are enormous. Erros may begin to occur at the very inception of the process where the objectives... may be erroneously or imperfectly specified, as well as [in] later design and development stages . . . Because of human inability to perform and communicate with perfection, software development is accompanied by a quality assurance activity.

Software testing is a critical element of software quality assurance and represents the ultimate review of specification, design, and code generation.

The increasing visibility of software as a system element and the attendant “costs” associated with a software failure are motivating forces for well-planned, thorough testing. It is not unusual for a software development organization to expend between 30 and 40 percent of total project effort on testing. In the extreme, testing of human-rated software (e.g., flight control, nuclear reactor monitoring) can cost three to five times as much as all other software engineering steps combined!

QUICK LOOK

What is it?

Once source code has been generated, software must be tested to uncover (and correct) as many errors as possible before delivery to your customer. Your goal is to design a series of test cases that have a high likelihood of finding errors-but how?

That’s where software testing techniques enter the picture. These techniques provide systematic guidance for designing tests that

1) exercise the internal logic of software components, and

(2) exercise the input and output domains of the program to uncover errors in program function, behavior, and performance.

Who does it?

During early stages of testing, a software engineer performs all tests. However, as the testing progresses, testing specialists may become involved.

Why is it important?

Reviews and other SQA activities can and do uncover errors, but they are not sufficient. Every time the program is executed, the customer tests it! Therefore, you have to execute the program before it gets to the customer with the specific intent of finding and removing all errors. In order to find the highest possible number of erros, tests must be conducted systematically and test cases must be designed using disciplined techniques.

What are the steps?

Software is tested from two different perspectives: (1) internal program logic is exercised using “white box” test case design techniques. Software requirements are exercised using “black box” test case design techniques .In both cases, the intent is to find the maximum number of errors with the minimum amount of effort and time.

What is the work product?

A set of test cases designed to exercise both internal logic and external requirements is designed and documented, expected restarts are defined, and actual results are recorded.

How do I ensure that I’ve done it right?

When you begin testing, change your point of view. Try hard to “break” the software! Design test cases in a disciplined fashion and review the test cases you do create for thoroughness.

Introduction to Software Testing

Software testing is a critical element of software quality assurance and represents the ultimate process to ensure the correctness of the product. The quality product always enhances the customer confidence is using the product thereby increases the business economics. In other words, a good quality product means zero defects, which is derived from a better quality process in testing.

The definition of testing is not well understood. People use a totally incorrect definition of the word testing, and that this is the primary cause for poor program testing. Examples of these definitions are such statements as “Testing is the process of demonstrating that errors are not present”, “The purpose of testing is to show that a program performs its intended functions correctly”, and “Testing is the process of establishing confidence that a program does what is supposed to do”.

Testing the product means adding value to it that means raising the quality or reliability of the program. Raising the reliability of the product means finding and removing errors. Hence one should not test a product to show that it works; rather, one should start with the assumption that the program contains errors and then test the program to find as many of the errors as possible. Thus a more appropriate definition is:

Testing is the process of executing a program with the intent of finding errors.

What is the purpose of Testing?

To show the software works: It is know as demonstration-oriented
To show the software doesn’t work:
It is known as destruction-oriented
To minimize the risk of not working up to an acceptable level:
It is known as evaluation-oriented

Why do we need to Test?

Defects can exist in the software, as it is developed by human who can make mistakes during the development of software. However, it is the primary duty of a software vendor to ensure that software delivered does not have defects and the customers day-to-day operations do not get affected. This can be achieved by rigorously testing the software. The most common origin of software bugs is due to:

Poor understanding and incomplete requirements
Unrealistic schedule
Fast changes in requirements
Too many assumptions and complacency

What is Testing?

“Testing is an activity in which a system or component is executed under specified conditions; the results are observed and recorded and an evaluation is made of some aspect of the system or component
“ - IEEE
Executing a system or component is known as dynamic testing.
Review, inspection and verification of documents (Requirements, design documents Test plans etc.), code and other work products of software is known as static testing.
Static testing is found to be the most effective and efficient way of testing.
Successful testing of software demands both dynamic and static testing.
Measurements show that a defect discovered during design that costs $1 to rectify at that stage will cost $1,000 to repair in production. This clearly points out the advantage of early testing.
Testing should start with small measurable units of code, gradually progress towards testing integrated components of the applications and finally be completed with testing at the application level.
Testing verifies the system against its stated and implied requirements, i.e., is it doing what it is supposed to do? It should also check if the system is not doing what it is not supposed to do, if it takes care of boundary conditions, how the system performs in production-like environment and how fast and consistently the system responds when the data volumes are high.

Software Testing Fundamentals part two

Testing in itself cannot ensure the quality of software. All testing can do is give you a certain level of assurance (confidence) in the software. On its own, the only thing that testing proves is that under specific controlled conditions, the software functioned as expected by the test cases executed.

difference between QA and testing:

TESTING means “Quality Control”; and

QUALITY CONTROL measures the quality of a product; while

QUALITY ASSURANCE measures the quality of processes used to create a quality product.

The Mission of Testing:

In well-run projects, the mission of the test team is not merely to perform testing, but to help minimize the risk of product failure. Testers look for manifest problems in the product, potential problems, and the absence of problems. They explore, assess, track, and report product quality, so that others in the project can make informed decisions about product development. It's important to recognize that testers are not out to "break the code." We are not out to embarrass or complain, just to inform. We are human meters of product quality.

The test policy characterises the organisation’s philosophy towards software testing. This would incorporate statements to ensure compliance with standards such as ISO 9001, ISO 12207 and IEEE 730. ISO 9001 provides only a very high level requirement that suppliers perform testing as part of verification and document it. At this level ISO 12207 defines the requirement for specific verification and validation processes to support the primary processes of development, maintenance, etc.

IEEE 730 requires the production of both a Software Verification and Validation Plan (and corresponding Report) and the documentation of any other tests (presumably those performed by the developers), but appears to be superfluous, from a testing point of view, if ISO 9001 and ISO 12207 are used.

A Testing Policy is management’s definition of testing a department. A Testing Policy involves the following criteria.

1)Definition of Testing

2) Testing System

3) Evaluation

4) Standards

Software Testing Fundamentals

Determine whether the system meets specifications (producer view).

Determine whether the system meets business and user needs (customer view).

Test Objectives:

1. Testing is a process of executing a program with the intent of finding an error.

2. A good test case is one that has a high probability of finding an as-yet-undiscovered error.

3. A successful test is one that uncovers an as-yet-undiscovered error.

Testing Principals:

The following can be described as testing principals:

All tests should be traceable to customer requirements.
Tests should be planned long before testing begins.
The Pareto principal applies to testing.
Testing should begin “in small” and progress toward testing “in large”.
Exhaustive testing is not possible.
To be most effective, an independent third party should conduct testing.

What is Defect?

The purpose of testing is to find defects. A defect is a variance from a desired product attribute. Two categories of defects are

Variance from product specifications:

The product built varies from the product specified. For example, the specifications may say that x is to be added to y to produce z. If the algorithm in the built Varies from that specification, it is considered to be defective.

Variance from customer/user expectation:

This variance is something that the user wanted that in the built product, but also was not specified to be included in the built product. The missing piece may be a specification or requirement, or the method by which the requirement was implemented may be unsatisfactory.

What is Software Testing?

Software testing is more than just error detection;

Testing software is operating the software under controlled conditions, to

(1) verify that it behaves “as specified”;

(2) to detect errors, and

(3) to validate that what has been specified is what the user actually wanted.

Verification is the checking or testing of items, including software, for conformance and consistency by evaluating the results against pre-specified requirements. [Verification: Are we building the system right?]

Error Detection: Testing should intentionally attempt to make things go wrong to determine if things happen when they shouldn’t or things don’t happen when they should.

Validation looks at the system correctness – i.e. is the process of checking that what has been specified is what the user actually wanted. [Validation: Are we building the right system?]

In other words, validation checks to see if we are building what the customer wants/needs, and verification checks to see if we are building that system correctly. Both verification and validation are necessary, but different components of any testing activity.

The definition of testing according to the ANSI/IEEE 1059 standard is that testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is defects/errors/bugs) and to evaluate the features of the software item.

Remember: The purpose of testing is verification, validation and error detection in order to find problems – and the purpose of finding those problems is to get them fixed.

RELATED POST

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

Quality management in testing

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

Testing is a process of dynamically executing software after it is completed.

Quality Control involves the series of inspections, reviews, and tests used throughout the software process to ensure each work product meets the requirements placed upon it.

Quality Assurance consists of the auditing and reporting functions of management.

Quality Factors

We can define software quality in several ways that could, ideally, all tie together. Here are those ways:

Satisfaction level - the degree to which a software product meets a user's needs and expectations.
A software product's value relative to its various stakeholders and its competition.
The extent to which a software product exhibits desired properties.
The degree to which a software product works correctly in the environment it was designed for, without deviating from expected behavior.
The effectiveness and correctness of the process employed in developing the software product.

The Cost of Quality

Does quality cost us anything and if so what? And how does that compare to the cost of not having quality? These are heady topics, indeed, for any organization that wants to produce satisfactory products and yet still keep a handle on things reduced development times and more dynamic release cycles of products.

There is some confusion about the business value of quality even outside the software development context. On the one hand, there are those who believe that it is economical to maximize quality.

Experiences in manufacturing fields relating to the cost and return-on-investment of quality improvements seems to suggest that there are diminishing returns to quality expenditures after a certain point.

However, quality improvements can often result in quantifiable cost savings that outweigh the funds actually spent on the quality efforts. Regardless of which side of the fence you sit on, a main focus in qualitly management is how to make profitable decisions on quality expenditures.

This problem is particularly salient in software development due to limited empirical evidence on the economics of software quality. So the key is to focus on evaluating the cost of quality and return on quality. This usually requires metrics and in terms of software engineering economics context and beyond the scope of this general overview.

The cost of quality falls into three broad categories: prevention, appraisal, and failure. Prevention costs involve investments aimed at getting work done right the first time and preventing quality problems from ever coming up, at least insofar as possible.

Examples include training, new techniques and tools, methodologies, etc. This is a proactive approach that commends itself to defect prevention rather than defect correction and removes the idea of quality efforts essentially being reactive in efforts to "put out fires."

Appraisal costs involve all of the testing and control efforts to measure whether needed quality has been achieved to some predefined level. Failure costs are those incurred by the need to fix and recover from the quality problems that do arise. One of the aims of a Quality Assurance department is to measure these collective quality costs on an ongoing basis.

(8.2)

RELATED POST

recent major computer system failures caused by software bugs

In August of 2003 a U.S. court ruled that a lawsuit against a large online brokerage company could proceed; the lawsuit reportedly involved claims that the company was not fixing system problems that sometimes resulted in failed stock trades, based on the experiences of 4 plaintiffs during an 8-month period. A previous lower court's ruling that "...six miscues out of more than 400 trades does not indicate negligence." was invalidated.

In April of 2003 it was announced that the largest student loan company in the U.S. made a software error in calculating the monthly payments on 800,000 loans. Although borrowers were to be notified of an increase in their required payments, the company will still reportedly lose $8 million in interest. The error was uncovered when borrowers began reporting inconsistencies in their bills.
News reports in February of 2003 revealed that the U.S. Treasury Department mailed 50,000 Social Security checks without any beneficiary names. A spokesperson indicated that the missing names were due to an error in a software change. Replacement checks were subsequently mailed out with the problem corrected, and recipients were then able to cash their Social Security checks.
In March of 2002 it was reported that software bugs in Britain's national tax system resulted in more than 100,000 erroneous tax overcharges. The problem was partly attibuted to the difficulty of testing the integration of multiple systems.
A newspaper columnist reported in July 2001 that a serious flaw was found in off-the-shelf software that had long been used in systems for tracking certain U.S. nuclear materials. The same software had been recently donated to another country to be used in tracking their own nuclear materials, and it was not until scientists in that country discovered the problem, and shared the information, that U.S. officials became aware of the problems.
According to newspaper stories in mid-2001, a major systems development contractor was fired and sued over problems with a large retirement plan management system. According to the reports, the client claimed that system deliveries were late, the software had excessive defects, and it caused other systems to crash.

In January of 2001 newspapers reported that a major European railroad was hit by the aftereffects of the Y2K bug. The company found that many of their newer trains would not run due to their inability to recognize the date '31/12/2000'; the trains were started by altering the control system's date settings.

News reports in September of 2000 told of a software vendor settling a lawsuit with a large mortgage lender; the vendor had reportedly delivered an online mortgage processing system that did not meet specifications, was delivered late, and didn't work.

In early 2000, major problems were reported with a new computer system in a large suburban U.S. public school district with 100,000+ students; problems included 10,000 erroneous report cards and students left stranded by failed class registration systems; the district's CIO was fired. The school district decided to reinstate it's original 25-year old system for at least a year until the bugs were worked out of the new system by the software vendors.
In October of 1999 the $125 million NASA Mars Climate Orbiter spacecraft was believed to be lost in space due to a simple data conversion error. It was determined that spacecraft software used certain data in English units that should have been in metric units. Among other tasks, the orbiter was to serve as a communications relay for the Mars Polar Lander mission, which failed for unknown reasons in December 1999. Several investigating panels were convened to determine the process failures that allowed the error to go undetected.
Bugs in software supporting a large commercial high-speed data network affected 70,000 business customers over a period of 8 days in August of 1999. Among those affected was the electronic trading system of the largest U.S. futures exchange, which was shut down for most of a week as a result of the outages.
In April of 1999 a software bug caused the failure of a $1.2 billion U.S. military satellite launch, the costliest unmanned accident in the history of Cape Canaveral launches. The failure was the latest in a string of launch failures, triggering a complete military and industry review of U.S. space launch programs, including software integration and testing processes. Congressional oversight hearings were requested.

A small town in Illinois in the U.S. received an unusually large monthly electric bill of $7 million in March of 1999. This was about 700 times larger than its normal bill. It turned out to be due to bugs in new software that had been purchased by the local power company to deal with Y2K software issues.

In early 1999 a major computer game company recalled all copies of a popular new product due to software problems. The company made a public apology for releasing a product before it was ready.
The computer system of a major online U.S. stock trading service failed during trading hours several times over a period of days in February of 1999 according to nationwide news reports. The problem was reportedly due to bugs in a software upgrade intended to speed online trade confirmations.
In April of 1998 a major U.S. data communications network failed for 24 hours, crippling a large part of some U.S. credit card transaction authorization systems as well as other large U.S. bank, retail, and government data systems. The cause was eventually traced to a software bug.

January 1998 news reports told of software problems at a major U.S. telecommunications company that resulted in no charges for long

distance calls for a month for 400,000 customers. The problem went undetected until customers called up with questions about their bills.
In November of 1997 the stock of a major health industry company dropped 60% due to reports of failures in computer billing systems, problems with a large database conversion, and inadequate software testing. It was reported that more than $100,000,000 in receivables had to be written off and that multi-million dollar fines were levied on the company by government agencies.
A retail store chain filed suit in August of 1997 against a transaction processing system vendor (not a credit card company) due to the software's inability to handle credit cards with year 2000 expiration dates.
In August of 1997 one of the leading consumer credit reporting companies reportedly shut down their new public web site after less than two days of operation due to software problems. The new site allowed web site visitors instant access, for a small fee, to their personal credit reports. However, a number of initial users ended up viewing each others' reports instead of their own, resulting in irate customers and nationwide publicity. The problem was attributed to "...unexpectedly high demand from consumers and faulty software that routed the files to the wrong computers."
In November of 1996, newspapers reported that software bugs caused the 411 telephone information system of one of the U.S. RBOC's to fail for most of a day. Most of the 2000 operators had to search through phone books instead of using their 13,000,000-listing database. The bugs were introduced by new software modifications and the problem software had been installed on both the production and backup systems. A spokesman for the software vendor reportedly stated that 'It had nothing to do with the integrity of the software. It was human error.'
On June 4 1996 the first flight of the European Space Agency's new Ariane 5 rocket failed shortly after launching, resulting in an estimated uninsured loss of a half billion dollars. It was reportedly due to the lack of exception handling of a floating-point error in a conversion from a 64-bit integer to a 16-bit signed integer.

Software bugs caused the bank accounts of 823 customers of a major U.S. bank to be credited with $924,844,208.32 each in May of 1996, according to newspaper reports. The American Bankers Association claimed it was the largest such error in banking history. A bank spokesman said the programming errors were corrected and all funds were recovered.

Software bugs in a Soviet early-warning monitoring system nearly brought on nuclear war in 1983, according to news reports in early 1999. The software was supposed to filter out false missile detections caused by Soviet satellites picking up sunlight reflections off cloud-tops, but failed to do so. Disaster was averted when a Soviet commander, based on a what he said was a '...funny feeling in my gut', decided the apparent missile attack was a false alarm. The filtering software code was rewritten.

Read more about software testing here at wikepedia.

Programming Portal

Top Tabs