![Testing of software product characteri
stics (non-functional testing)
Non-functional testing, as functional testing, is performed at all test levels. Non-fu
nctional testing includes, but is not limited to, performance testing, load testing,
stress testing, usability testing, maintainability testing, reliability testing and porta
bility testing. It is the testing of 'how well' the system works.
Many have tried to capture software quality in a collection of characteristics a
nd related sub-characteristics. In these models some elementary characteristic
s keep on reappearing, although their place in the hierarchy can differ. The Int
ernational Organization for Standardization (ISO) has defined a set of quality c
haracteristics [ISO/IEC 9126, 2001]. This set reflects a major step towards cons
ensus in the IT industry and thereby addresses the general notion of software
quality. The ISO 9126 standard defines six quality characteristics and the sub
division of each quality characteristic into a number of sub-characteristics. This
standard is getting more and more recognition in the industry, enabling devel
opment, testing and their stakeholders to use a common terminology for quali
ty characteristics and thereby for non-functional testing.](https://image.slidesharecdn.com/testingthroughoutthesoftwarelifecycletesttypes-171210210525/85/Testing-throughout-the-software-life-cycle-test-types-6-320.jpg)
Testing throughout the software life cycle (test types)
- 1. Testing Throughout The Software Life Cycle Presented by Tyas Setyo Indria 11453201869 ProgramStudiS1 SistemInformasi FakultasSainsDanTeknologi UniversitasIslamSultanSyarif KasimRiau 2017 TEST TYPES: THE TARGETS OF TESTING Reference Graham et.al (2006)
- 2. Test types are introduced as a means of clearly defining the objective of a certain test level for a programme or project. We need to think about different types of testing because testing the func tionality of the component or system may not be sufficient at each level to meet the overall test objectives. Focusing the testing on a specific test objective and, therefore, selecting the appropria te type of test helps making and communicating decisions against test objectives easier. A test type is focused on a particular test objective, which could be the testing of a function to b e performed by the component or system; a non-functional quality characteristic, such as reliabilit y or usability; the structure or architecture of the component or system; or related to changes, i.e. confirming that defects have been fixed (confirmation testing, or re-testing) and looking for unint ended changes (regression testing). Depending on its objectives, testing will be organized differen tly. For example, component testing aimed at performance would be quite different to componen t testing aimed at achieving decision coverage. Test Type
- 3. Testing of function (functional testing) Functional testing considers the specified behavior and i s often also referred to as black-box testing. This is not entirely true, since black-box testing also includes non-fu nctional testing The function of a system (or component) is 'what it does'. Th is is typically described in a requirements specification, a fun ctional specification, or in use cases. There may be some fun ctions that are 'assumed' to be provided that are not docum ented that are also part of the requirement for a system, tho ugh it is difficult to test against undocumented and implicit r equirements. Functional tests are based on these functions, d escribed in documents or understood by the testers and may be performed at all test levels (e.g. test for components may be based on a component specification).
- 4. Testing of function (functional testing) Function (or functionality) testing can, based upon ISO 9126 , be d one focusing on suitability, interoperability, security, accuracy and compliance. Security testing, for example, investigates the functions (e.g. a firewall) relating to detection of threats, such as viruses, from malicious outsiders It has been replaced by ISO/IEC 25010:2011
- 5. Testing of function (functional testing) Testing functionality can be done from two perspectives: requirements-based or business-process-based. Requirements-based testing uses a specification of the functional requirements for the system as the basis for designing tests. A good way to start is to use the table of contents of the requirements specification as an initial test inventory or list of items to test (or not to test). We should also prioritize the requirements b ased on risk criteria (if this is not already done in the specification) and use this to prioritize the tests. This will ensure that the most important and most critical tests are included in the testing effort. Business-process-based testing uses knowledge of the business processes. Busi ness processes describe the scenarios involved in the day-to-day business use of the system. For example, a personnel and payroll system may have a business pr ocess along the lines of: someone joins the company, he or she is paid on a reg ular basis, and he or she finally leaves the company. Use cases originate from ob ject-oriented development, but are nowadays popular in many development life cycles. They also take the business processes as a starting point, although they s tart from tasks to be performed by users. Use cases are a very useful basis for te st cases from a business perspective.
- 6. Testing of software product characteri stics (non-functional testing) Non-functional testing, as functional testing, is performed at all test levels. Non-fu nctional testing includes, but is not limited to, performance testing, load testing, stress testing, usability testing, maintainability testing, reliability testing and porta bility testing. It is the testing of 'how well' the system works. Many have tried to capture software quality in a collection of characteristics a nd related sub-characteristics. In these models some elementary characteristic s keep on reappearing, although their place in the hierarchy can differ. The Int ernational Organization for Standardization (ISO) has defined a set of quality c haracteristics [ISO/IEC 9126, 2001]. This set reflects a major step towards cons ensus in the IT industry and thereby addresses the general notion of software quality. The ISO 9126 standard defines six quality characteristics and the sub division of each quality characteristic into a number of sub-characteristics. This standard is getting more and more recognition in the industry, enabling devel opment, testing and their stakeholders to use a common terminology for quali ty characteristics and thereby for non-functional testing.
- 7. Testing of software product chara cteristics (non-functional testing) The characteristics and their sub-characteristics are, respectively: functionality, which consists of five sub-characteristics: suitability, accuracy, security, interoperability and compliance; this characteristic deals with func tional testing as described in Section 2.3.1; reliability, which is defined further into the sub-characteristics maturity (ro bustness), fault-tolerance, recoverability and compliance; usability, which is divided into the sub-characteristics understandability, le arnability, operability, attractiveness and compliance; efficiency, which is divided into time behavior (performance), resource uti l ization and compliance; maintainability, which consists of five sub-characteristics: analyzability, cha ngeability, stability, testability and compliance; portability, which also consists of five sub-characteristics: adaptability, inst allability, co-existence, replaceability and compliance.
- 8. Testing of software structure/architec ture (structural testing) The third target of testing is the structure of the system or compone nt. If we are talking about the structure of a system, we may call it th e system architecture. Structural testing is often referred to as 'white -box' or 'glass-box' because we are interested in what is happening ' inside the box'. At component level, and to a lesser extent at component integration testing, t here is good tool support to measure code coverage. Coverage measurement tools assess the percentage of executable elements (e.g. statements or decisio n outcomes) that have been exercised (i.e. covered) by a test suite. If coverag e is not 100%, then additional tests may need to be written and run to cover t hose parts that have not yet been exercised. This of course depends on the ex it criteria. The techniques used for structural testing are structure-based techniques, also referred to as white-box techniques. Control flow models are often used to s upport structural testing.
- 9. Testing related to changes (confirmati on and regression testing) Confirmation testing (re-testing) When a test fails and we determine that the cause of the failure is a software defect, the defect is reported, and we can expect a new version of the softwar e that has had the defect fixed. In this case we will need to execute the test a gain to confirm that the defect has indeed been fixed. This is known as confir mation testing (also known as re-testing). When doing confirmation testing, it is important to ensure that the test is exe cuted in exactly the same way as it was the first time, using the same inputs, data and environment. If the test now passes does this mean that the software is now correct? Well, we now know that at least one part of the software is cor rect where the defect was. But this is not enough. The fix may have introduced or uncovered a different defect elsewhere in the software. The way to detect t hese 'unexpected side-effects' of fixes is to do regression testing.
- 10. Testing of software structure/architect ure (structural testing) Regression testing The term 'regression testing' is something of a misnomer. It would be better if it w ere called 'anti-regression' testing because we are executing tests with the intent of checking that the system has not regressed (that is, it does not now have more defe cts in it as a result of some change). More specifically, the purpose of regression test ing is to verify that modifications in the software or the environment have not cause d unintended adverse side effects and that the system still meets its requirements. It is common for organizations to have what is usually called a regression test suite or regression test pack. This is a set of test cases that is specifically used for regressi on testing. They are designed to collectively exercise most functions (certainly the m ost important ones) in a system but not test any one in detail. It is appropriate to h ave a regression test suite at every level of testing (component testing, integration t esting, system testing, etc.). All of the test cases in a regression test suite would be executed every time a new version of software is produced and this makes them ide al candidates for automation. If the regression test suite is very large it may be mor e appropriate to select a subset for execution.
- 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