The document discusses the fundamentals of software testing, detailing its necessity, types, and the consequences of defects in software products, illustrated with real-world examples of disasters caused by software faults. It highlights the importance of testing in identifying defects, ensuring quality, and meeting customer requirements, as well as the various methods and terminology associated with the field. Additionally, it emphasizes the role of testers and the limits of testing, underlining that while testing cannot guarantee complete quality, it is essential for finding and fixing issues.

1. Testing Basics

2. Learning Objectives
 What Testing is
 Why it is needed
 Basic terms to be Known
 Cost of Testing
 Need of Domain Knowledge
 Need of Static Testing
 Need of White Box Testing
 Need of Black Box Testing
 What Static / WB / BB Reveal and
 Why they are Complementary

3. INTRODUCTION TO TESTING
Software products are integral part of our lives. We cannot
imagine doing without them. They are used in Banks,
Telecom, Retail, Hospitals etc .However if defects are
encountered in them they can lead loss of money, time,
business reputation and can even result in injury or death.
Some of the Major disasters seen due to defects in software
are:
Disaster: Canada’s radiation therapy machine malfunctioned
and delivered lethal radiation doses to patients. Three people
Therac-25 died and three were critically injured due to it.
Cause: Due to race condition defect, a technician could
accidentally configure Therac-25 so the electron beam would
fire in high-power mode without the proper patient shielding

4. INTRODUCTION TO TESTING
Disaster: Businesses spent billions on programmers to fix Y2K bug.
Cause: To save computer storage space, legacy software often stored
the year for dates as two digit numbers, such as “99″ for 1999. The
software also interpreted “00″ to mean 1900 rather than 2000, so when
the year 2000 came along, bugs would result.
Cost: $475 million, corporate credibility
Disaster: Intel’s Pentium chip occasionally made mistakes when
dividing floating-point numbers within a specific range. For example,
dividing 4195835.0/3145727.0 yielded 1.33374 instead of 1.33382, an
error of 0.006. Intel replaced the chips for anyone who complained. It cost
them $475 million, corporate credibility.
Cause: The divider in the Pentium floating point unit had a flawed
division table, missing about five of a thousand entries and resulting in
these rounding errors.

5. WHY DO DEFECTS OCCUR?
Incorrect and incomplete and misunderstood specification.
Defects occur because human beings have tendency to
make mistakes.
Due to time pressure programmers don’t get enough time to
check their code.
Some of the tasks are inherently complex.
Failures are also caused by environmental conditions such
as: radiation, magnetism, electronic fields
Faults in firmware can influence execution of software.
Changing requirements/Late design changes result in
change of code which is bound to have defects.
When one programmer tries to change another
programmer’s code, errors occur due to miscommunication.

6. Cost of Defects:
Defect detected and corrected in earlier and same phase will cost
less as compared to defect detected and corrected in latter stages.
Problem amplifies as it percolates to the later stages.
The costs are Logarithmic that is it increases ten folds as the time
increases.

7. INTRODUCTION TO TESTING
What is testing?
Have you done testing before?

8. NEED OF TESTING?
 Find defects.
 Access quality of the product.
 Build confidence in product.
 Certify to standards.
 Meet customer’s requirements.
 Minimize time and cost
 Find scenarios for smooth working of software inspite of
defects.
 Avoid being sued by customer.

9. SOME TERMS AND TERMINOLOGIES
RELATED TO SOFTWARE TESTING:
Testing and Debugging.
QA and QC.
Product and Project.
Error, Defect (Bug) and Failure.

10. TESTING AND DEBUGGING.
Testing:
Testing is done to find defects in the software.
Debugging:
Debugging is done to find, analyse and remove causes of failure in
software.

11. QA AND QC.
Quality Assurance:
A planned and systematic set of activities necessary to
provide adequate confidence that requirements are
properly established and products or services conform to
specified requirements.
Quality Control:
The process by which product quality is compared with
applicable standards; and the action taken when non-
conformance is detected.

12. Difference between Product and Project.
Product (COTS):
Software made for general market e.g. Windows, Adobe products.
Project:
Software made for specific customer.

13. Definition
Error (Mistake):
A human action that produces an incorrect result.
Defect (Bug, Fault):
A flaw in a component or system that can cause the component
or system to fail to perform its required function. e.g. an incorrect
statement or data definition. A defect, if encountered during
execution, may cause a failure of the component or system.
Failure:
Deviation of the component of the system from its expected
delivery, services or result.
-Fo undatio n o f So ftware te sting

14. TYPES OF TESTING
 Manual and Automation testing.
 Static and Dynamic testing.
 Black and White box testing.
 Retesting and Regression testing.
 Functional and Non-Functional testing.
 Exhausting testing.

15. Manual and Automation
testing
Manual testing:
Testing that requires human input and analysis.
Automation testing:
Testing software with aid tool (software used for testing) e.g. of
tools are QTP, Load runner etc.

16. Black Box and White Box Testing
Black Box/Behavioral testing/I/O driven:
Testing the software without knowing the internal working of the
software.
White Box/Clear Box/Structural Testing/code driven
testing:
Testing the internal structure of the software (Unit) .
It is also known as Code driven testing.

17. Retesting and Regression Testing
Retesting:
Rerunning of tests that failed earlier in order to verify the success
of corrective action.
Regression testing:
Testing of the previously tested program following modification to
ensure that defects have not been introduced in the unchanged
areas of software due to the changes made.

18. Static and Dynamic testing
Static testing:
Testing software without executing/running it.
Dynamic testing:
Testing software by executing/running it.

19. Functional and Non-Functional Testing
Functional Testing:
Testing the functionality of a component or system based on the
specification.
Non-Functional Testing:
Testing attributes of the component or system apart from
functionality.
e.g. performance, usability, maintainability, portability

20. Exhaustive testing
Testing with combination of all input values and
preconditions.

21. Characteristics of a Good Tester.
 They are explorers.
 They are troubleshooters.
 They are relentless.
 They are creative.
 They are (mellowed) perfectionists.
 They exercise good judgment.
 They are tactful and diplomatic.
 They are persuasive.

22. What good testers do?
 Desired results from planned efforts
 Being productive without waste
 Being in the right context
 Channelizing the testing efforts
 Being creative and smart
 Thought process with a difference

23. How to achieve it?
 Goals for testing activities:
 Knowing the quality and Risk of the system we are
testing.
 Enough information to concerned stakeholders like
developers etc.
 Help management understand system quality
 Project subjective goals team wants to achieve?

24. How good testers work
 Keeping information about the most
important aspects of overall system
 Provide developers the information which
help them complete tasks efficiently
 Help Management understand the
concepts of Testing and Quality

25. What Is the Right Level of Efficiency?
Cconformance = Testing (Finding Bugs) + QA
(Preventing Bugs)
Cnonconformance = Fixing Bugs+Retesting+Customer
dissatisfaction+ Lost bussiness etc.
Cquality= Cconformance + Cnonconformance

26. Role of the Tester
 Lessons learned in S/W testing-Kaner
 Tester is headlight of a project
 Mission drives everything tester do
 Tester serves many clients (like manager, developer, user
etc.)
 Find important bugs fast
 Run with the programmers
 Question everything, but not necessarily loud.
 Focus on failures. You will not find all bugs.
 Beware of testing “Completely”

27. Role of the Tester
 Lessons learned in S/W testing-Kaner
 You don’t assure quality by testing
 Never be a gatekeeper
 Beware of the not-my-job theory of testing
 Don’t expect anyone to understand testing.
 You focus on failures so that client can focus on success.
 Always remember Good Testers think technically,
creatively, critically and practically.

28. Limits of testing
 You cannot test a program completely
 The domain of possible inputs is too large to test
 There are too many possible paths
 The UI issues are too complex to test
 You cannot find every design error
 You can’t prove programs correct using logic
 You have to check that the system is good enough
 Good enough means an acceptable level of quality problems
and risks remain

29. So Why Test?
 The Purpose of Testing a program is to find problems
in it.
 The purpose of finding problems is to get them fixed.
 Always remember-A test that reveals a problem is a
success. A test that did not reveal a problem was a
waste of time.

30. What Does “Quality” Mean to You?
 A definition from J. M. Juran:
Fitness for use. Features [that] are decisive as to product
performance and as to ‘product satisfaction’…. The word
‘quality’ also refers to freedom from deficiencies…[that]
result in complaints, claims, returns, rework and other
damage. Those collectively are forms of ‘product
dissatisfaction.’
 Fitness for use by who m ?
 Testing looks for the presence or absence of
deficiencies
 What happens when Quality is lacking.