This document provides an overview of software testing fundamentals. It defines testing as executing software to find bugs and discusses why testing is necessary to ensure quality. It also covers causes of defects, different levels of testing from unit to acceptance, testing principles, and sample entry and exit criteria for different test stages. The goal of testing is to validate software meets requirements and works as expected while improving quality through the identification and fixing of defects.

1. FUNDAMENTALS OF TESTING

2. TABLE OF CONTENT
FUNDAMENTALS OF TESTING
 1.1 What is Testing?
 1.2 Why is Testing necessary
 1.3 Causes of Software Defects
 1.4 Testing and Quality
 1.5 How Much Testing is Enough?
 1.6 Testing Principles
 1.7 Fundamental Test Process
 1.8 Levels of Testing

3. 1. FUNDAMENTALS OF TESTING
Learning Objectives for Fundamentals of Testing
 The objectives identify what you will be able to do following the completion of
each module.

4. 1.1 WHAT IS TESTING?
 Software testing is a process of executing a software/application with the
intend of finding bugs.
 Software testing can be stated as the process of validating and verifying that
a software program/application/product:
 meets the requirements that guided its design and development;
 works as expected; and
 can be implemented with the same characteristics.

5. 1.2 Why is Testing necessary
Testing is necessary because we all make mistakes. Some of those mistakes are
unimportant, but some of them are expensive and dangerous. We need to check
everything and anything we produce because things can always go wrong –
humans makes mistakes all the time – it is what we do best!

6. 1.3 Causes of Software Defects
 A human being can make an error (mistake), which produces a defect (fault,
bug) in the program code, or in a document. If a defect in code is executed,
the system may fail to do what it should do (or do something it shouldn’t),
causing a failure. Defects in software, systems or documents may result in
failures, but not all defects do so.
 Defects occur because human beings are fallible and because there is time
pressure, complex code, complexity of infrastructure, changing technologies,
and/or many system interactions.
 Failures can be caused by environmental conditions as well. For example,
radiation, magnetism, electronic fields, and pollution can cause faults in
firmware or influence the execution of software by changing the hardware
conditions.

7. 1.4 Testing and Quality
 With the help of testing, it is possible to measure the quality of software in
terms of defects found, for both functional and non-functional software
requirements and characteristics (e.g., reliability, usability, efficiency,
maintainability and portability).
 Testing can give confidence in the quality of the software if it finds few or no
defects. A properly designed test that passes reduces the overall level of risk
in a system. When testing does find defects, the quality of the software
system increases when those defects are fixed.
 Lessons should be learned from previous projects. By understanding the root
causes of defects found in other projects, processes can be improved, which
in turn should prevent those defects from reoccurring and, as a consequence,
improve the quality of future systems. This is an aspect of quality assurance.

8. 1.5 How Much Testing is Enough?
 We’ve seen that testing helps us find defects and improve software quality.
How much testing should we do? We have a choice: test everything, test
nothing or test some of the software. Now, your immediate response to that
may well be to say, ‘Everything must be tested’. We don’t want to use
software that has not been completely tested, do we? This implies that we
must exercise every aspect of a software system during testing. What we
need to consider is whether we must, or even can, test completely.
 Let’s look at how much testing we’d need to do to be able to test
exhaustively. How much tests would you need to do to completely test a
one-digit numeric field? The immediate question is, ‘What you mean by
test completely?’. There are 10 possible valid numeric values but as well
as the valid values we need to ensure that all the invalid values are
rejected. There are 26 upper alpha character, 26 lower case, at least 6
special and punctuation characters as well as a blank value. So there
would be at least 68 tests for this example of a one digit field.

9. CONT…
 Deciding how much testing is enough should take account of the level of
risk, including technical, safety, and business risks, and project
constraints such as time and budget.
 Testing should provide sufficient information to stakeholders to make
informed decisions about the release of the software or system being
tested, for the next development step or handover to customers.

10. 1.6 TESTING PRINCIPLES
 Principle 1 – Testing shows presence of defects
 Principle 2 – Exhaustive testing is impossible
 Principle 3 – Independent Testing
 Principle 4 – Pesticide paradox
 Principle 5 – Testing is context dependent
 Principle 6 – Absence-of-errors fallacy

11. 1.7 FUNDAMENTAL TEST PROCESS
The fundamental test process consists of the following main activities:
Test planning and control
Test analysis and design
Test implementation and
execution
Evaluating exit criteria and
reporting
Test closure activities

12. 1.8 LEVELS OF TESTING
 Unit Testing
 System Testing
 Integration Testing
 User Acceptance Testing
Sample Entry and Exit Criteria for Unit Testing
Entry Criteria
♦ Business Requirements are at least 80% complete and have been approved to-date
♦ Technical Design has been finalized and approved
♦ Development environment has been established and is stable
♦ Code development for the module is complete
Exit Criteria
♦ Code has version control in place
♦ No known major or critical defects prevents any modules from moving to System
Testing
♦ A testing transition meeting has be held and the developers signed off
♦ Project Manager approval has been received

13. CONT…
Sample Entry and Exit Criteria for System Testing
Entry Criteria
♦ Unit Testing for each module has been completed and approved;
each module is under version control
♦ An incident tracking plan has been approved
♦ A system testing environment has been established
♦ The system testing schedule is approved and in place
Exit Criteria
♦ Application meets all documented business and functional requirements
♦ No known critical defects prevent moving to the Integration Testing
♦ All appropriate parties have approved the completed tests
♦ A testing transition meeting has be held and the developers signed off

14. CONT…
Sample Entry and Exit Criteria for Integration Testing
Entry Criteria
♦ System testing has been completed and signed off
♦ Outstanding issues and defects have been identified and documented
♦ Test scripts and schedule are ready
♦ The integration testing environment is established
Exit Criteria
♦ All systems involved passed integration testing and meet agreed upon functionality and
performance requirements
♦ Outstanding defects have been identified, documented, and presented to the business
sponsor
♦ Stress, performance, and load tests have been satisfactorily conducted
♦ The implementation plan is final draft stage
♦ A testing transition meeting has been held and everyone has signed off

15. CONT…
Sample Entry and Exit Criteria for User Acceptance Testing
Entry Criteria
♦ Integration testing signoff was obtained
♦ Business requirements have been met or renegotiated with the Business Sponsor or
representative
♦ UAT test scripts are ready for execution
♦ The testing environment is established
♦ Security requirements have been documented and necessary user access obtained
Exit Criteria
♦ UAT has been completed and approved by the user community in a transition meeting
♦ Change control is managing requested modifications and enhancements
♦ Business sponsor agrees that known defects do not impact a production release—no
remaining defects are rated 3, 2, or 1

16. THANKS