{"id":232,"date":"2018-07-24T12:18:00","date_gmt":"2018-07-24T12:18:00","guid":{"rendered":"http:\/\/csp8.epgpbooks.inflibnet.ac.in\/?post_type=chapter&p=232"},"modified":"2018-08-08T05:38:39","modified_gmt":"2018-08-08T05:38:39","slug":"fundamentals-of-software-testing","status":"publish","type":"chapter","link":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/chapter\/fundamentals-of-software-testing\/","title":{"rendered":"Fundamentals of Software Testing"},"content":{"raw":"
\r\n\r\n \r\n

FUNDAMENTALS OF SOFTWARE TESTING\u00a0<\/strong><\/p>\r\n \r\n

Software testing is the evaluation of a system with the intention of finding an error or fault or a bug. It also checks for the functionalities of the system so that it meets the specified requirements.<\/p>\r\n \r\n

LEARNING OBJECTIVES\u00a0<\/strong><\/p>\r\n \r\n

\u2022\u00a0 To execute a program with the intent of finding an error.<\/em><\/p>\r\n

\u2022\u00a0 To check if the system meets the requirements and be executed successfully in the intended environment.<\/p>\r\n

\u2022\u00a0 To check if the system is \u201cFit for purpose\u201d.<\/p>\r\n

\u2022\u00a0 To check if the system does what it is expected to do.<\/p>\r\n \r\n

COMPUTER BUG\u00a0<\/strong><\/p>\r\n \r\n

In 1947, Harvard University was operating a room-sized computer called the Mark II. It encompassed mechanical relays and glowing vacuum tubes. The technicians program the computer by reconfiguring it and they had to change the occasional vacuum tube. A moth flew into the computer and was zapped by the high voltage when it landed on a relay. Bugs can also be known as:<\/p>\r\n \r\n

\u00b7\u00a0 Defect<\/p>\r\n

\u00b7\u00a0 Fault<\/p>\r\n

\u00b7\u00a0 Problem<\/p>\r\n

\u00b7\u00a0 Error<\/p>\r\n

\u00b7\u00a0 Incident<\/p>\r\n

\u00b7\u00a0 Anomaly<\/p>\r\n

\u00b7\u00a0 Variance<\/p>\r\n

\u00b7\u00a0 Failure<\/p>\r\n

\u00b7\u00a0 Inconsistency<\/p>\r\n

\u00b7\u00a0 Product Anomaly<\/p>\r\n

\u00b7\u00a0 Product Incidence<\/p>\r\n

\u00b7\u00a0 Feature<\/p>\r\n\r\n<\/div>\r\n

\r\n\r\n \r\n

The programs that are developed contain defects which are hard to predict in the future, however it is highly likely, that the software we will develop in the future will not be significantly better.<\/p>\r\n \r\n\r\nSources of Problems\u00a0<\/strong>\r\n\r\n \r\n\r\nThe problems can arise from various sources such as:\r\n\r\n \r\n\r\n\u00b7\u00a0 Requirements Definition: <\/strong>Erroneous, incomplete, inconsistent requirements.\r\n\r\n\u00b7\u00a0 Design:\u00a0<\/strong>Fundamental design flaws in the software.\r\n\r\n\u00b7\u00a0 Implementation:\u00a0<\/strong>Mistakes in chip fabrication, wiring, programming faults, malicious code.\r\n\r\n\u00b7\u00a0 Support \u00a0Systems:\u00a0<\/strong>Poor programming languages, faulty compilers and debuggers, misleading development tools.\r\n\r\n\u00b7\u00a0 Inadequate Testing of Software: <\/strong>Incomplete testing, poor verification, mistakes in debugging.\r\n\r\n\u00b7\u00a0 Evolution: <\/strong>Sloppy redevelopment or maintenance, introduction of new flaws in attempts to fix old flaws, incremental escalation to inordinate complexity.\r\n\r\n \r\n\r\nAdverse Effects of Faulty Software\u00a0<\/strong>\r\n\r\n \r\n\r\nFaulty software causes many adverse effects such as:\r\n\r\n \r\n\r\n\u00b7\u00a0 Money Management:\u00a0<\/strong>Fraud, violation of privacy, shutdown of stock exchanges and banks, negative interest rates.\r\n\r\n\u00b7\u00a0 Control of Elections: <\/strong>Wrong results (intentional or non-intentional).\r\n\r\n\u00b7\u00a0 Control of Jails: <\/strong>Technology-aided escape attempts and successes, accidental release of inmates, failures in software controlled locks.\r\n\r\n\u00b7\u00a0 Law Enforcement: \u00a0<\/strong>False arrests and imprisonments.\r\n\r\n<\/div>\r\n

\r\n\r\n \r\n

Project Mercury\u2019s FORTRAN code had the following fault: DO I=1.10 instead of ... DO I=1...10. The fault was discovered in an analysis of why the software did not seem to generate results that were sufficiently accurate. The erroneous 1.10 would cause the loop to be executed exactly once.<\/p>\r\n \r\n\r\nMilitary Aviation Problems\u00a0<\/strong>\r\n\r\n \r\n

An F-18 crashed because of a missing exception condition: if ... then ... without the else clause that was thought could not possibly arise. In simulation, an F-16 program bug caused the virtual plane to flip over whenever it crossed the equator, as a result of a missing minus sign to indicate south latitude.<\/p>\r\n \r\n\r\nYear Ambiguities\u00a0<\/strong>\r\n\r\n \r\n

In 1992, Mary Bandar received an invitation to attend a kindergarten in Winona, Minnesota, along with others born in '88. Mary was 104 years old at the time. Mr. Blodgett\u2019s auto insurance rate tripled when he turned 101. He was the computer program\u2019s first driver over 100, and his age was interpreted as 1. This is a double blunder because the program\u2019s definition of a teenager is someone under 20!<\/p>\r\n \r\n\r\nAT&T Bug\u00a0<\/strong>\r\n\r\n \r\n

In mid-December 1989, AT&T installed new software in 114 electronic switching systems. On January 15, 1990, 5 million calls were blocked during a 9 hour period nationwide. The bug was traced to a C program that contained a break statement within an switch clause nested within a loop. The switch clause was part of a loop. Initially, the loop contained only if clauses with break statements to exit the loop. When the control logic became complicated, a switch clause was added to improve the readability of the code.<\/p>\r\n\r\n<\/div>\r\n

\r\n\r\n \r\n

A Norwegian bank ATM consistently dispersed 10 times the amount required. Many people joyously joined the queues as the word spread. A software flaw caused a UK bank to duplicate every transfer payment request for half an hour. The bank lost 2 billion British pounds. The bank eventually recovered the funds but lost half a million pounds in potential interest.<\/p>\r\n \r\n\r\nMaking Rupee\u00a0<\/strong>\r\n\r\n \r\n

An Australian man purchased $104,500 worth of Sri Lankan Rupees. The next day he sold the Rupees to another bank for $440,258. The first bank\u2019s software had displayed a bogus exchange rate in the Rupee position. A judge ruled that the man had acted without intended fraud and could keep the extra $335,758.<\/p>\r\n \r\n\r\nBug in BoNY Software\u00a0<\/strong>\r\n\r\n \r\n

The Bank of New York (BoNY) had a $32 billion overdraft as the result of a 16-bit integer counter that went unchecked. BoNY was unable to process the incoming credits from security transfers, while the NY Federal Reserve automatically debited BoNY\u2019s cash account.<\/p>\r\n \r\n\r\nSPECIFICATION\u00a0<\/strong>\r\n\r\n \r\n

You have to know what your product is before you can say if it has a bug -\u201cif you can\u2019t say it, you can\u2019t do it\u201d. A specification <\/em>defines the product being created and includes the functional requirements that describe the features the product will support (E.g. on a word processor save, print, check spelling, change font etc) and non-functional requirements that focuses on the constraints of the product (E.g. Security, reliability, user friendliness, platform etc).<\/p>\r\n \r\n\r\nSOFTWARE BUGS\u00a0<\/strong>\r\n\r\n \r\n\r\nA software bug occurs when at least one of these rules is true:\r\n\r\n \r\n\r\n\u25e6\u00a0 The software does not do something that the specification says it should do.\r\n\r\n\u25e6\u00a0 The software does something that the specification says it should not do.\r\n\r\n\u25e6\u00a0 The software does something that the specification does not mention.\r\n\r\n\u25e6\u00a0 The software does not do something that the product specification does not mention but should.<\/span>\r\n\r\n\u25e6\u00a0 The software is difficult to understand, hard to use or slow.<\/span>\r\n\r\n<\/div>\r\n

\r\n\r\n \r\n\r\nMost bugs are not because of mistakes in the code, the estimation of the bugs uncovered at various phases is as follows:\r\n
    \r\n \t
  • Specification (~= 55%)<\/li>\r\n \t
  • Design (~= 25%)<\/li>\r\n \t
  • Code (~= 15%)<\/li>\r\n \t
  • Other (~= 5%)<\/li>\r\n<\/ul>\r\n \r\n\r\nRelative cost of bugs\u00a0<\/strong>\r\n\r\n \r\n

    The bugs that are found at later phases cost more to fix. Cost to fix a bug increases exponentially (10x) i.e. it increases tenfold as time increases. E.g. a bug found during specification costs $1 to fix. If the bug is found in design cost is $10, if found in code cost is $100 and if found in released software cost is $1000. The cost keeps increasing tenfold as the time increases.<\/p>\r\n \r\n\r\nBug Free Software\u00a0<\/strong>\r\n\r\n \r\n

    Software is in the news for the wrong reason such as security breach, Mars Lander lost, hackers getting credit card information, etc. The development of a bug free software is difficult when software gets more features and supports more platforms, it becomes increasingly difficult to make it create bug-free. The common questions that arise with the development of a bug free software are:<\/p>\r\n \r\n\r\n\u25e6\u00a0 Why can\u2019t software engineers develop software that just works?\r\n\r\n\u25e6\u00a0 Do you think bug free software is unattainable?\r\n\r\n\u25e6\u00a0 Are their technical barriers that make this impossible?\r\n\r\n\u25e6\u00a0 Is it just a question of time before we can do this?\r\n\r\n\u25e6\u00a0 Are we missing technology or processes?\r\n\r\n<\/div>\r\n \r\n

    GOAL OF A SOFTWARE TESTER<\/strong><\/p>\r\n \r\n

    The goals of a software tester is to find bugs as early in the software development processes as possible and make sure they get fixed. The software tester must be careful not to get caught in the dangerous spiral of unattainable perfection. The expectation on a software tester involves checking the following:<\/p>\r\n\r\n

      \r\n \t
    • Are they explorers?<\/li>\r\n \t
    • Are they troubleshooters?<\/li>\r\n \t
    • Are they relentless?<\/li>\r\n \t
    • Are they creative?<\/li>\r\n \t
    • Are they perfectionists (within reason)?<\/li>\r\n \t
    • Do they exercise good judgment?<\/li>\r\n \t
    • Are they tactful and diplomatic?<\/li>\r\n \t
    • Are they persuasive?<\/li>\r\n<\/ul>\r\n \r\n

      TESTING<\/strong><\/p>\r\n \r\n

      Testing is the confirming of correct behavior of a piece of software with respect to this context. Software testing is the evaluation of a system with the intention of finding an error or fault or a bug. It also checks for the functionalities of the system so that it meets the specified requirements. We know what we intended the code to do \u2013 we need to confirm that it does what we intended. Testing involves conducting test to ensure the production function correctly, but the test conducted must be looked into to check whether the tests are testing the right (relevant) \u201cstuff\u201d. The test is testing \u201cmost\u201d of the code and not just repeatedly testing the same code.<\/p>\r\n \r\n

      Good Testing Practices<\/strong><\/p>\r\n \r\n

      A good test case is one that has a high probability of detecting an undiscovered defect, not one that shows that the program works correctly. It is impossible to test your own program. A necessary part of every test case is a description of the expected result. Non-reproducible or on-the-fly testing is avoided. The test cases for valid as well as invalid input conditions are written and the results of each test are thoroughly inspected.<\/p>\r\n \r\n\r\nWeb Links<\/strong>\r\n

        \r\n \t
      • https:\/\/www.tutorialspoint.com\/software_testing\/software_testing_types.htm<\/li>\r\n \t
      • https:\/\/softwaretestingfundamentals.com<\/li>\r\n \t
      • www.softwaretestinghelp.com\/types-of-software-testing\/<\/li>\r\n<\/ul>\r\n \r\n\r\nSupporting & Reference Materials<\/strong>\r\n
          \r\n \t
        • Roger S. Pressman, \u201cSoftware Engineering: A Practitioner\u2019s Approach\u201d, Fifth Edition, McGraw Hill, 2017.<\/li>\r\n \t
        • PankajJalote, \u201cAn Integrated Approach to Software Engineering\u201d, Second Edition, Springer Verlag, 1997.<\/li>\r\n \t
        • Ian Sommerville, \u201cSoftware Engineering\u201d, Sixth Edition, Addison Wesley, 2015.<\/li>\r\n<\/ul>","rendered":"
          \n

           <\/p>\n

          FUNDAMENTALS OF SOFTWARE TESTING\u00a0<\/strong><\/p>\n

           <\/p>\n

          Software testing is the evaluation of a system with the intention of finding an error or fault or a bug. It also checks for the functionalities of the system so that it meets the specified requirements.<\/p>\n

           <\/p>\n

          LEARNING OBJECTIVES\u00a0<\/strong><\/p>\n

           <\/p>\n

          \u2022\u00a0 To execute a program with the intent of finding an error.<\/em><\/p>\n

          \u2022\u00a0 To check if the system meets the requirements and be executed successfully in the intended environment.<\/p>\n

          \u2022\u00a0 To check if the system is \u201cFit for purpose\u201d.<\/p>\n

          \u2022\u00a0 To check if the system does what it is expected to do.<\/p>\n

           <\/p>\n

          COMPUTER BUG\u00a0<\/strong><\/p>\n

           <\/p>\n

          In 1947, Harvard University was operating a room-sized computer called the Mark II. It encompassed mechanical relays and glowing vacuum tubes. The technicians program the computer by reconfiguring it and they had to change the occasional vacuum tube. A moth flew into the computer and was zapped by the high voltage when it landed on a relay. Bugs can also be known as:<\/p>\n

           <\/p>\n

          \u00b7\u00a0 Defect<\/p>\n

          \u00b7\u00a0 Fault<\/p>\n

          \u00b7\u00a0 Problem<\/p>\n

          \u00b7\u00a0 Error<\/p>\n

          \u00b7\u00a0 Incident<\/p>\n

          \u00b7\u00a0 Anomaly<\/p>\n

          \u00b7\u00a0 Variance<\/p>\n

          \u00b7\u00a0 Failure<\/p>\n

          \u00b7\u00a0 Inconsistency<\/p>\n

          \u00b7\u00a0 Product Anomaly<\/p>\n

          \u00b7\u00a0 Product Incidence<\/p>\n

          \u00b7\u00a0 Feature<\/p>\n<\/div>\n

          \n

           <\/p>\n

          The programs that are developed contain defects which are hard to predict in the future, however it is highly likely, that the software we will develop in the future will not be significantly better.<\/p>\n

           <\/p>\n

          Sources of Problems\u00a0<\/strong><\/p>\n

           <\/p>\n

          The problems can arise from various sources such as:<\/p>\n

           <\/p>\n

          \u00b7\u00a0 Requirements Definition: <\/strong>Erroneous, incomplete, inconsistent requirements.<\/p>\n

          \u00b7\u00a0 Design:\u00a0<\/strong>Fundamental design flaws in the software.<\/p>\n

          \u00b7\u00a0 Implementation:\u00a0<\/strong>Mistakes in chip fabrication, wiring, programming faults, malicious code.<\/p>\n

          \u00b7\u00a0 Support \u00a0Systems:\u00a0<\/strong>Poor programming languages, faulty compilers and debuggers, misleading development tools.<\/p>\n

          \u00b7\u00a0 Inadequate Testing of Software: <\/strong>Incomplete testing, poor verification, mistakes in debugging.<\/p>\n

          \u00b7\u00a0 Evolution: <\/strong>Sloppy redevelopment or maintenance, introduction of new flaws in attempts to fix old flaws, incremental escalation to inordinate complexity.<\/p>\n

           <\/p>\n

          Adverse Effects of Faulty Software\u00a0<\/strong><\/p>\n

           <\/p>\n

          Faulty software causes many adverse effects such as:<\/p>\n

           <\/p>\n

          \u00b7\u00a0 Money Management:\u00a0<\/strong>Fraud, violation of privacy, shutdown of stock exchanges and banks, negative interest rates.<\/p>\n

          \u00b7\u00a0 Control of Elections: <\/strong>Wrong results (intentional or non-intentional).<\/p>\n

          \u00b7\u00a0 Control of Jails: <\/strong>Technology-aided escape attempts and successes, accidental release of inmates, failures in software controlled locks.<\/p>\n

          \u00b7\u00a0 Law Enforcement: \u00a0<\/strong>False arrests and imprisonments.<\/p>\n<\/div>\n

          \n

           <\/p>\n

          Project Mercury\u2019s FORTRAN code had the following fault: DO I=1.10 instead of … DO I=1…10. The fault was discovered in an analysis of why the software did not seem to generate results that were sufficiently accurate. The erroneous 1.10 would cause the loop to be executed exactly once.<\/p>\n

           <\/p>\n

          Military Aviation Problems\u00a0<\/strong><\/p>\n

           <\/p>\n

          An F-18 crashed because of a missing exception condition: if … then … without the else clause that was thought could not possibly arise. In simulation, an F-16 program bug caused the virtual plane to flip over whenever it crossed the equator, as a result of a missing minus sign to indicate south latitude.<\/p>\n

           <\/p>\n

          Year Ambiguities\u00a0<\/strong><\/p>\n

           <\/p>\n

          In 1992, Mary Bandar received an invitation to attend a kindergarten in Winona, Minnesota, along with others born in ’88. Mary was 104 years old at the time. Mr. Blodgett\u2019s auto insurance rate tripled when he turned 101. He was the computer program\u2019s first driver over 100, and his age was interpreted as 1. This is a double blunder because the program\u2019s definition of a teenager is someone under 20!<\/p>\n

           <\/p>\n

          AT&T Bug\u00a0<\/strong><\/p>\n

           <\/p>\n

          In mid-December 1989, AT&T installed new software in 114 electronic switching systems. On January 15, 1990, 5 million calls were blocked during a 9 hour period nationwide. The bug was traced to a C program that contained a break statement within an switch clause nested within a loop. The switch clause was part of a loop. Initially, the loop contained only if clauses with break statements to exit the loop. When the control logic became complicated, a switch clause was added to improve the readability of the code.<\/p>\n<\/div>\n

          \n

           <\/p>\n

          A Norwegian bank ATM consistently dispersed 10 times the amount required. Many people joyously joined the queues as the word spread. A software flaw caused a UK bank to duplicate every transfer payment request for half an hour. The bank lost 2 billion British pounds. The bank eventually recovered the funds but lost half a million pounds in potential interest.<\/p>\n

           <\/p>\n

          Making Rupee\u00a0<\/strong><\/p>\n

           <\/p>\n

          An Australian man purchased $104,500 worth of Sri Lankan Rupees. The next day he sold the Rupees to another bank for $440,258. The first bank\u2019s software had displayed a bogus exchange rate in the Rupee position. A judge ruled that the man had acted without intended fraud and could keep the extra $335,758.<\/p>\n

           <\/p>\n

          Bug in BoNY Software\u00a0<\/strong><\/p>\n

           <\/p>\n

          The Bank of New York (BoNY) had a $32 billion overdraft as the result of a 16-bit integer counter that went unchecked. BoNY was unable to process the incoming credits from security transfers, while the NY Federal Reserve automatically debited BoNY\u2019s cash account.<\/p>\n

           <\/p>\n

          SPECIFICATION\u00a0<\/strong><\/p>\n

           <\/p>\n

          You have to know what your product is before you can say if it has a bug -\u201cif you can\u2019t say it, you can\u2019t do it\u201d. A specification <\/em>defines the product being created and includes the functional requirements that describe the features the product will support (E.g. on a word processor save, print, check spelling, change font etc) and non-functional requirements that focuses on the constraints of the product (E.g. Security, reliability, user friendliness, platform etc).<\/p>\n

           <\/p>\n

          SOFTWARE BUGS\u00a0<\/strong><\/p>\n

           <\/p>\n

          A software bug occurs when at least one of these rules is true:<\/p>\n

           <\/p>\n

          \u25e6\u00a0 The software does not do something that the specification says it should do.<\/p>\n

          \u25e6\u00a0 The software does something that the specification says it should not do.<\/p>\n

          \u25e6\u00a0 The software does something that the specification does not mention.<\/p>\n

          \u25e6\u00a0 The software does not do something that the product specification does not mention but should.<\/span><\/p>\n

          \u25e6\u00a0 The software is difficult to understand, hard to use or slow.<\/span><\/p>\n<\/div>\n

          \n

           <\/p>\n

          Most bugs are not because of mistakes in the code, the estimation of the bugs uncovered at various phases is as follows:<\/p>\n

            \n
          • Specification (~= 55%)<\/li>\n
          • Design (~= 25%)<\/li>\n
          • Code (~= 15%)<\/li>\n
          • Other (~= 5%)<\/li>\n<\/ul>\n

             <\/p>\n

            Relative cost of bugs\u00a0<\/strong><\/p>\n

             <\/p>\n

            The bugs that are found at later phases cost more to fix. Cost to fix a bug increases exponentially (10x) i.e. it increases tenfold as time increases. E.g. a bug found during specification costs $1 to fix. If the bug is found in design cost is $10, if found in code cost is $100 and if found in released software cost is $1000. The cost keeps increasing tenfold as the time increases.<\/p>\n

             <\/p>\n

            Bug Free Software\u00a0<\/strong><\/p>\n

             <\/p>\n

            Software is in the news for the wrong reason such as security breach, Mars Lander lost, hackers getting credit card information, etc. The development of a bug free software is difficult when software gets more features and supports more platforms, it becomes increasingly difficult to make it create bug-free. The common questions that arise with the development of a bug free software are:<\/p>\n

             <\/p>\n

            \u25e6\u00a0 Why can\u2019t software engineers develop software that just works?<\/p>\n

            \u25e6\u00a0 Do you think bug free software is unattainable?<\/p>\n

            \u25e6\u00a0 Are their technical barriers that make this impossible?<\/p>\n

            \u25e6\u00a0 Is it just a question of time before we can do this?<\/p>\n

            \u25e6\u00a0 Are we missing technology or processes?<\/p>\n<\/div>\n

             <\/p>\n

            GOAL OF A SOFTWARE TESTER<\/strong><\/p>\n

             <\/p>\n

            The goals of a software tester is to find bugs as early in the software development processes as possible and make sure they get fixed. The software tester must be careful not to get caught in the dangerous spiral of unattainable perfection. The expectation on a software tester involves checking the following:<\/p>\n

              \n
            • Are they explorers?<\/li>\n
            • Are they troubleshooters?<\/li>\n
            • Are they relentless?<\/li>\n
            • Are they creative?<\/li>\n
            • Are they perfectionists (within reason)?<\/li>\n
            • Do they exercise good judgment?<\/li>\n
            • Are they tactful and diplomatic?<\/li>\n
            • Are they persuasive?<\/li>\n<\/ul>\n

               <\/p>\n

              TESTING<\/strong><\/p>\n

               <\/p>\n

              Testing is the confirming of correct behavior of a piece of software with respect to this context. Software testing is the evaluation of a system with the intention of finding an error or fault or a bug. It also checks for the functionalities of the system so that it meets the specified requirements. We know what we intended the code to do \u2013 we need to confirm that it does what we intended. Testing involves conducting test to ensure the production function correctly, but the test conducted must be looked into to check whether the tests are testing the right (relevant) \u201cstuff\u201d. The test is testing \u201cmost\u201d of the code and not just repeatedly testing the same code.<\/p>\n

               <\/p>\n

              Good Testing Practices<\/strong><\/p>\n

               <\/p>\n

              A good test case is one that has a high probability of detecting an undiscovered defect, not one that shows that the program works correctly. It is impossible to test your own program. A necessary part of every test case is a description of the expected result. Non-reproducible or on-the-fly testing is avoided. The test cases for valid as well as invalid input conditions are written and the results of each test are thoroughly inspected.<\/p>\n

               <\/p>\n

              Web Links<\/strong><\/p>\n

                \n
              • https:\/\/www.tutorialspoint.com\/software_testing\/software_testing_types.htm<\/li>\n
              • https:\/\/softwaretestingfundamentals.com<\/li>\n
              • www.softwaretestinghelp.com\/types-of-software-testing\/<\/li>\n<\/ul>\n

                 <\/p>\n

                Supporting & Reference Materials<\/strong><\/p>\n

                  \n
                • Roger S. Pressman, \u201cSoftware Engineering: A Practitioner\u2019s Approach\u201d, Fifth Edition, McGraw Hill, 2017.<\/li>\n
                • PankajJalote, \u201cAn Integrated Approach to Software Engineering\u201d, Second Edition, Springer Verlag, 1997.<\/li>\n
                • Ian Sommerville, \u201cSoftware Engineering\u201d, Sixth Edition, Addison Wesley, 2015.<\/li>\n<\/ul>\n","protected":false},"author":4,"menu_order":23,"template":"","meta":{"pb_show_title":"on","pb_short_title":"","pb_subtitle":"","pb_authors":["dr-r-baskaran"],"pb_section_license":""},"chapter-type":[],"contributor":[58],"license":[],"class_list":["post-232","chapter","type-chapter","status-publish","hentry","contributor-dr-r-baskaran"],"part":3,"_links":{"self":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters\/232","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters"}],"about":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/types\/chapter"}],"author":[{"embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/users\/4"}],"version-history":[{"count":5,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters\/232\/revisions"}],"predecessor-version":[{"id":404,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters\/232\/revisions\/404"}],"part":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/parts\/3"}],"metadata":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters\/232\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/media?parent=232"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapter-type?post=232"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/contributor?post=232"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/license?post=232"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}