Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Fundamentals of testing


Published on

Software testing is a process of executing a software/application with the intend of finding bugs.

Published in: Software
  • Login to see the comments

  • Be the first to like this

Fundamentals of testing

  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16. THANKS