DOCSLIB.ORG

Topic # 10 Software Testing: Strategies (Ch

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Topic # 10 Software Testing: Strategies (Ch Topic # 10 Software Testing: Strategies (Ch. 17) 1 Objectives 1. Software Testing Strategy 2. Unit Testing 3. Integration Testing 4. Validation Testing 5. System Testing 2 Software Testing Strategy The goal of software testing is to uncover errors. To achieve this goal objective, the following strategic approach should be used: a series of 4 types (levels) of software tests – 1) unit tests, 2) integration tests, 3) validation tests, and 4) system tests. – should be planned and executed. Software testing accounts for the largest percentage (up to 25-30%) of technical effort in the software engineering process. Testing -- a systematic, planned activity Debugging -- an art (luck, intuition, etc). 3 Verification and Validation Verification -- process-related term corresponds to “Are we building the product right?” (Is software engineering process correct?) Validation - product-related term corresponds to “Are we building the right product?” (Is software product correct: Does it meet all customer requirements?) Ex: somebody used software engineering theory, software design procedures, graphic user interface, testing procedures, BUT the final software product is useless for a customer (or, maybe it is not popular among vast majority of customers, users). In this case: - verification – YES, - validation – NO. 4 Components of Software Testing Strategy 1. Unit tests 2. Unit integration tests concentrate on functional verification of a component concentrate on functional and incorporation verification of a component and incorporation of components into a program structure. 4. System tests 3. Validation tests demonstrates traceability validates software once it has been validates software once it has been to software requirements Incorporated into a larger system (actual environment) 5 Question: Why do we need so many types of tests? Answers: Due to various types of bugs of software system. Due to various consequences of SW bugs. Bug Categories: 1) variables-related bugs, 2) input/output data-related bugs, 3) coding (syntax)-related bugs, 4) system-related bugs, 5) functionality (functions)-related bugs, 6) design-related bugs, 7) standards violation-related bugs, 8) documentation-related bugs, etc. Consequences (Types) of SW Bugs infectious In 2002, a study damage commissioned by the US Department of Commerce' catastrophic National Institute of Standards and Technology concluded extreme that software bugs, or errors, serious are so prevalent and so harmful that they cost the US disturbing economy an estimated $59 billion annually, or about annoying 0.6 percent of the gross mild domestic product. Bug Type 6 What Testing Shows (Outcomes) syntax (coding) errors, logic errors, input date errors, etc. requirements conformance performance quality of final product 7 1. Unit Testing Testing begins at the unit (module) level and works “outward” toward the integration of the entire SW system Testing is conducted by the developer in the developer’s environment (alpha-testing) and by independent testing group outside development environment (beta-testing). module to be tested results software engineer test cases Unit testing focuses verification effort on the smallest unit. Parallel testing on multiple modules is possible. 8 Unit Testing (cont.) module to be tested We should test: • scope of all declared variables (local, global) • data types of variables (integer, real, string, char, etc.) • boundary conditions (what will happen with variables when we leave this unit or module) • all functional tests (to test all required functions inside this unit) • independent paths inside this unit or module • all interfaces inside unit/module • identify and test all error-handling paths test cases 9 2. Integration Testing Strategies The goal of integration testing is to ensure that all interacting software units/modules/subsystems in a system interface correctly with one another to produce the desired results. Furthermore, in trying to attain this goal, integration tests will ensure that the introduction of one or more subsystems into the system does not have an adverse affect on existing functionality. An integration test covers the testing of interface points between subsystems. Integration testing is performed once unit testing has been completed for all units contained in the subsystems being tested. 2 main approaches: • top-down integration (the “big bang” approach) • bottom-up integration (an incremental construction strategy) 10 Top Down Integration (cont.) A top module is tested with stubs B F G stubs are replaced one at a time, "depth first" C as new modules are integrated, some subset of tests is re-run D E 11 Bottom-Up Integration (cont.) A B F G drivers are replaced one at a time, "depth first" C working modules are grouped into building blocks and integrated D E cluster 12 3, 4, … and other High Order Testing other specialized testing Validation testing: Focus is on software requirements 4. system test System testing: Focus is on system integration Alpha/Beta testing: Focus is on customer usage Recovery testing: forces the software to fail in a variety of ways and verifies that recovery is properly performed Security testing: verifies that protection mechanisms built into 3. validation test a system will, in fact, protect it from improper penetration Stress testing: executes a system in a manner that demands resources in abnormal quantity, frequency, or volume Performance Testing: test the run-time performance of software within the context of an integrated system 13 Software Testing: Tools by IBM Company (examples) 14 Topic # 10 Software Testing: Strategies Ch. 17: Additional Information 15 Software Testing: Additional Information 1. Software Testing Standards and Procedures http://it.toolbox.com/blogs/enterprise-solutions/sample-software-testing-standards-and- procedures-12772 2. Unit Testing http://mauriziostorani.wordpress.com/2008/07/09/unit-testing-examples-concepts-and- frameworks/ 3. Integration Testing http://www.exforsys.com/tutorials/testing/integration-testing-whywhathow.html 16 Topic # 10: Software Testing: SW Testing Techniques (Ch. 18) 17 Objectives 1. Software Testing Principles 2. Black-Box Testing technique 3. White-Box Testing technique 18 SW Testing Principles 1. All tests should traceable to customer requirements. *) most severe problems are those that cause program to fail to meet customer requirements 2. Tests should be planned long before actual testing process begins. *) think about testing as soon as customer requirements are completed 3. The Pareto principle applies to SW testing. *) 80% of all errors uncovered during testing will likely be traceable to 20 percent of all program components OR 20% of components generate 80% of errors 4. Testing should begin “in the small” (modules) and progress toward testing “in the large” (subsystems and systems). *) think about different testing procedures and content (tests) for each SW level -- system, subsystem, unit, component as soon as requirements are completed 5. Exhaustive testing is NOT possible. *) number of path permutations even in a small program is exceptionally large Æ if required reliability is greater than 0.9… 6. To be most effective, testing should be conducted by both a developer (alpha-testing) and an independent tester (beta-testing). 19 Who Tests the Software? SW developer • understands the system • is driven by "delivery“ • will test "gently" Alpha-Testing Independent tester • must learn about the system, • is driven by quality • will attempt to test as much Beta-Testing as possible; even break software system 20 Software Testing Techniques white-box black-box technique technique Techniques Strategies 21 White Box Testing Technique The goal of white-box testing (inside- module) is to 1) exercise all program logic paths within a module at least once, 2) check all loop execution constraints on both TRUE and FALSE (YES/NO) sides, and 3) check all internal data structure boundaries to ensure their validity. It focuses on the program control structure within a single module. ... our goal is to ensure that all It is a very time- and effort- statements and conditions have been executed at least once ... consuming testing method. 22 White-Box Testing Mechanics Unit/Module Environment Input Data Output Data Code Example: Currency (EURO to DOLLAR) converter unit/module (1-999 Euros -- 1.4; 1000-9999 – 1.45; >10000 – 1.45) Input: Amount (in EUROs) Output: Amount in U.S. DOLARS (with a rate based on amount of EURos) 23 Example 24 Exhaustive Testing vs Selective Testing Selective Testing: applications of the the Pareto principle : 80% of all errors uncovered during testing will likely be traceable to 20 percent of all components OR 20% of components generate 80% of errors Knowledge ? Experience ! Intuition! 25 Topic # 10 Software Testing: SW Testing Techniques In-Classroom Exercise # 1 26 Black-Box Testing Technique Black-box testing focuses on the requirements functional requirements of the software without regard to the internal workings of a module or program. It is not an alternative to white- outputs box testing; it is a complementary approach. Both white-box and black-box techniques uncover different inputs events classes (types) of errors. 27 Black-Box Testing Environment Input Data (of specified data Output Data (of specified data types and structures) types and structures) Unit/module Code(with code) Events Example: Webster system Input: Alpha-numeric UserName and Password Output: a) BUID number (integer data type), b) CORRECT (Yes, Enter)/INCORRECT
Load more

Recommended publications
  • Core Elements of Continuous Testing
    WHITE PAPER CORE ELEMENTS OF CONTINUOUS TESTING Today’s modern development disciplines -- whether Agile, Continuous Integration (CI) or Continuous Delivery (CD) -- have completely transformed how teams develop and deliver applications. Companies that need to compete in today’s fast-paced digital economy must also transform how they test. Successful teams know the secret sauce to delivering high quality digital experiences fast is continuous testing. This paper will define continuous testing, explain what it is, why it’s important, and the core elements and tactical changes development and QA teams need to make in order to succeed at this emerging practice. TABLE OF CONTENTS 3 What is Continuous Testing? 6 Tactical Engineering Considerations 3 Why Continuous Testing? 7 Benefits of Continuous Testing 4 Core Elements of Continuous Testing WHAT IS CONTINUOUS TESTING? Continuous testing is the practice of executing automated tests throughout the software development cycle. It’s more than just automated testing; it’s applying the right level of automation at each stage in the development process. Unlike legacy testing methods that occur at the end of the development cycle, continuous testing occurs at multiple stages, including development, integration, pre-release, and in production. Continuous testing ensures that bugs are caught and fixed far earlier in the development process, improving overall quality while saving significant time and money. WHY CONTINUOUS TESTING? Continuous testing is a critical requirement for organizations that are shifting left towards CI or CD, both modern development practices that ensure faster time to market. When automated testing is coupled with a CI server, tests can instantly be kicked off with every build, and alerts with passing or failing test results can be delivered directly to the development team in real time.
    [Show full text]
  • Software Development Career Pathway
    Career Exploration Guide Software Development Career Pathway Information Technology Career Cluster For more information about NYC Career and Technical Education, visit: www.cte.nyc Summer 2018 Getting Started What is software? What Types of Software Can You Develop? Computers and other smart devices are made up of Software includes operating systems—like Windows, Web applications are websites that allow users to contact management system, and PeopleSoft, a hardware and software. Hardware includes all of the Apple, and Google Android—and the applications check email, share documents, and shop online, human resources information system. physical parts of a device, like the power supply, that run on them— like word processors and games. among other things. Users access them with a Mobile applications are programs that can be data storage, and microprocessors. Software contains Software applications can be run directly from a connection to the Internet through a web browser accessed directly through mobile devices like smart instructions that are stored and run by the hardware. device or through a connection to the Internet. like Firefox, Chrome, or Safari. Web browsers are phones and tablets. Many mobile applications have Other names for software are programs or applications. the platforms people use to find, retrieve, and web-based counterparts. display information online. Web browsers are applications too. Desktop applications are programs that are stored on and accessed from a computer or laptop, like Enterprise software are off-the-shelf applications What is Software Development? word processors and spreadsheets. that are customized to the needs of businesses. Popular examples include Salesforce, a customer Software development is the design and creation of Quality Testers test the application to make sure software and is usually done by a team of people.
    [Show full text]
  • Testing E-Commerce Systems: a Practical Guide - Wing Lam
    Testing E-Commerce Systems: A Practical Guide - Wing Lam As e-customers (whether business or consumer), we are unlikely to have confidence in a Web site that suffers frequent downtime, hangs in the middle of a transaction, or has a poor sense of usability. Testing, therefore, has a crucial role in the overall development process. Given unlimited time and resources, you could test a system to exhaustion. However, most projects operate within fixed budgets and time scales, so project managers need a systematic and cost- effective approach to testing that maximizes test confidence. This article provides a quick and practical introduction to testing medium- to large-scale transactional e-commerce systems based on project experiences developing tailored solutions for B2C Web retailing and B2B procurement. Typical of most e-commerce systems, the application architecture includes front-end content delivery and management systems, and back-end transaction processing and legacy integration. Aimed primarily at project and test managers, this article explains how to · establish a systematic test process, and · test e-commerce systems. The Test Process You would normally expect to spend between 25 to 40 percent of total project effort on testing and validation activities. Most seasoned project managers would agree that test planning needs to be carried out early in the project lifecycle. This will ensure the time needed for test preparation (establishing a test environment, finding test personnel, writing test scripts, and so on) before any testing can actually start. The different kinds of testing (unit, system, functional, black-box, and others) are well documented in the literature.
    [Show full text]
  • Practical Unit Testing for Embedded Systems Part 1 PARASOFT WHITE PAPER
    Practical Unit Testing for Embedded Systems Part 1 PARASOFT WHITE PAPER Table of Contents Introduction 2 Basics of Unit Testing 2 Benefits 2 Critics 3 Practical Unit Testing in Embedded Development 3 The system under test 3 Importing uVision projects 4 Configure the C++test project for Unit Testing 6 Configure uVision project for Unit Testing 8 Configure results transmission 9 Deal with target limitations 10 Prepare test suite and first exemplary test case 12 Deploy it and collect results 12 Page 1 www.parasoft.com Introduction The idea of unit testing has been around for many years. "Test early, test often" is a mantra that concerns unit testing as well. However, in practice, not many software projects have the luxury of a decent and up-to-date unit test suite. This may change, especially for embedded systems, as the demand for delivering quality software continues to grow. International standards, like IEC-61508-3, ISO/DIS-26262, or DO-178B, demand module testing for a given functional safety level. Unit testing at the module level helps to achieve this requirement. Yet, even if functional safety is not a concern, the cost of a recall—both in terms of direct expenses and in lost credibility—justifies spending a little more time and effort to ensure that our released software does not cause any unpleasant surprises. In this article, we will show how to prepare, maintain, and benefit from setting up unit tests for a simplified simulated ASR module. We will use a Keil evaluation board MCBSTM32E with Cortex-M3 MCU, MDK-ARM with the new ULINK Pro debug and trace adapter, and Parasoft C++test Unit Testing Framework.
    [Show full text]
  • Interpreting Reliability and Availability Requirements for Network-Centric Systems What MCOTEA Does
    Marine Corps Operational Test and Evaluation Activity Interpreting Reliability and Availability Requirements for Network-Centric Systems What MCOTEA Does Planning Testing Reporting Expeditionary, C4ISR & Plan Naval, and IT/Business Amphibious Systems Systems Test Evaluation Plans Evaluation Reports Assessment Plans Assessment Reports Test Plans Test Data Reports Observation Plans Observation Reports Combat Ground Service Combat Support Initial Operational Test Systems Systems Follow-on Operational Test Multi-service Test Quick Reaction Test Test Observations 2 Purpose • To engage test community in a discussion about methods in testing and evaluating RAM for software-intensive systems 3 Software-intensive systems – U.S. military one of the largest users of information technology and software in the world [1] – Dependence on these types of systems is increasing – Software failures have had disastrous consequences Therefore, software must be highly reliable and available to support mission success 4 Interpreting Requirements Excerpts from capabilities documents for software intensive systems: Availability Reliability “The system is capable of achieving “Average duration of 716 hours a threshold operational without experiencing an availability of 95% with an operational mission fault” objective of 98%” “Mission duration of 24 hours” “Operationally Available in its intended operating environment “Completion of its mission in its with at least a 0.90 probability” intended operating environment with at least a 0.90 probability” 5 Defining Reliability & Availability What do we mean reliability and availability for software intensive systems? – One consideration: unlike traditional hardware systems, a highly reliable and maintainable system will not necessarily be highly available - Highly recoverable systems can be less available - A system that restarts quickly after failures can be highly available, but not necessarily reliable - Risk in inflating availability and underestimating reliability if traditional equations are used.
    [Show full text]
  • Parallel, Cross-Platform Unit Testing for Real-Time Embedded Systems
    University of Denver Digital Commons @ DU Electronic Theses and Dissertations Graduate Studies 1-1-2017 Parallel, Cross-Platform Unit Testing for Real-Time Embedded Systems Tosapon Pankumhang University of Denver Follow this and additional works at: https://digitalcommons.du.edu/etd Part of the Computer Sciences Commons Recommended Citation Pankumhang, Tosapon, "Parallel, Cross-Platform Unit Testing for Real-Time Embedded Systems" (2017). Electronic Theses and Dissertations. 1353. https://digitalcommons.du.edu/etd/1353 This Dissertation is brought to you for free and open access by the Graduate Studies at Digital Commons @ DU. It has been accepted for inclusion in Electronic Theses and Dissertations by an authorized administrator of Digital Commons @ DU. For more information, please contact [email protected],[email protected]. PARALLEL, CROSS-PLATFORM UNIT TESTING FOR REAL-TIME EMBEDDED SYSTEMS __________ A Dissertation Presented to the Faculty of the Daniel Felix Ritchie School of Engineering and Computer Science University of Denver __________ In Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy __________ by Tosapon Pankumhang August 2017 Advisor: Matthew J. Rutherford ©Copyright by Tosapon Pankumhang 2017 All Rights Reserved Author: Tosapon Pankumhang Title: PARALLEL, CROSS-PLATFORM UNIT TESTING FOR REAL-TIME EMBEDDED SYSTEMS Advisor: Matthew J. Rutherford Degree Date: August 2017 ABSTRACT Embedded systems are used in a wide variety of applications (e.g., automotive, agricultural, home security, industrial, medical, military, and aerospace) due to their small size, low-energy consumption, and the ability to control real-time peripheral devices precisely. These systems, however, are different from each other in many aspects: processors, memory size, develop applications/OS, hardware interfaces, and software loading methods.
    [Show full text]
  • QA and Testing Have Become More of a Concurrent Process
    Special Feature: SW Testing “QA and testing have become more of a concurrent process rather than an end of lifecycle process” Manish Tandon, VP & Head– Independent Validation and Testing Solutions, Infosys Interview by: Anil Chopra, PCQuest n an exclusive interview with the PCQuest Editor, Manish talks become a software tester? about the global trends in software testing, skillsets required Software testing has evolved into a very special function and Ito enter the field, how technology has evolved in this area to anybody wanting to enter the domain requires two special provide higher ROI, and much more. An IIT and IIM graduate, skillsets. One is deep functional or domain skills to understand Manish is responsible for formulating and executing the business the functionality. Plus, you need specialized technical skills strategy for Independent Validation and Testing Solutions practice as well because you want to do automation, middleware, and at Infosys. He mentors the unit specifically in meeting business performance testing. It’s a unique combination, and we focus goals and targets. In addition, he manages critical relationships very strongly on both these dimensions. A good software tester with client executives, industry analysts, deal consultants, and should always have an eye for detail. So people who have a slightly anchors the training and development of key personnel. Provided critical eye and are willing to dig deeper always make much better here are his expert comments on the subject. testers than people who want to fly at 30k feet. Q> What are some of the global trends in the software Q> You mentioned that software testing is now required testing business? How do you see the market moving? for front-end applications.
    [Show full text]
  • Leading Practice: Test Strategy and Approach in Agile Projects
    CA SERVICES | LEADING PRACTICE Leading Practice: Test Strategy and Approach in Agile Projects Abstract This document provides best practices on how to strategize testing CA Project and Portfolio Management (CA PPM) in an agile project. The document does not include specific test cases; the list of test cases and steps for each test case are provided in a separate document. This document should be used by the agile project team that is planning the testing activities, and by end users who perform user acceptance testing (UAT). Concepts Concept Description Test Approach Defines testing strategy, roles and responsibilities of various team members, and test types. Testing Environments Outlines which testing is carried out in which environment. Testing Automation and Tools Addresses test management and automation tools required for test execution. Risk Analysis Defines the approach for risk identification and plans to mitigate risks as well as a contingency plan. Test Planning and Execution Defines the approach to plan the test cases, test scripts, and execution. Review and Approval Lists individuals who should review, approve and sign off on test results. Test Approach The test approach defines testing strategy, roles and responsibilities of various team members, and the test types. The first step is to define the testing strategy. It should describe how and when the testing will be conducted, who will do the testing, the type of testing being conducted, features being tested, environment(s) where the testing takes place, what testing tools are used, and how are defects tracked and managed. The testing strategy should be prepared by the agile core team.
    [Show full text]
  • Unit Testing Is a Level of Software Testing Where Individual Units/ Components of a Software Are Tested. the Purpose Is to Valid
    Unit Testing is a level of software testing where individual units/ components of a software are tested. The purpose is to validate that each unit of the software performs as designed. A unit is the smallest testable part of software. It usually has one or a few inputs and usually a single output. In procedural programming a unit may be an individual program, function, procedure, etc. In object-oriented programming, the smallest unit is a method, which may belong to a base/ super class, abstract class or derived/ child class. (Some treat a module of an application as a unit. This is to be discouraged as there will probably be many individual units within that module.) Unit testing frameworks, drivers, stubs, and mock/ fake objects are used to assist in unit testing. METHOD Unit Testing is performed by using the White Box Testing method. When is it performed? Unit Testing is the first level of testing and is performed prior to Integration Testing. BENEFITS Unit testing increases confidence in changing/ maintaining code. If good unit tests are written and if they are run every time any code is changed, we will be able to promptly catch any defects introduced due to the change. Also, if codes are already made less interdependent to make unit testing possible, the unintended impact of changes to any code is less. Codes are more reusable. In order to make unit testing possible, codes need to be modular. This means that codes are easier to reuse. Development is faster. How? If you do not have unit testing in place, you write your code and perform that fuzzy ‘developer test’ (You set some breakpoints, fire up the GUI, provide a few inputs that hopefully hit your code and hope that you are all set.) If you have unit testing in place, you write the test, write the code and run the test.
    [Show full text]
  • Including Jquery Is Not an Answer! - Design, Techniques and Tools for Larger JS Apps
    Including jQuery is not an answer! - Design, techniques and tools for larger JS apps Trifork A/S, Headquarters Margrethepladsen 4, DK-8000 Århus C, Denmark [email protected] Karl Krukow http://www.trifork.com Trifork Geek Night March 15st, 2011, Trifork, Aarhus What is the question, then? Does your JavaScript look like this? 2 3 What about your server side code? 4 5 Non-functional requirements for the Server-side . Maintainability and extensibility . Technical quality – e.g. modularity, reuse, separation of concerns – automated testing – continuous integration/deployment – Tool support (static analysis, compilers, IDEs) . Productivity . Performant . Appropriate architecture and design . … 6 Why so different? . “Front-end” programming isn't 'real' programming? . JavaScript isn't a 'real' language? – Browsers are impossible... That's just the way it is... The problem is only going to get worse! ● JS apps will get larger and more complex. ● More logic and computation on the client. ● HTML5 and mobile web will require more programming. ● We have to test and maintain these apps. ● We will have harder requirements for performance (e.g. mobile). 7 8 NO Including jQuery is NOT an answer to these problems. (Neither is any other js library) You need to do more. 9 Improving quality on client side code . The goal of this talk is to motivate and help you improve the technical quality of your JavaScript projects . Three main points. To improve non-functional quality: – you need to understand the language and host APIs. – you need design, structure and file-organization as much (or even more) for JavaScript as you do in other languages, e.g.
    [Show full text]
  • Testing and Debugging Tools for Reproducible Research
    Testing and debugging Tools for Reproducible Research Karl Broman Biostatistics & Medical Informatics, UW–Madison kbroman.org github.com/kbroman @kwbroman Course web: kbroman.org/Tools4RR We spend a lot of time debugging. We’d spend a lot less time if we tested our code properly. We want to get the right answers. We can’t be sure that we’ve done so without testing our code. Set up a formal testing system, so that you can be confident in your code, and so that problems are identified and corrected early. Even with a careful testing system, you’ll still spend time debugging. Debugging can be frustrating, but the right tools and skills can speed the process. "I tried it, and it worked." 2 This is about the limit of most programmers’ testing efforts. But: Does it still work? Can you reproduce what you did? With what variety of inputs did you try? "It's not that we don't test our code, it's that we don't store our tests so they can be re-run automatically." – Hadley Wickham R Journal 3(1):5–10, 2011 3 This is from Hadley’s paper about his testthat package. Types of tests ▶ Check inputs – Stop if the inputs aren't as expected. ▶ Unit tests – For each small function: does it give the right results in specific cases? ▶ Integration tests – Check that larger multi-function tasks are working. ▶ Regression tests – Compare output to saved results, to check that things that worked continue working. 4 Your first line of defense should be to include checks of the inputs to a function: If they don’t meet your specifications, you should issue an error or warning.
    [Show full text]
  • The Roots of Software Engineering*
    THE ROOTS OF SOFTWARE ENGINEERING* Michael S. Mahoney Princeton University (CWI Quarterly 3,4(1990), 325-334) At the International Conference on the History of Computing held in Los Alamos in 1976, R.W. Hamming placed his proposed agenda in the title of his paper: "We Would Know What They Thought When They Did It."1 He pleaded for a history of computing that pursued the contextual development of ideas, rather than merely listing names, dates, and places of "firsts". Moreover, he exhorted historians to go beyond the documents to "informed speculation" about the results of undocumented practice. What people actually did and what they thought they were doing may well not be accurately reflected in what they wrote and what they said they were thinking. His own experience had taught him that. Historians of science recognize in Hamming's point what they learned from Thomas Kuhn's Structure of Scientific Revolutions some time ago, namely that the practice of science and the literature of science do not necessarily coincide. Paradigms (or, if you prefer with Kuhn, disciplinary matrices) direct not so much what scientists say as what they do. Hence, to determine the paradigms of past science historians must watch scientists at work practicing their science. We have to reconstruct what they thought from the evidence of what they did, and that work of reconstruction in the history of science has often involved a certain amount of speculation informed by historians' own experience of science. That is all the more the case in the history of technology, where up to the present century the inventor and engineer have \*-as Derek Price once put it\*- "thought with their fingertips", leaving the record of their thinking in the artefacts they have designed rather than in texts they have written.
    [Show full text]