Software Testing Curve

      Traditional CMMI or waterfall development model A common practice of software testing is that testing is performed by an independent group of testers after the functionality is developed before it is shipped to the customer. This practice often results in the testing phase being used as a project buffer to compensate for project delays, thereby compromising the time devoted to testing. Another practice is to start software testing at the same moment the project starts and it is a continuous process until the project finishes. Further information: Capability Maturity Model Integration and Waterfall model  Agile or Extreme development model In contrast, some emerging software disciplines such as extreme programming and the agile software development movement, adhere to a "test-driven software development" model. In this process, unit tests are written first, by the software engineers (often with pair programming in the extreme programming methodology). Of course, these te

         Installation testing Main article: Installation testing An installation test assures that the system is installed correctly and working at actual customer's hardware. Compatibility testing Main article: Compatibility testing A common cause of software failure (real or perceived) is a lack of its compatibility with other application software, operating systems (or operating system versions, old or new), or target environments that differ greatly from the original (such as a terminal or GUI application intended to be run on the desktop now being required to become a web application, which must render in a web browser). For example, in the case of a lack of backward compatibility, this can occur because the programmers develop and test software only on the latest version of the target environment, which not all users may be running. This results in the unintended consequence that the latest work may not function on earlier versions of the target environment, or on older hardw

  Top-down and bottom-up Bottom-Up Testing  is an approach to integrated testing where the lowest level components—modules, procedures or functions— are tested first, then integrated and used to facilitate the testing of higher-level components. After the integration testing of lower-level integrated modules, the next level of modules will be formed and can be used for integration testing. The process is repeated until the components at the top of the hierarchy are tested. This approach is helpful only when all or most of the modules of the same development level are ready. [ citation needed ]  This method also helps to determine the levels of software developed and makes it easier to report testing progress in the form of a percentage. [ citation needed ] Top-Down Testing  is an approach to integrated testing where the top integrated modules are tested and the branch of the module is tested step by step until the end of the related module. In both, method stubs and drivers are used to

  Testing levels      Tests are frequently grouped by where they are added in the software development process, or by the level of specificity of the test. The main levels during the development process as defined by the SWEBOK guide are unit-, integration-, and system testing that are distinguished by the test target without implying a specific process model. [30]  Other test levels are classified by the testing objective. Unit testing Main article: Unit testing Unit testing, also known as component testing, refers to tests that verify the functionality of a specific section of code, usually at the function level. In an object-oriented environment, this is usually at the class level, and the minimal unit tests include the constructors and destructors. [31] These types of tests are usually written by developers as they work on code (white-box style), to ensure that the specific function is working as expected. One function might have multiple tests, to catch corner cases or other branc

  Testing methods

  Automated testing Main article: Test automation Many programming groups are relying more and more on automated testing, especially groups that use test-driven development. There are many frameworks to write tests in, and continuous integration software will run tests automatically every time code is checked into a version control system. While automation cannot reproduce everything that a human can do (and all the ways they think of doing it), it can be very useful for regression testing. However, it does require a well-developed test suite of testing scripts in order to be truly useful. Testing tools Program testing and fault detection can be aided significantly by testing tools and debuggers. Testing/debug tools include features such as: ·          Program monitors, permitting full or partial monitoring of program code including: ·           Instruction set simulator, permitting complete instruction-level monitoring and trace facilities ·           Program animation, permitting ste