Testing throughout the software life cycle (test levels)
- 1. TEST LEVELS Testing Throughout The Software Life Cycle Presented by Tyas Setyo Indria 11453201869 ProgramStudi S1 SistemInformasi Fakultas Sains Dan Teknologi UniversitasIslamSultanSyarif KasimRiau 2017 Reference Graham et.al (2006)
- 2. TEST LEVELS Compare the different levels of testing: major objectives, typical objects of testing, typical targets of testing (e.g. functional or structural) and rela ted work products, people who test, types of defects and failures to be i dentified. This section looks in more detail at the various test level. The key characteristics for each test level are discussed and defined to be able to more clearly separate the vario us test levels. A thorough understanding and definition of the various test levels will identify missing areas and prev ent overlap and repetition. Sometimes we may wish to int roduce deliberate overlap to address specific risks. Unde rstanding whether we want overlaps and removing the ga ps will make the test levels more complementary thus lea ding to more effective and efficient testing.
- 3. Component testing Component testing may be done in isolation from the res t of the system depending on the context of the develop ment life cycle and the system. Most often stubs and dri vers are used to replace the missing software and simul ate the interface between the software components in a simple manner. A stub is called from the software compo nent to be tested; a driver calls a component to be teste d (see Figure 2.5)
- 4. Component testing Typically, component testing occurs with access to the code bei ng tested and with the support of the development environment , such as a unit test framework or debugging tool, and in practic e usually involves the programmer who wrote the cod. Sometim es, depending on the applicable level of risk, component testing is carried out by a different programmer thereby introducing ind ependence. Defects are typically fixed as soon as they are found, without formally recording the incidents found. One approach in component testing, used in Extreme Programm ing (XP), is to prepare and automate test cases before coding. T his is called a test-first approach or test-driven development. T his approach is highly iterative and is based on cycles of develop ing test cases, then building and integrating small pieces of cod e, and executing the component tests until they pass.
- 5. Integration testing Integration testing tests interfaces between components, i nteractions to different parts of a system such as an operati ng system, file system and hardware or interfaces between systems. Note that integration testing should be differentiat ed from other integration activities. Integration testing is oft en carried out by the integrator, but preferably by a specific integration tester or test team. There may be more than one level of integration testing and it may b e carried out on test objects of varying size. For example: • component integration testing tests the interactions between softw are com ponents and is done after component testing; • system integration testing tests the interactions between different s ystems and may be done after system testing. In this case, the dev eloping organiza tion may control only one side of the interface, so changes may be destabilizing. Business processes implemented as workflows may involve a series of systems that can even run on diff erent platforms.
- 6. Integration testing One extreme is that all components or systems are integrated sim ultaneously, after which everything is tested as a whole. This is cal led 'big-bang' integration testing. Big-bang testing has the advant age that everything is finished before integration testing starts. Th ere is no need to simulate (as yet unfinished) parts. The major dis advantage is that in general it is time-consuming and difficult to tra ce the cause of failures with this late integration. A disadvantage is that it can be time-consuming since stubs and drivers have to be developed and used in the test. Within incremental integration testing a range of possibilities exist, partly depending on the system architecture: • Top-down: testing takes place from top to bottom, following the control flow or architectural structure (e.g. starting from the GUI or main menu). Components or systems are substituted b y stubs. • Bottom-up: testing takes place from the bottom of the control flow upwards. Components or systems are substituted by drivers. • Functional incremental: integration and testing takes place on the basis of the functions or fu nctionality, as documented in the functional specification. • The preferred integration sequence and the number of integration steps required depend on t he location in the architecture of the high-risk interfaces. The best choice is to start integratio n with those interfaces that are expected to cause most problems. Doing so prevents major d efects at the end of the integration test stage. In order to reduce the risk of late defect discov ery, integration should normally be incremental rather than 'big-bang'. Ideally testers should u nderstand the architecture and influence integration planning. If integration tests are planned before components or systems are built, they can be developed in the order required for most efficient testing.
- 7. System testing System testing is concerned with the behavior of the whol e system/product as defined by the scope of a developmen t project or product. It may include tests based on risks and /or requirements specification, business processes, use ca ses, or other high level descriptions of system behavior, int eractions with the operating system, and system resources. System testing should investigate both functional and non-fu nctional requirements of the system. Typical non-functional t ests include performance and reliability. Testers may also need to deal with incomplete or undocumented requirements. Syste m testing of functional requirements starts by using the most appropriate specification-based (black-box) techniques for the aspect of the system to be tested. For example, a decision tabl e may be created for combinations of effects described in busi ness rules. System testing requires a controlled test environment with re gard to, amongst other things, control of the software versions , testware and the test data
- 8. Acceptance testing When the development organization has performed its system test and has corrected all or most defects, the system will be delivered to the us er or customer for acceptance testing. Acceptance testing may occur at more than just a single l evel, for example: A Commercial Off The Shelf (COTS) software produc t may be acceptance tested when it is installed or integ rated. Acceptance testing of the usability of a component ma y be done during component testing. Acceptance testing of a new functional enhancement may come before system testing.
- 9. Acceptance testing Within the acceptance test for a business-supporting system, two main test types can be distinguished; as a result of their special character, they are u sually prepared and executed separately. The user acceptance test focuse s mainly on the functionality thereby validating the fitness-for-use of the sys tem by the business user, while the operational acceptance test (also call ed production acceptance test) validates whether the system meets the req uirements for operation. The user acceptance test is performed by the users and application manage rs. In terms of planning, the user acceptance test usually links tightly to the s ystem test and will, in many cases, be organized partly overlapping in time. I f the system to be tested consists of a number of more or less independent s ubsystems, the acceptance test for a subsystem that complies to the exit crit eria of the system test can start while another subsystem may still be in the system test phase. In most organizations, system administration will perform the operational acceptance test shortly before the system is released. The o perational acceptance test may include testing of backup/restore, disaster recovery, maintenance tasks and periodic check of security vulnerabilities.
- 10. Acceptance testing Other types of acceptance testing that exist are contract acceptance testing and co mpliance acceptance testing. Contract acceptance testing is performed against a contract's acceptance criteria for producing custom-developed software. Acceptanc e should be formally defined when the contract is agreed. Compliance acceptance t esting or regulation acceptance testing is performed against the regulations which must be adhered to, such as governmental, legal or safety regulations. If the system has been developed for the mass market, e.g. commercial off-the-shelf software (CO TS), then testing it for individual users or customers is not practical or even possible in some case s. Feedback is needed from potential or existing users in their market before the software product i s put out for sale commercially. Very often this type of system undergoes two stages of acceptance test. The first is called alpha testing. This test takes place at the developer's site. A cross-section of potential users and members of the developer's organization are invited to use the system. Dev elopers observe the users and note problems. Alpha testing may also be carried out by an indepen dent test team. Beta testing, or field testing, sends the system to a cross-section of users who inst all it and use it under real-world working conditions. The users send records of incidents with the s ystem to the development organization where the defects are repaired. Note that organizations may use other terms, such as factory acceptance testing and site accep tance testing for systems that are tested before and after being moved to a customer's site.
- 11. Backlink Website Kampus UIN Suska Riau JL. H.R Soebrantas No.155 KM.35 Simpang Baru Panam Pe kanbaru-Riau http://sif.uin-suska.ac.id/ http://fst.uin-suska.ac.id/ http://www.uin-suska.ac.id/
- 12. Thank you