The History of Software Testing
- 1. The History of Software Testing
- 2. The History of Software Testing DEBAGGING testing was often associated to debugging: there was no clear difference between testing and debugging … - 1956 DEMONSTRATION in this period it was shown, that software satisfies the requirements 1957 - 1978 DESTRUCTION the goal was to find errors 1979 - 1982 EVALUATION during the software lifecycle a product evaluation is provided and measuring quality 1983 - 1987 PREVENTION to prevent faults in requirements, design, and implementation 1988 - ...
- 3. The History of Software Testing DEBAGGING testing was often associated to debugging: there was no clear difference between testing and debugging … - 1956
- 4. Falsifiability (Popper) Theory can only be considered scientific if an experiment can be conducted that can falsify the theory. 1934 The Fisrt Computer (Analytical Engine, built by Babbage) It was created to calculate a series of values automatically. 1837 The Fisrt Programmer (Ada Lovelace) Published the first algorithm for Babbage’s Analyticall Engine. 1843 The Fisrt Using the Term ‘Bug’ Thomas Edison: “..."Bugs" - as such little faults and difficulties are called… ” 1878 THE DEBAGGING - ORIENTED PERIOD The Fisrt Documented Computer Bug 1946 Juran's Quality Control Handbook Three processes for the management of quality: quality planning, quality control and quality improvement. 1951 The Fisrt High-level Programming Language (FORTRAN) 1954
- 5. The History of Software Testing DEMONSTRATION in this period it was shown, that software satisfies the requirements 1957 - 1978
- 6. Cost-of-change curve (Boehm) The curve essentially shows that the cost of changing the software (fixing a software defect) rises exponentially in time. 1976 First software test team (Project Mercury) 1958 Testing shows the presence, not the absence of bugs Edsger Dijkstra, conference by the NATO Science Committee, Rome, Italy 1969 Decision table Burton Grad, working at IBM, introduces decision tables. 1969 THE DEMONSTRATION - ORIENTED PERIOD State transition testing Tsun S. Chow introduces testing techniques for state transition testing. 1976
- 7. The History of Software Testing DESTRUCTION the goal was to find errors 1979 - 1982
- 8. The First Computer Graphic Disney movie, Tron is a hybrid form between actors and overplayed graphics. The Art of Software Testing The book by Glenford Myers is the first book about software testing only. It introduces black box testing. 1979 Space Invaders and Pacman Were Introduced THE DESTRUCTION - ORIENTED PERIOD IBM Personal Computer Goes Mass Market The IBM-PC or IBM 5150 set the standard for mass market computer products. 1982 1981 1979
- 9. The History of Software Testing EVALUATION during the software lifecycle a product evaluation is provided and measuring quality 1983 - 1987
- 10. Use cases In his paper Object Oriented Development in an Industrial Environment Ivar Jacobson introduces the concept of use cases and use case modeling for the customer requirements. 1987 First testing industry conference The US Professional Development Institute. 1984 The first domain name is registered Symbolics.com becomes the first registered domain. 1985 Windows 1.0 released 1985 THE EVALUATION - ORIENTED PERIOD
- 11. The History of Software Testing PREVENTION to prevent faults in requirements, design, and implementation 1988 - ...
- 12. Pesticide paradox In the second edition of Software Testing Techniques Boris Beizer coins the term pesticide paradox to describe the phenomenon that the more you test software, the more immune it becomes to your tests. Exploratory testing introduced In the book Testing Computer Software Cem Kaner uses the term 'exploratory testing' for the first time. 1988 HyperText Markup Language Physicist from CERN Tim Berners-Lee First Internet service provider The World: the first commercial provider of dial-up Internet access. THE PREVENTION - ORIENTED PERIOD Linux released Released by student Linus Torvalds from Finland 19911990 19901990
- 13. Context-Driven Testing Cem Kaner, James Bach, Brian Marick and Bret Pettichord start the Context-Driven school of testing based on the principle that 'The value of any practice depends on its context'. The first graphical browser Marc Andreessen produced the Mosaic browser 1992 Google online Larry Page and Sergey Brin launch Google; the internet service provider that rapidly becomes the most visited website in the world. Pairwise testing Introduced by David Cohen, Siddhartha Dalal, Jesse Parelius and Gardner Patton in their paper The Combinatorial Design Approach to Automatic Test Generation THE PREVENTION - ORIENTED PERIOD Agile Manifesto published 17 representatives from different development methodologies leads to the Agile Manifesto in which the Twelve Principles of Agile Software are published. 20011996 19991996
- 14. Selenium developed The popular web application test tool Selenium is developed at by Jason Huggins. ISTQB founded The International Software Testing Qualifications Board is founded in Edinburgh. 2002 Test-Driven Development In the book Test Driven Development: By Example Kent Beck publishes the software development technique in which a test is written before the functionality is coded. Schools of Software Testing Bret Pettichord publishes the paper in which he classifies software testing ideas into five schools. THE PREVENTION - ORIENTED PERIOD Test Automation Pyramid Published in the book Succeeding with Agile by Mike Cohn. 20092003 20042002
- 15. The History of Software Testing DEBAGGING to debug the software … - 1956 DEMONSTRATION to prove that software works 1957 - 1978 DESTRUCTION to prove that software doesn’t work 1979 - 1982 EVALUATION to measure the quality 1983 - 1987 PREVENTION to prevent faults 1988 - ...
- 16. Seven principles of Software Testing
- 17. 1 - Testing shows presence of defects Testing can show the defects are present, but cannot prove that there are no defects. Even after testing the application or product thoroughly we cannot say that the product is 100% defect free. Testing always reduces the number of undiscovered defects remaining in the software but even if no defects are found, it is not a proof of correctness.
- 18. 2 - Exhaustive testing is impossible Testing everything including all combinations of inputs and preconditions is not possible. So, instead of doing the exhaustive testing we can use risks and priorities to focus testing efforts. For example: In an application in one screen there are 15 input fields, each having 5 possible values, then to test all the valid combinations you would need 30 517 578 125 (515 ) tests. This is very unlikely that the project timescales would allow for this number of tests. So, accessing and managing risk is one of the most important activities and reason for testing in any project.
- 19. 3. Early testing It is much cheaper to fix a Defect in early stages of testing. In the software development life cycle testing activities should start as early as possible and should be focused on defined objectives. So that any defects in the requirements or design phase are captured in early stages.
- 20. 4. Defect clustering A small number of modules contains most of the defects discovered during pre-release testing or shows the most operational failures. This is the application of the Pareto Principle to software testing: approximately 80% of the problems are found in 20% of the modules.
- 21. 5. Pesticide paradox If the same kinds of tests are repeated again and again, eventually the same set of test cases will no longer be able to find any new bugs. To overcome this “Pesticide Paradox”, it is really very important to review the test cases regularly and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects.
- 22. 6. Testing is context dependent Testing is basically context dependent. Different kinds of sites are tested differently. For example, safety – critical software is tested differently from an e-commerce site. All the developed software’s are not identical. You might use a different approach, methodologies, techniques and types of testing depending upon the application type.
- 23. 7. Absence – of – errors fallacy If the system built is unusable and does not fulfil the user’s needs and expectations then finding and fixing defects does not help. It is possible that software which is 99% bug-free is still unusable. This can be the case if the system is tested thoroughly for the wrong requirement. Software testing is not mere finding defects, but also to check that software addresses the business needs.