{"id":245,"date":"2018-07-25T04:29:27","date_gmt":"2018-07-25T04:29:27","guid":{"rendered":"http:\/\/csp8.epgpbooks.inflibnet.ac.in\/?post_type=chapter&p=245"},"modified":"2018-08-08T05:41:16","modified_gmt":"2018-08-08T05:41:16","slug":"fundamentals-of-software-testing-iii","status":"publish","type":"chapter","link":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/chapter\/fundamentals-of-software-testing-iii\/","title":{"rendered":"Fundamentals of Software Testing III"},"content":{"raw":"
\r\n\r\n \r\n

FUNDAMENTALS OF SOFTWARE TESTING<\/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 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

STAGES OF TESTING\u00a0<\/strong><\/p>\r\n \r\n

Various testing is done during various phases of the development cycle such as:<\/p>\r\n \r\n

\u00b7\u00a0 Module or unit testing.<\/p>\r\n

\u00b7\u00a0 Integration testing,<\/p>\r\n

\u00b7\u00a0 Function testing.<\/p>\r\n

\u00b7\u00a0 Performance testing.<\/p>\r\n

\u00b7\u00a0 Acceptance testing.<\/p>\r\n

\u00b7\u00a0 Installation testing.<\/p>\r\n\r\n<\/div>\r\n

\r\n\r\n\"\"\r\n\r\nUNIT TESTING\u00a0<\/strong>\r\n\r\n \r\n\r\nUnit testing is the testing and validation at the unit level. Unit testing validates and tests the following:\r\n\r\n \r\n\r\n\u00b7\u00a0 Algorithms and logic\r\n\r\n\u00b7\u00a0 Data structures (global and local)\r\n\r\n\u00b7\u00a0 Interfaces\r\n\r\n\u00b7\u00a0 Independent paths\r\n\r\n\u00b7\u00a0 Boundary conditions\r\n\r\n\u00b7\u00a0 Error handling\r\n\r\n\u00b7\u00a0 Formal verification.\r\n\r\n\u00b7\u00a0 Testing the program itself by performing black box and white box testing.\r\n\r\n \r\n\r\n\"\"\r\n\r\nINTEGRATION TESTING\u00a0<\/strong>\r\n\r\n \r\n

One module can have an adverse effect on another. Sub-functions, when combined, may not produce the desired major function. Individually acceptable imprecision in calculations may be magnified to unacceptable levels. Interfacing errors not detected in unit testing may appear in this\u00a0phase. Timing problems (in real-time systems) and resource contention problems are not detectable by unit testing.<\/span><\/p>\r\n\r\n<\/div>\r\n

\r\n\r\n \r\n\r\nTop-Down Integration\u00a0<\/strong>\r\n\r\n \r\n

The main control module is used as a driver, and stubs are substituted for all modules directly subordinate to the main module. Depending on the integration approach selected (depth or breadth first), subordinate stubs are replaced by modules one at a time. Tests are run as each individual module is integrated. On the successful completion of a set of tests, another stub is replaced with a real module. Regression testing is performed to ensure that errors have not developed as result of integrating new modules.<\/p>\r\n\"\"\r\n\r\nProblems with Top-Down Integration\u00a0<\/strong>\r\n\r\n \r\n\r\nAdvantages<\/strong>: No test stubs are needed, Errors in critical modules are found early.\r\n\r\n \r\n\r\nDisadvantages: <\/strong>Test drivers are needed, Interface errors are discovered late.\r\n\r\n \r\n\r\nBottom-Up Integration\u00a0<\/strong>\r\n\r\n \r\n

Integration begins with the lowest-level modules, which are combined into clusters, or builds, that perform specific software sub-function. Drivers (control programs developed as stubs) are written to coordinate test case input and output. The cluster is tested. Drivers are removed and clusters are combined moving upward in the program structure.<\/p>\r\n\r\n<\/div>\r\n

\r\n\r\n \r\n\r\nVALIDATION TESTING\u00a0<\/strong>\r\n\r\n \r\n

Validation testing determines if the software meets all of the requirements defined in the SRS. Writing down the requirements is very essential. Regression testing is performed to determine if the software still meets all of its requirements in light of changes and modifications to the software. Regression testing involves selectively repeating existing validation tests, not developing new tests.<\/p>\r\n \r\n\r\nALPHA AND BETA TESTING\u00a0<\/strong>\r\n\r\n \r\n

It\u2019s best to provide customers with an outline of the things that you would like them to focus on and specific test scenarios for them to execute. Provide with customers who are actively involved with a commitment to fix defects that they discover.<\/p>\r\n \r\n\r\nACCEPTANCE TESTING\u00a0<\/strong>\r\n\r\n \r\n

Acceptance testing is similar to validation testing except that customers are present or directly involved. Usually these tests are developed by the customer<\/p>\r\n \r\n\r\nTEST METHODS\u00a0<\/strong>\r\n\r\n \r\n\r\nTest methods include the following:\r\n\r\n \r\n\r\n\u00b7\u00a0 White box or glass box testing\r\n\r\n\u00b7\u00a0 Black box testing\r\n\r\n\u00b7\u00a0 Top-down and bottom-up for performing incremental integration\r\n\r\n\u00b7\u00a0 ALAC (Act-Like-A-Customer)\r\n\r\n \r\n\r\nTest Types\u00a0<\/strong>\r\n\r\n \r\n\r\nThe types of tests include:\r\n\r\n \r\n\r\n\u00b7\u00a0 Functional tests\r\n\r\n\u00b7\u00a0 Algorithmic tests\r\n\r\n\u00b7\u00a0 Positive tests\r\n\r\n\u00b7\u00a0 Negative tests\r\n\r\n\u00b7\u00a0 Usability tests\r\n\r\n\u00b7\u00a0 Boundary tests<\/span>\r\n\r\n\u00b7\u00a0 Startup\/shutdown tests<\/span>\r\n\r\n\u00b7\u00a0 Platform tests<\/span>\r\n\r\n\u00b7\u00a0 Load\/stress tests<\/span>\r\n\r\n<\/div>\r\n

\r\n\r\n \r\n\r\nCONCURRENT DEVELOPMENT\/ VALIDATION TESTING MODEL\u00a0<\/strong>\r\n\r\n \r\n

Concurrent testing involves conducting informal validation while development is still going on. It provides an opportunity for validation tests to be developed and debugged early in the software development process which results in formal validation being less eventful, since most of the problems have already been found and fixed. This model provides early feedback to software engineers<\/p>\r\n \r\n\r\nValidation Readiness Review\u00a0<\/strong>\r\n\r\n \r\n\r\n\u00b7\u00a0 During informal validation developers can make any changes needed in order to comply with the SRS.\r\n\r\n\u00b7\u00a0 During informal validation QA runs tests and makes changes as necessary in order for tests to comply with the SRS.\r\n\r\n\u00b7\u00a0 During formal validation the only changes that can be made are bug fixes in response to bugs reported during formal validation testing. No new features can be added at this time.\r\n\r\n\u00b7\u00a0 During formal validation the same set of tests run during informal validation is run again.\r\n\r\n \r\n\r\nNo new tests are added.\r\n\r\n \r\n\r\nEntrance Criteria for Formal Validation Testing<\/strong>\r\n\r\n \r\n\r\nThe entrance criteria for formal validation testing are as follows:\r\n

    \r\n \t
  • Software development must be completed (a precise definition of \u201ccompleted\u201d is required).<\/li>\r\n \t
  • The test plan must be reviewed, approved and is under document control.<\/li>\r\n \t
  • A requirements inspection should have been performed on the SRS.<\/li>\r\n \t
  • Design \u00a0inspections \u00a0should \u00a0have \u00a0been \u00a0performed \u00a0on \u00a0the \u00a0SDDs \u00a0(Software \u00a0Design Descriptions).<\/li>\r\n \t
  • Code inspections must performed on all \u201ccritical modules\u201d.<\/li>\r\n \t
  • All test scripts should be completed and the software validation test procedure document should be reviewed, approved, and placed under document control.<\/li>\r\n \t
  • Selected test scripts should be reviewed, approved and placed under document control.<\/li>\r\n \t
  • All test scripts should have been executed at least once.<\/li>\r\n \t
  • CM tools must be in place and all source code should be under configuration control.<\/li>\r\n \t
  • Software problem reporting procedures should be in place.<\/li>\r\n \t
  • Validation testing completion criteria should be developed, reviewed, and approved.<\/li>\r\n<\/ul>\r\n<\/div>\r\n \r\n

    Formal Validation<\/strong><\/p>\r\n \r\n

    During formal validation, the same tests that were run during informal validation are executed again and the results recorded. Software Problem Reports (SPRs) are submitted for each test that fails. SPR tracking is performed and includes the status of all SPRs (i.e., open, fixed, verified, deferred, not a bug). For each bug fixed, the SPR identifies the modules that were changed to fix the bug. Baseline change assessment is used to ensure only modules that should have changed have changed and no new features have slipped in.<\/p>\r\n \r\n

    Informal code reviews are selectively conducted on changed modules to ensure that new bugs are not being introduced. Time required to find and fix bugs (find-fix cycle time) is tracked. Regression testing is performed using the following guidelines:<\/p>\r\n\r\n

      \r\n \t
    • Use complexity measures to help determine which modules may need additional testing<\/li>\r\n \t
    • Use judgment to decide which tests to be rerun<\/li>\r\n \t
    • Base decision on knowledge of software design and past history<\/li>\r\n<\/ul>\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, 2001.<\/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, 2000.<\/li>\r\n<\/ul>\r\n ","rendered":"
          \n

           <\/p>\n

          FUNDAMENTALS OF SOFTWARE TESTING<\/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 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

          STAGES OF TESTING\u00a0<\/strong><\/p>\n

           <\/p>\n

          Various testing is done during various phases of the development cycle such as:<\/p>\n

           <\/p>\n

          \u00b7\u00a0 Module or unit testing.<\/p>\n

          \u00b7\u00a0 Integration testing,<\/p>\n

          \u00b7\u00a0 Function testing.<\/p>\n

          \u00b7\u00a0 Performance testing.<\/p>\n

          \u00b7\u00a0 Acceptance testing.<\/p>\n

          \u00b7\u00a0 Installation testing.<\/p>\n<\/div>\n

          \n

          \"\"<\/p>\n

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

           <\/p>\n

          Unit testing is the testing and validation at the unit level. Unit testing validates and tests the following:<\/p>\n

           <\/p>\n

          \u00b7\u00a0 Algorithms and logic<\/p>\n

          \u00b7\u00a0 Data structures (global and local)<\/p>\n

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

          \u00b7\u00a0 Independent paths<\/p>\n

          \u00b7\u00a0 Boundary conditions<\/p>\n

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

          \u00b7\u00a0 Formal verification.<\/p>\n

          \u00b7\u00a0 Testing the program itself by performing black box and white box testing.<\/p>\n

           <\/p>\n

          \"\"<\/p>\n

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

           <\/p>\n

          One module can have an adverse effect on another. Sub-functions, when combined, may not produce the desired major function. Individually acceptable imprecision in calculations may be magnified to unacceptable levels. Interfacing errors not detected in unit testing may appear in this\u00a0phase. Timing problems (in real-time systems) and resource contention problems are not detectable by unit testing.<\/span><\/p>\n<\/div>\n

          \n

           <\/p>\n

          Top-Down Integration\u00a0<\/strong><\/p>\n

           <\/p>\n

          The main control module is used as a driver, and stubs are substituted for all modules directly subordinate to the main module. Depending on the integration approach selected (depth or breadth first), subordinate stubs are replaced by modules one at a time. Tests are run as each individual module is integrated. On the successful completion of a set of tests, another stub is replaced with a real module. Regression testing is performed to ensure that errors have not developed as result of integrating new modules.<\/p>\n

          \"\"<\/p>\n

          Problems with Top-Down Integration\u00a0<\/strong><\/p>\n

           <\/p>\n

          Advantages<\/strong>: No test stubs are needed, Errors in critical modules are found early.<\/p>\n

           <\/p>\n

          Disadvantages: <\/strong>Test drivers are needed, Interface errors are discovered late.<\/p>\n

           <\/p>\n

          Bottom-Up Integration\u00a0<\/strong><\/p>\n

           <\/p>\n

          Integration begins with the lowest-level modules, which are combined into clusters, or builds, that perform specific software sub-function. Drivers (control programs developed as stubs) are written to coordinate test case input and output. The cluster is tested. Drivers are removed and clusters are combined moving upward in the program structure.<\/p>\n<\/div>\n

          \n

           <\/p>\n

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

           <\/p>\n

          Validation testing determines if the software meets all of the requirements defined in the SRS. Writing down the requirements is very essential. Regression testing is performed to determine if the software still meets all of its requirements in light of changes and modifications to the software. Regression testing involves selectively repeating existing validation tests, not developing new tests.<\/p>\n

           <\/p>\n

          ALPHA AND BETA TESTING\u00a0<\/strong><\/p>\n

           <\/p>\n

          It\u2019s best to provide customers with an outline of the things that you would like them to focus on and specific test scenarios for them to execute. Provide with customers who are actively involved with a commitment to fix defects that they discover.<\/p>\n

           <\/p>\n

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

           <\/p>\n

          Acceptance testing is similar to validation testing except that customers are present or directly involved. Usually these tests are developed by the customer<\/p>\n

           <\/p>\n

          TEST METHODS\u00a0<\/strong><\/p>\n

           <\/p>\n

          Test methods include the following:<\/p>\n

           <\/p>\n

          \u00b7\u00a0 White box or glass box testing<\/p>\n

          \u00b7\u00a0 Black box testing<\/p>\n

          \u00b7\u00a0 Top-down and bottom-up for performing incremental integration<\/p>\n

          \u00b7\u00a0 ALAC (Act-Like-A-Customer)<\/p>\n

           <\/p>\n

          Test Types\u00a0<\/strong><\/p>\n

           <\/p>\n

          The types of tests include:<\/p>\n

           <\/p>\n

          \u00b7\u00a0 Functional tests<\/p>\n

          \u00b7\u00a0 Algorithmic tests<\/p>\n

          \u00b7\u00a0 Positive tests<\/p>\n

          \u00b7\u00a0 Negative tests<\/p>\n

          \u00b7\u00a0 Usability tests<\/p>\n

          \u00b7\u00a0 Boundary tests<\/span><\/p>\n

          \u00b7\u00a0 Startup\/shutdown tests<\/span><\/p>\n

          \u00b7\u00a0 Platform tests<\/span><\/p>\n

          \u00b7\u00a0 Load\/stress tests<\/span><\/p>\n<\/div>\n

          \n

           <\/p>\n

          CONCURRENT DEVELOPMENT\/ VALIDATION TESTING MODEL\u00a0<\/strong><\/p>\n

           <\/p>\n

          Concurrent testing involves conducting informal validation while development is still going on. It provides an opportunity for validation tests to be developed and debugged early in the software development process which results in formal validation being less eventful, since most of the problems have already been found and fixed. This model provides early feedback to software engineers<\/p>\n

           <\/p>\n

          Validation Readiness Review\u00a0<\/strong><\/p>\n

           <\/p>\n

          \u00b7\u00a0 During informal validation developers can make any changes needed in order to comply with the SRS.<\/p>\n

          \u00b7\u00a0 During informal validation QA runs tests and makes changes as necessary in order for tests to comply with the SRS.<\/p>\n

          \u00b7\u00a0 During formal validation the only changes that can be made are bug fixes in response to bugs reported during formal validation testing. No new features can be added at this time.<\/p>\n

          \u00b7\u00a0 During formal validation the same set of tests run during informal validation is run again.<\/p>\n

           <\/p>\n

          No new tests are added.<\/p>\n

           <\/p>\n

          Entrance Criteria for Formal Validation Testing<\/strong><\/p>\n

           <\/p>\n

          The entrance criteria for formal validation testing are as follows:<\/p>\n

            \n
          • Software development must be completed (a precise definition of \u201ccompleted\u201d is required).<\/li>\n
          • The test plan must be reviewed, approved and is under document control.<\/li>\n
          • A requirements inspection should have been performed on the SRS.<\/li>\n
          • Design \u00a0inspections \u00a0should \u00a0have \u00a0been \u00a0performed \u00a0on \u00a0the \u00a0SDDs \u00a0(Software \u00a0Design Descriptions).<\/li>\n
          • Code inspections must performed on all \u201ccritical modules\u201d.<\/li>\n
          • All test scripts should be completed and the software validation test procedure document should be reviewed, approved, and placed under document control.<\/li>\n
          • Selected test scripts should be reviewed, approved and placed under document control.<\/li>\n
          • All test scripts should have been executed at least once.<\/li>\n
          • CM tools must be in place and all source code should be under configuration control.<\/li>\n
          • Software problem reporting procedures should be in place.<\/li>\n
          • Validation testing completion criteria should be developed, reviewed, and approved.<\/li>\n<\/ul>\n<\/div>\n

             <\/p>\n

            Formal Validation<\/strong><\/p>\n

             <\/p>\n

            During formal validation, the same tests that were run during informal validation are executed again and the results recorded. Software Problem Reports (SPRs) are submitted for each test that fails. SPR tracking is performed and includes the status of all SPRs (i.e., open, fixed, verified, deferred, not a bug). For each bug fixed, the SPR identifies the modules that were changed to fix the bug. Baseline change assessment is used to ensure only modules that should have changed have changed and no new features have slipped in.<\/p>\n

             <\/p>\n

            Informal code reviews are selectively conducted on changed modules to ensure that new bugs are not being introduced. Time required to find and fix bugs (find-fix cycle time) is tracked. Regression testing is performed using the following guidelines:<\/p>\n

              \n
            • Use complexity measures to help determine which modules may need additional testing<\/li>\n
            • Use judgment to decide which tests to be rerun<\/li>\n
            • Base decision on knowledge of software design and past history<\/li>\n<\/ul>\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, 2001.<\/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, 2000.<\/li>\n<\/ul>\n

                   <\/p>\n","protected":false},"author":4,"menu_order":25,"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-245","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\/245","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\/245\/revisions"}],"predecessor-version":[{"id":406,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapters\/245\/revisions\/406"}],"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\/245\/metadata\/"}],"wp:attachment":[{"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/media?parent=245"}],"wp:term":[{"taxonomy":"chapter-type","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/pressbooks\/v2\/chapter-type?post=245"},{"taxonomy":"contributor","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/contributor?post=245"},{"taxonomy":"license","embeddable":true,"href":"https:\/\/ebooks.inflibnet.ac.in\/csp8\/wp-json\/wp\/v2\/license?post=245"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}