International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.4, July 2012
ISSUES IN TESTING
OF
SOFTWARE
WITH
NFR
Pratima Singh 1 and Anil Kumar Kumar Tripat Tripathi hi 2 1 2
Department Department of Computer Computer Engineeri Engineering, ng, IIT (BHU).Var (BHU).Varanasi, anasi, U.P. U.P. India
[email protected] pratima.singh.rs.
[email protected] .in
Department of Computer Engineering, Engineering, IIT (BHU).Varanasi, U.P. India India
[email protected] [email protected]
A BSTRACT Software Development has started experiencing the need of consideration of NFR (Non Functional Requirements) for producing high quality acceptable software. Mostly software engineering literature has cons consid ider ered ed only only for for test testing ing Functi Function onal al Requi Require remen ments ts.. In cont context ext of of such such a need need this this work work att attemp empts ts to consider NFR, resulting from quality quality concerns of stakeholder, stakeholder, along with their impact and effect on testing .We identi identify fy and bring bring out issues issues,, in in test testing ing of NFR that that warran warrant, t, purp purpose oseful ful and meanin meaningfu gfull considerations.
EYWORDS K Testing Testing issues, issues, Non-fun Non-functiona ctionall Requireme Requirements, nts, Testability, Testability, FR (Function (Functional al Requirem Requirement.), ent.), Goal Centric Centric Traceability (GCT), GRL (Goal Oriented Requirement Language), SIG (Soft goal Interdependency Graph), soft goal.
1. INTRODUCTION Testing happens to be an important phase in software development lifecycle. It consumes around 70% of resource resource required required for for developing developing a softwar softwaree system. system. [1,2,4,5 [1,2,4,5,6,7,8]. ,6,7,8]. According According to Brian Brian Lawrence[48] , among the top 10 risks risks of Requirement Requirement Engineering is “Overlooking a crucial requirement” and “Modelli unctional Requirements”. As stated by L. M. cysnerio[10] Modelling ng only F ”Although Non-Functional Requirements (NFR) have been present in many software developmen developmentt methods, methods, they they have been treated treated as a second second or even even third class class of requirem requirement, ent, frequently hidden inside notes and and therefore frequently frequently neglected or forgotten.” forgotten.” Surprisingly, despite the fact that non functional requirements (NFR) are are among the most expensive expensive and diffic difficult ult to deal deal with, with, even even today today there there are are only some some work work that that focus focus on NFR NFR as first first class class requirements” Chung[16]stated ”Surprisingly NFR has received little attention by research and definitely less well understood than other less critical factors in software development”. It is universally accepted fact that NFR NFR play very dominant role in acceptability of software, but they have been been treated very very off handily, handily, by industry industry for long, until until they realized realized the fact fact that NFR cannot be neglected further, because NFR not satisfied, results into low acceptability which goes goes against the product because of increasing competitive market, expectations of stakeholders, failures failures of of various various critica criticall system. system. [12]. [12]. In In literature literature ambulance ambulance case[3 case[39], 9], Moose-tes Moose-testt of the the Merce Mercedes des Benz Benz A Class Class [17] and and the Siem Siemens ens mobil mobile[4 e[40] 0] have have been been commonly commonly discus discussed sed with with refere reference nce to softwa software re system systemss not being acceptable beca becaus usee of neglig negligen ence ce of NFR NFR..“Essentially softwa software re utility utility is deter determin mined ed by both both FR and NFR NFR nonet nonethel heless ess,, there there have have been been more emphas emphasis is on FR and its testing testing,, even even though though FR is not useful useful without without NFR NFR.” In an NFR survey by Fridge DOI : 10.5121/ijsea.2012.3405
61
International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.4, J uly 2012
and Liste isterr [38 [38]] it is state tated d that “most startling and disturbing, deficiency is the shortage of measur measuree for Specification and design methodology of any form of NFR.” These are reasons enough for Software Engineering research community to take NFR as a resea research rch theme theme and look look into the the issues issues,, challe challenges nges and and proble problems ms in handlin handling g NFR while while,, specificat specification, ion, designing, designing, coding coding and testing of software software systems. systems. With such an intention intention this work attempts attempts to answer answer some possible possible Research Research Questio Questions: ns: 1) What are the problems in handling NFR? 2) What What are the problems problems in testing testing a softwa software re with NFR? NFR? Based Based on the above said, the rest of the papers papers are organized, organized, as follows: follows: Section Section 2: Issues Issues and challenges challenges of of handling handling NFR NFR in software software development development process. process. Section Section 3: Literature Literature Survey: Survey: Current Current methods methods to handle handle NFR NFR at various various stages of developme development. nt. Section Section 4: Issues Issues and challenges challenges of Software Software Testing Testing with NFR. NFR. Section Section 5: Difference Difference between between NFR testing and FR Testing Testing.. Sect Section6 ion6:: Futur Futuree Resear Research ch Direc Direction tions. s. Sectio Section n 7: Conclu Conclusio sions ns and Observ Observatio ations. ns. Section8: Future Research Directions.
2. ISSU ISSUES ES AND CHALLENGES OF HANDLIN HANDLING G NFR IN SOFTWARE DEVELOPMENT. Non functional requirements refer to a whole list of "ileitis" such as usability, reliability and availability, apart from some others such as performance and security. [10, [10, 12, 16, 19]. There is no universally accepted definition of NFR [12] “NFR not only introduce quality factors but also represent global constrains under which a system must operate”. They are global in the sense that they arise from all parts of the system and from their interactions. [11,16]. NFR are also known as Quality Requirements [27,10] and unlike Functional Requirements that address specific problems and are are the there refo fore re typ typic icaally lly impl impleement menteed thr throug ough part partic icul ulaar loca locali lizzed modul odulees or components.NFR provide the justifications for design decisions and constraints showing the way in which the required functionality may be realized, for satisfying the associated quality concerns of the stakeholders.[10,11,16,14,5,50,12,].
Issue No1: Identification of NFR. Challenges: NFR NFR are too soft soft or subjec subjective tive to be identi identifie fied d clearl clearly. y. [13] [13].. They They are are very very cas casuall ually y
treated treated as they are hidden hidden somewhere, somewhere, in the software software specificati specifications ons or mentioned mentioned in form of commen comments ts or or some some speci special al require requiremen ments ts in SRS SRS [13] [13] .They .They are are too “fuzzy” and as late thought thought even in the minds of stakeholders.
Handling the the Diversity Diversity of NFR. Issue No2: Handling Challenges: Great Great diversity diversity in no and type of of NFR NFR makes makes it diffic difficult ult to be handled handled by a commo common n
methodology methodology.. Various Various quality concer concerns ns of stakehold stakeholders ers have have their specific specific associate associated d constraints, constraints, resource resource requiremen requirementt for their specifica specification, tion, designin designing g and testing. testing. This problem problem of diversity, diversity, can be seen appearin appearing g in several several work work [5, 44] done in an an attempt attempt to be able to clearly clearly classify classify NFR NFR on several several possible possible basis but still still having having no clear-cut clear-cut definit definition ion of NFR [45]
Issue no3: Interplays among NFR. Challenges: Conflicting interplays interplays among NFR where one NFR NFR impacts negatively negatively or
positively positively on on other, other, conflicts conflicts resolution resolution among NFR is a problem problem [13,3,10 [13,3,10,14,1 ,14,16] 6] 62
International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.4, J uly 2012
Issue 4: NFR affecting Design decisions decisions specifications.
plays very import important ant role role in justifi justificat cation ion of of a design design decisio decisions. ns.[29 [29]] Chal Challe leng nges: es: NFR NFR plays Design Design decisions decisions are based on both NFR and FR , but NFR helps in justification justification of of particular choice of design decision[52] Problems of scope of of FR and NFR. Issue 5 Problems Challenges: The two extreme cases of representation representation of Requirements, as use case or misuse cases cases which needs to be separat separately ely understood understood.. Misuse Misuse case case are there there to repre represent sent negative negative cases (generally used for security security based NFR) which behaves behaves as a constraint or limiting boundary for use cases.[20,28,36]
Issue 6: Ambiguous specification in software requirement specification (SRS). Challenge: Challenge: SRS is the origin origin of of all syste system m related related errors. errors. Two Two extreme extremess associate associated d with specification of NFR can be Formal method specification or Natural language specification. Natural language specification is easy but inherently ambiguous, contradictory to Formal Method specification which is unambiguous but difficult to deal deal with because of required mathematical mathematical “proof of concept concept” [5].
Issue Issue 7: Traceab Traceabilit ility y among among NFR design, design, code and and test test cases. cases. Challenge Challenge : Due Due to seemingly seemingly insignif insignificant icant prese presence nce of NFR NFR at the specificat specification ion stage, stage, where where a FR specification dominates dominates the scene, scene, it is a challenge to save save NFR from Omission error [14],and [14],and provide provide traceability traceability of Non Functional Functional Requiremen Requirementt to design design and code level. URRENT SECTION 3: LITERATURE SURVEY: CURRENT AT VARIOUS VARIOUS STAGES OF DEVELOPMENT DEVELOPMENT.
METHODS METHODS TO HANDLE HANDLE
NFR
This section captures the significant work done towards handling of NFR at various stages of development. At At requirement requirement Engineering Engineering phase several several Goal Oriented Approaches to handle NFR NFR have have been been sugg sugges este ted d such such as i*, i*, fram framew ewor ork k and and GRL GRL (Goa (Goall –Oriented Requirement Language), Language), SIG (Soft goal interdepend interdependence ence graph) graph) [21, 25, 35, 35, 34]. 34]. All these goal oriented oriented approa approache chess are based based on ident identify ifying ing NFR NFR as soft soft goal goal which which needs needs to be be satisf satisfied ied (within (within an an acceptable acceptable limit, or goals merely met) or “not satisfied” at all. all. NFR NFR are refined refined,, unles unlesss they they are are identified identified or decomposed decomposed as FR and their significanc significancee for for design design decision decision is made. made. Example Example of NFR Framework, as shown in figure 2, security of information is decomposed into the sub goals integrity, availability, confidentiality through an AND type of contribution (i.e. only if all sub goals are met met the overall goal is achieved),while achieved),while the goal of system performance is decomp decompose osed d into throughput and response time. Interestingly, it is necessary to address interactions between different kinds of non-functional requirements even though the non-functional requirements were initially stated as separate requirements. Note that cryptography contributes negatively (show as “-”) for system performance.
63
International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.4, J uly 2012
(above (above figure figure is adapted from[ from[ 45 ]) The significan significantt efforts in handling handling NFR in literature literature have been been tabulated tabulated below: below: Table1 Table1 1)Significant attempts to handle
NFR framework[10,11,12,14,16]
NFR
Salient Features of this attempt
Refining goal to sub goal till it is an operationaliz operationalized ed goal
Advantage
Makes relationship between NFR & intended decisions explicit, as one design decision impacts multiple NFR positively or negatively.
Main issues attempted to catered to
issue no 1,2,3
2 Sign Signif ific ican antt atte attemp mpts ts to hand handle le NFR NFR
FRML FRML(F (For orma mall Requ Requir irem emen entt Mode Modell llin ing g Language)[26]
Salie lient Features of this attem tempt
Semi formal specifica ication tion method bridging the the gap between two extremes of specification by formal formal method and natural natural language specification.
Advantage
Takes ad advantage of of Formal specification using temporal temporal logic & ease ease of a modelling modelling language language
Main is issues at attempted to to ca catered to to
Issue No No:6
3)Sign ignificant att attempts to to handle NFR
OORNF too tool[1 l[11,15]
64
International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.4, J uly 2012
Salient Features of this attempt
Separate view of FR & NFR integrated by a LEL( Language Extended Lexicon).
Advantage
Smooth integration of FR and NFR makes both vertical traceability ( among requirement design and code) and horizontal horizontal traceability traceability (between FR to NFR) NFR) to happen happen
Main issues attempted to ca catered to to
Issue No No:7
4)S 4)Sign ignific ificaant attem tempt to ha handle ndle NFR
PREM REM( per perform formaance nce requ requir ireement ent eva evalua luation tion model)[14,29]
Salien ient Features of this attempt
Agile approach to ad address the sp specifica ication ion an and testing of performance which is an important important type of NFR
Advantage
To identify and specify performance requirement incrementally
Main Main issu issues es atte attemp mpte ted d to to ca catere tered d to to
Issu Issue2 e2:: Foc Focus used ed atte attent ntio ion n on on one one of the the div diver erse se NFR.
5)Significant attempts for NFR
Misuse case, Abuse case or UMLsec[28,36]
Salient Fe Features of th this at attempt
Misuse ca case is is the inverse of of us use ca cases an and describe functions that system should not allow
Advantage
More use full in analyzing Security threats
Main issues attempted to catered to
Issue1,3,5
6)Significant attempts for NFR
GDUC(Goal driven use case) ref[14]
Salient Features of this attempt
Deriving use case with goal
65
International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.4, J uly 2012
Advantage
Each use case is viewed as a process associated with a goal that it must achieve, optimize or maintain.
Main issues attempted to catered to
Issue 1,2,3
7)Significant attempts for NFR
GCT(Goal Centric Traceability)[21,34]
Salien ient Features of this attempt
QAM(qual uality assessment Metho thods) is the the bas basis of this model
Advantage
Traceability of NFR to design decision is justified.
Main issues attempted to catered to
Issue 1,3
8)S 8)Sign ignific ificaant at attem tempts pts to ha handle ndle NFR
i* (hav (havin ing g its its extens tensio ion n as as TROPOS,URN)[18,37]
Salien ient Features of this attempt
It is an agent orien iented ted approach in which actors are depicted as agents with intentional properties properties representing their belief, goal, abilities and negotiations
Advantage
Focuses directly on modelling NFR and so soft goal It is a strate strategic gic dependenc dependency y model, model,
Main issues at attem tempted ted to to ca cater tered to to
Issue de design ign de decisions.
9)Signif 9)Significan icantt attempts attempts to to handle handle NFR
KAOS[14]
Salient Fe Features of th this at attempt
Uses Fo Formal me methods (a (acyclic gr graph)to represent both rational & satisfaction relationship
66
International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.4, J uly 2012
Advantage
KAOS relies on meta-models to provide a self descriptive and extensible modelling framework. framework. This gives it the advantage of Model based analysis.
Main issues attem tempted ted to cater tered to
Resolve lves Issues No:1
10)S 10)Sig igni nifi fica cant nt atte attemp mpts ts to to hand handle le NFR NFR
FDAF FDAF(F (For orma mall Desi Design gn Ana Analy lysi siss Fram Framew ewor ork) k),, similar effort of formalizing requirement is (TLA+) extended temporal logic. [14]
Salien ient Features of this attempt
It as assists ists the user in selec lecting formal methods and translates an extended semi formal UML design into formal notations.
Advantage
It exploits the benefit of formal method representation
Main issues attempted to catered to
Issue No 6
11)Significant attempts to handle NFR
“Constraint and object oriented programming programming
styles.[14] Salient Features of this attempt
Usage of exception handling mechanism
Advantage
Exceptional handling is the mechanism to identify constrains in these methods
Main issues attempted to ca catered to to
Issue no no1,
12)S 12)Sig igni nifi fica cant nt atte attemp mpts ts to to hand handle le NFR NFR
FRID FRIDA A Mode Modell (Fro (From m Requ Requir irem emen ents ts to to Desi Design gn using Aspects)[14] Aspects)[14]
Salient Fe Features of th this at attempt
a)FRIDA de determines a way to el elicit an and mo model FR and NFR separate separately. ly. B)It uses conflicts matrix to
resolve conflicts
67
International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.4, J uly 2012
Advantage
Used to accommodate view point of variant stakeholders using AOP( Aspect oriented Programming.)
Main issues attempted to ca catered to to
Issues 3,2
13)S 13)Sig igni nifi fica cant nt atte attemp mpts ts to to hand handle le NFR NFR
R++ R++ is an an exte extens nsio ion n of c++, c++, sim simil ilar ar effo effort rt is ILOG Jrules in java.[1,3]
Salient Features of this attempt
Is a combination of Rule based and objectoriented based development methodology
Advantage
Takes the advantage of Ru Rule based techniques
Main issues attempted to catered to
Issue6
14)S 14)Sig ign nific ificaant atte ttempts to handle ndle NFR
B Method thod [14] 14]
Salient Fe Features of th this at attempt
Full fo formal me method wh which us uses se set th theory notations to specify, design & implement software Systems
Advantage
Refinement process transforms abstract nondeterministic specification into concrete deterministic system. Key merit of such refinement mechanism is the ability to preserve already proven system property in higher level models.
Main issues attempted to catered to
Issue 1,2,3
15)S 15)Sig igni nifi fica cant nt atte attemp mpts ts to han handl dlee NFR NFR
Test Testing ing of NFR NFR is in emb embry ryon onic ic sta stage ge[r [ref ef 54] 54] limited to only debugging distributed real time system.
Salient Fe Features of th this at attempt
Limited to to on only re replay & visualization of of Computations
68
International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.4, J uly 2012
Advantage
Simple visualization by by usage of probes provide effective means of identifying computational bottleNECK
Main issues attempted to catered to
Issue 5
16)S 16)Sig ign nific ificaant att atteempts to to hand handle le NFR
Cos Cosmic FP FP[23, [23,24 24]]
Salient Fe Features of of th this attempt
Extending CO COCOMO mo model fo for co cost ev evaluation due to NFR
Advantage
One of the least significant at attempts to to evaluate cost due to NFR.
Main issues attempted to catered to
Issue 4
17)S 17)Sig igni nifi fica cant nt atte attemp mpts ts to hand handle le NFR NFR
POMS POMSA( A(Pr Proc oces esss Ori Orien ente ted d Met Metri rics cs for for sof softw twar aree architecture adaptability)[51] adaptability)[51]
Salien ient Features of this attempt
Trace back th the reason fo for tak taking des design ign dec decisio ision n
Advantage
Gives justification for taking certain design decisions
Main issues attempted to catered to
Issue 4
18)S 18)Sig igni nifi fica cant nt atte attemp mpts ts to han handl dlee NFR NFR
TRAG TRAGOS OSOM OMA( A(Tr Trac acea eabi bili lity ty driv driven en Goal Goal Solution Mapping.)[47]
Salien ient Features of this attempt
It uses goal orien iented ted method to guide the design ign activity, support support conflict resolution, resolution, decision decision making and classification classification of solutions. solutions.
Advantage
a)Gives justification of how NFR affect architectural decisions b)Tracing of requirement specification to design
Main issues attempted to catered to
Issue 1,2,3,4
19)Signific ificaant att atteempts to ha handle NFR
ZCL
69
International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.4, J uly 2012
Salien ient Features of this attempt
First Or Order Temporal logic ogic are utilized to de deal with idea of including including NFR in software software design through architecture
Advantage
Usage of formal method for an existing configuration model CL framework .
Main issues attempted to catered to
Issue 6
Section 5: Prevalent Testing Testing issues in light of NFR. Testing cannot be thought about suddenly, in a day[41,42,] in the last phase phase of release release when there is highest pressure for the release, of the product. It has to start right from the first phase of development. Therefore specify for testability, design for testability and code for testability should be done so that, we get good quality and testable product, at the end when when then pressure pressure of delivery is prioritized over that of quality of delivered product [7, 2]
Issue1: Specify Specify for testability testability of NFR. Challenges: Testability refers to “the degree to which a system or a component component facilitates facilitates the establishment of test criteria and the performance of tests to determine whether those criteria have been met.[32,33]. met.[32,33]. NFR in SRS SRS poses enormous enormous challenges. challenges. specificat specification ion in natural natural language language is inconsistent. This becomes more prevalent in case of NFR which are too “soft”, abstract abstract or fuzzy fuzzy even in the minds minds of stakeholders. Formal method specification specification holds the key to unambiguous specification but it has its own limitation of being difficult to be usable by all different different types of stakeholder stakeholders. s. No doubt it increases increases the challenges challenges of Requirement Requirement Engineers, Engineers, Architects Architects,, Designers and coder community ,but this effort is worth it as one of the seven Testing Princi Principle pless emphas emphasize izess on“ Early Testing”[4,8] i.e.” stitch in time saves nine” This issue has been addressed well for FR but remains to be studied in case of NFR.
Issues 2: NFRs role in decision making at design level. NFR affects affects various decisions decisions made while choosing various design options. NFR justify the reasons behind the choice of a particular architecture. architecture. [3] which is of great importance when when there is conflicting requirement. [29]
Issue 3: Code Code for testability testability of NFR. NFR. It can intuitively intuitively be improved improved if the stake holders holders concerns concerns which which are cross cross cutting across across various various modules can be coded separately as “concerns”. And related test aspects for these concerns can be written to test these “aspects” or “viewpoint” as and when required at these “ join points” and “point cut” [5, 30, and 31]
Issue4: Issue4: Cost and Effort Effort Estimation Estimation of Testing Testing of NFR:
There has been very few models contributing towards the cost and effort estimation of different development models such as COCOMO Model, FP model or LOC(lines of code) based 70
International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.4, J uly 2012
models.[9] There seems no model model known specially for estimating the cost cost of testing a software . [45]. No doubt cost of testing an NFR NFR is very high due to need of testing various permutations and combinations of configurations required for acceptance of product, then there is need of dynamic test environment, or test scenarios or no. of test test scripts for NFR testing.
Issue Issue 5: Testi Testing ng of Missio Mission n Critical Critical Syst Systems ems. Testing of , real time mission critical system is difficult, due to need to generate near “life life environment”. It is very difficult difficult to create create details regarding regarding customers customers hardware hardware setup, deployment information information and test data .Due to confidentiality Issue Issue invo involve lved d with with missio mission n critica criticall system system,, type of data data used used may vary vary far from from the the actual actual type type needed by the customers. customers. Test data is built based based on sample sample data collected collected by testers or is collected from similar or related products. MBT( (model based testing) may be explored for testing of NFR[49,50], because because intuitively modelling Non Functional Functional Requirement may yield test data very close close to actual data, especially where where mission critical systems have strict “entry “entry criteria” and “exit criteria”.
Issue Issue 7 Decidi Deciding ng the stoppi stopping ng criteri criteria. a. [9,8] [9,8] Deciding Deciding the test coverag coveragee criteria criteria [23], [23], i.e. i.e. How much much testing testing is enough enough is dominant dominant testing testing issue, issue, This becomes becomes more dominant dominant in in case of of NFR because because of of its nonlinear nonlinear availabilit availability y across across various modules. The penetration of these concerns across various various modules makes it difficult to decide decide as to how much much testing testing is suffic sufficient, ient, or what what are the test test coverag coveragee criteria criteria for NFR. NFR. Clear cut establishment of Entry and Exit criteria followed by by its execution can give a basis basis for deciding the stopping criteria for NFR testing.
Issue 8 Generation and Execution of Efficient test Suite: In NFR, testing needs reusability of test suites because of need to test, variant configuration, or environment in which which acceptance testing may take place because of variety variety of customers customers environmen environment, t, configura configuration tion possible possible at at customers customers end.[2] end.[2] One often often needs to change the testtestscript to check check the variety of test scenario scenario generated. generated. Test Suite is a collection of Test Test cases. cases. It It should be an optimized collection, of new and old reusable test cases. NFR like maintainability and reusability heavily depend on optimization of existing or new new test cases. Generically speaking all the issues issues in testing testing boils down to generation, execution, optimization and evaluation of test cases in the test suite. These problems get aggravated with NFR testing, which holds its own share of problem
Issue 9 Test Oracle Oracle Generation Generation: what should be the basis of evaluation of test result is an issue of software software testing as a whole. whole. Usually SRS (as (as the contract document), or existing similar software forms the test oracle.NFR oracle.NFR testing testing is a part part of system system testing testing which which is done agains againstt SRS. Due Due to vague vague and ambiguous ambiguous specification of NFR, SRS becomes weak weak oracle for NFR NFR testing.
Issue 10 Testing Metrics: Metrics: There There has been very very little success success in developme development nt of any model model on Test metric metric for NFR, NFR, as opposite opposite to various various developme development nt metric metric available available in testing testing of FR.[9,41,an FR.[9,41,and d 42] . Basic elements elements of produc productt and and project project metrics metrics are difficult difficult to identify, identify, for NFR due to to its complex complex nature nature , where where there is need need of high volume of sample sample data for analysis. analysis. NFR testing testing results in huge huge collection collection 71
International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.4, J uly 2012
and analysis of data[2]. It needs expertise knowledge of product, domain, design and statistical statistical skills. There are various commonly existing existing testing metrics metrics for FR. like, defect find rate, defect fix rate, defect defect cause distribution, defect classification classification trend etc.
Test Automa Automation tion:: 11) Test How much much automation automation is possible? possible? for what what all testing testing activity activity is a concern concern of testers. testers. Various Various NFR such such as performance testing, security testing, stress, stress, load and GUI GUI testing lending themselves easily to automation process, where where there is need to analyze large volume of data or exponential combinations of configuration or environment environment needed to be tested for acceptance acceptance of a product.[6,8] product.[6,8] Creating Creating test cases, cases, test environmen environment, t, or test data to simulate simulate actual actual load or stress stress condition is good scenario for automation. automation. Thus “automation” “automation” is a fertile area for for NFR Testing because of inherent problems/ limitations / issues raised by NFR testing which are very nicely handled by Automation. There are several successful automation tools available commercially, for NFRs like stress , load ,GUI or performance testing like load runner win runner , Rational Robo, QTP, Test Test Control Control etc. etc. There There is plethora plethora of tools tools available available for testing testing of differ different ent types types of NFR.
Sectio Section n 6: Testin Testing g of FR vs. NFR. NFR. [5, 2]: 2]: Table2 Table2
Sl.No.
FR Testing
NFR Testing
1)
Testing of FR is Testing of Functionality
Testing of NFR is constrains
testing of
over
those
Functionality. FR Testing states “what” the system must
NFR
do
system
constrain
must
“how”
accomplish
the
the
“what”.[5,14].
2)
Testing of FR involves pr p roduct features & Testing of NFR NFR involves quality functionality.
3)
4)
factor
Testing is done through simple steps Test Testing ing yiel yields ds hug hugee data data set set written to check expected results.
collec collected ted and and analyz analyzed. ed.
Testing focuses on defect detection
Testing fo focuses on on qu qualification of results.
5)
Testing requires knowledge of product and Testing requires knowledge and domain
experience of product, domain, design,
architecture
and
statistical skills. 6)
Failure is normally due to code
Failure is normally due to code, design and architecture.
7)
Testing
phase
in involves
us usually
un unit,
Testing phase involves usually 72
International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.4, J uly 2012
component and integration level. 8)
system level testing.
Testing of FR is easy because of its well NFR testing is difficult due to defined goal.
its inability to operationalize the soft goals into concrete concrete testable testable objective.
9)
Result of testing varies due to product Result of NFR NFR testing testing varies varies due implementation
to
product
implementation,
resources and configurations. 1 0)
FR Testing talks about clear pa p ass or or fa fail NFR requires test results be criteria
documented in Qualitative as well as quantitative quantitative form.ie form.ie apart from verifying pass or fail the effort
required
in
test
execution[2] 11
Testing of FR requires one time setup for a Testing set of test cases
of
NFR
requires
configuration changes for each test case.
Section Section 8: Conclusion Conclusion and Observations: Observations: Testing Techniques have evolved through various various phases, starting from not being separable from Debug Debugging ging to Curren Currentt phase of preven preventing ting faults faults in requir requirem ement, ent, design design and implem implement entatio ations. ns. [43]. Testing Testing of NFR NFR has traditiona traditionally lly been been done informally informally using using Ad hoc Approach Approaches. es. [4, 6].There 6].There have been been multiple reasons reasons for this. Handling Handling NFR NFR is inherently inherently difficult difficult due to its soft, soft, subjective subjective and subtle subtle nature, nature, and all the more due to great great diversity, diversity, giving giving rise to conflicting conflicting requirements. Informal treatment of NFR, leads to non traceability of NFR from requirement through design, coding and testing phase leading to low testability. Testing of NFR imposes its own set of challenges challenges against against FR. FR. Currently, Currently, various various approaches approaches to handle handle the issues issues of NFR specification to testing is centred around “Goal oriented approaches” [10, 11, 12, 13, 14, 1516, 17, 19, 21]
Section Section 9: Future Research Research Direction: Direction:
The subsequent subsequent research research directions directions for future future exploration exploration are: 1) Testing of NFR can be made more more effective if NFR can can be specified, designed and coded for high testability testability.. Requiremen Requirementt engineering engineering has handled handled the specificati specification on of Functional Functional Requiremen Requirements ts very clearly clearly and measur measurably ably [5], may be be because because of clearclear-cut cut identific identification ation and and specificat specification ion of FR in in SRS, so their design design and and testing does have have numerous numerous measures measures and and metrics metrics for their evaluation. There are various well defined metrics for FR at design level, such as: No. of Module Modules, s, Interf Interface aces, s, Level Level of Cohes Cohesion ion and and Couplin Coupling g or KLOC. KLOC. The same same does does not hold hold good good for NFR testing. testing. one of the possible possible future directions directions can can be working working out testability testability measures measures for NFR particularly. 73
International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.4, J uly 2012
2)NFR 2)NFR results from from quality concerns concerns of stakeholders stakeholders.. Aspects (in AOP) AOP) deal with crosscutting crosscutting concerns and hence Aspects Aspects can be purposefully used not only for designing software with NFR but also also for for their their testing testing.. Similar Similarly ly test test aspects aspects can be writte written n for testing testing softwa software re with with respec respectt to an NFR. 3) MBT can be purposefully used for NFR Testing. Testing. A possible approach for this purpose purpose can be worked worked out. As realized, realized, after after survey, survey, NFR NFR can be handled handled more concrete concretely ly by MBT because, because, it models the real life situations yielding concrete test cases from abstract formal models. [49, 50]
REFERENCES [1] [2] [3] [4] [5] [6] [7] [8] [9] [10]
[11]
[12]
[13] [14]
[15] [16] [17]
[18]
[19] [20]
[21] [22]
Pressman, Pressman, R. S. (2005) (2005).. Software Software Engineering Engineering:: A Practitione Practitioner's r's Approach Approach (6th ed.). ed.). New York:York:McGraw-Hill Publication. Srinivasan Srinivasan Desikan,Gop Desikan,Gopalaswamy alaswamy Ramesh ,Software ,Software Testing Testing :Principles :Principles and Practic Practices, es, Pearson Pearson,2006 ,2006 Len Bass,Paul Bass,Paul Clements Clements ,Softwa ,Software re Architectu Architecture re in Practice,2 Practice,2nd nd edition,20 edition,2003 03 Pearson Pearson Rex Black, Black, Foundat Foundations ions of softwa software re testing20 testing2008, 08, cengag cengagee learning learning press, press, Sommerville Sommerville,, I. Software Software Engineering Engineering.. Low Low Price Edition. Edition. Pankaj Pankaj Jalote: Jalote: Practical Practical approa approach ch to software software engine engineering ering,, Rajib Mall Mall ,Fundamen ,Fundamentals tals of Software Software Enginee Engineering, ring, Third Third Edition, Edition, PHI Publicatio Publication. n. Glenford Glenford J Myaer Myaerss ,The Art of Software Software testing, testing, second second Edition ,John willey Fenton, Fenton, N.E. and Pfleeger Pfleeger,, S.L. "Software "Software Metrics: Metrics: A Rigorous Rigorous and PracticalAp PracticalApproa proach" ch" 2nd ed., International Thomson Computer Press, 1997. Luiz Marcio Cysneiros, Member,Julio Cesar Sampaio do Prado Leite, Member, Nonfunctional Requirements:From Elicitation to Conceptual Models, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 30, NO. 5, MAY 2004 Cysneiros,L.M., Leite, J.C.S.P. and Neto, J.S.M. “A Framework for Integrating Non -Functional Requirements into Conceptual Models” Requirements Engineering Journal ––Vol 6 , Issue 2 Apr. 2001, pp:97-115. Lawrence Chung1 and Julio Cesar Sampaio do Prado .T. Borgida et al. On Non-Functional Requirements in Software Engineering (Eds.): Mylopoulos Festschrift, LNCS 5600, pp. 363–379, 2009.© Springer-Verlag Berlin Heidelberg 2009 Saeed Ullah, Muzaffar Iq bal, Aamir Mehmood Mehmood Khan,A Survey on on Issues in Non-Functional Requirements Elicitation 978-1-61284-941-6/11 2011 IEEE A. Matoussi, R. R. Laleau. A Survey of Non-Functional Requirements Requirements in Software Development Process, October 2008 Laboratory of of Algorithmic, Complexity Complexity and Logic Logic (LACL) University University Paris 12 (Paris East) Technical Report TR –LACL–2008–7 Luiz Marcio Cysneiros and Julio Cesar Sampaio Leite. Using UML to reflect Non-functional Requirements. In CASCON, page 2, 2001. Chung, L., Nixon, B., Yu, E. and Mylopoulos,J. “Non -Functional Requirements in Software Engineering”: Boston Kluwer Academic Publishers 2000. Chung, L., Nixon, B. “Dealing with Non -Functional Requirements: Three Experimental Studies of of a Process-Oriented Approach” Proc. 17th Int. Con. on Software Eng. Seatle,Washington, April pp: 24 28, 1995. John Mylopoulos, Mylopoulos, Marco Pistore, Pistore, and Paolo Traverso. Model Checking Early Requirements Specifications in Tropos. In RE ’01: Proceedings of the Fifth IEEE International Symposium on Requirements Engineering (RE ’01), page 174. IEEE Computer Society, 2001. Martin Glinz. On Non-Functional Requirements. In 15th IEEE International,Volume , Issue , 15-19 Oct, pages 21–26, 2007. Jan Jurjens. UMLsec: Extending UML for Secure Systems Systems Development. In UML’02: Proceedings Proceedings of the 5th International Conference on The Unified Modeling Language, pages 412 –425, London, UK, 2002. Springer-Verlag. Sam Supakkul Supakkul and Lawrence Chung. Integrating FRs and NFRs: NFRs: A Use Case and Goal Goal Driven Approach. Proc. SERA 04, pages 30 –37, 2004. Steffen Zschaler. Zschaler. Formal Specification of Non-functional Properties Properties of Component-Based Software., Software., Workshop on Models for Non-functional Aspects of Component-Based Software (NfC’04) at UML 74
International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.4, J uly 2012
[23]
[24] [25]
[26]
[27] [28] [29]
[30]
[31]
[32] [33] [34]
[35]
[36] [37] [38] [39]
[40] [41] [42] [43] [44]
conference 2004, September 2004. Technical Report TUDFI04-12 Sept.2004 at Technische Universit¨at Dresden. Mohamad Kassab, M. Daneva, and Olga Ormandjieva. Scope Management Management ofNon-Functional ofNon-Functional Requirements. In EUROMICRO ’07: Proceedings of the 33rd EUROMICRO Conference on Software Engineering and Advanced Applications,pages 409 –417. IEEE Computer Society, 2007. A.Keshav Bharadwaj, Bharadwaj, T.R. Gopalakrishnan Gopalakrishnan Nair, Mapping General General System Characteristics to NonFunctional Requirements,2009 IEEE International Advance Computing Conference (IACC 2009) Goal Modelling in Requirements Engineering: Engineering: Analysis and Critique of of Current Methods Methods Evangelia Kavakli* , Pericles Loucopoulos** DOI: 10.4018/978-1-59140-375-3.ch006,ISBN13: 9781591403753, ISBN10: 1591403758, EISBN13: 9781591403777 http://www.igiglobal.com/chapter/goal-modeling-requirements-engineering/23011 Greenspan, S., Mylopoulos, Mylopoulos, J., & Borgida, Borgida, A. (1994, May 16-21). On Formal Requirements Requirements Modeling Languages: RML Revisited. Paper Paper presented at the 16th International Conference Conference on Software Software Engineering (ICSE-94), Sorrento, Italy. M. R. Barbacci, Barbacci, M. H. Klein, T. T. Longstaff and C. Weinstock, "Quality Attributes",Technical Report CMU/SEI-95-TR-021, Software Engineering Institute, Carnegie Mellon,University, December 1995. Ian Alexander Alexander Alexander Misuse Cases Help to Elicit Non-Functional Requirements, Requirements, Engineering Use Cases with DOORS, Address given at RE'01, IEEE Computer Society p 264, 2001 X. Franch, Franch, P. Botella, X. Burgués, J.M. J.M. Ribó.,Putting Non-Functional Requirements Requirements into Software Architecture1, In Proceedings of 9th Software Engineering and Knowledge Engineering Conference (SEKE), Madrid (Spain), 1997. Milena Milena Guessi, Lucas Lucas Bueno Ruas Ruas Oliveira, Oliveira, and Elisa Yumi Yumi Nakagawa. Nakagawa. Extensions Extensions of UML to Model Model Aspect-oriented Software Systems ,CLEI ELECTRONIC JOURNAL VOLUME 14 NUMBER 1 PAPER 3 APRIL 2011 Wehrmeister, M. A. (2009). An Aspect-Oriented Model-Driven Engineering Approach Approach for Distributed Embedded Real-Time Systems. PhD thesis, Federal University of Rio Grande do Sul, Brazil. www.inf.ufrgs.br/˜m www.inf.ufrgs.br/˜m awehrmeister/wehrmeister_thesis_final.pdf. Bret Pettichord., Design for Testability ,Pacific Northwest Software Quality Conference, Portland, Oregon, Oregon, October October 2002. Testability IEEE (1990). (1990). IEEE Standard Glossary of of Software Engineering Terminology, ANSI/IEEE Std 610.12-1990. Jane Cleland-Huang, Cleland-Huang, Raffaella Settimi, Oussama BenKhadra, Eugenia Eugenia Berezhanskaya, Berezhanskaya, Selvia Christina ,Goal-Centric Traceability for Managing Non-Functional Requirements,ICSE’05, May 15– 21, 2005, St. Louis, Missouri, USA. C opyright 2004 ACM 1-58113-963-2/05. Jonathan Lee and Nien-Lin Xue, Xue, Analyzing User Requirements by Use Cases: A Goal-Driven Approach, National Central Central University. IEEE Software J u l y / August 1999 0740-7459/99/1999 0740-7459/99/1999 IEEE Alexander I.: Misuse cases help to elicit non-functional requirements. Computing and ControlEngineering Journal 14(1), 40 –45 (2003) TROPOS, URN ,i*, Castro, J., Kolp, M., M., Mylopoulos, J.: Towards requirements-driven information information systems engineering: the Tropos project. Information Systems 27(6), 365 –389 (2002) C.J. Fidge and A.M. Lister,” A disciplined approach to real -time systems design Information and Software Technology,34(9):603 –610, September 1992. Finkelstein, A. and Dowell J. “A comedy of Errors: The London AmbulanceService Case Study” Proceedings of the Eighth International Workshop on Software Specification and Design, IEEE Computer Society Press pp 2-5 1996 J.-L. Lions, ARIANE 5 Flight Flight 501 Failure: Report Report by the Inquiry Board, http://ravel.esrin.esa.it/docs/esa-x-1819eng.pdf , 1996. Cem Kaner, J.D, The Ongoing Ongoing Revolution in Software Testing,Software Testing,Software Test & Performance Conference, December 8, 2004 Timişoara, Timişoara, Romania Romania , Software Software Testing Testing – State of the Art and Current Current Research Challenges,5th Challenges,5th International Symposium on Applied Computational Intelligence and Informatics • May 28– 29, 2009 Lu Luo, Technology Technology Maturation and Research Strategy Class Report for 17-939A 17-939A Software Testing techniques. Aburub F., Odeh M. and Beeson I., “Modeling Non -Functional Requirements for Business Process”,Information and Software Technology Journal, vol.49, no. 11 -12, pp. 1162-1171, 2007.
75
International Journal of Software Engineering & Applications (IJSEA), Vol.3, No.4, J uly 2012 [45] [45] M. Kassa Kassab, b, C. Const Constan antinides, and O. Ormandjieva,“Specifying and separating concerns from requirements to design: a case study”, Proc. the IASTED International Conference on Software Engineering (ACIT-SE 2005), Novosibirsk,Russia, 2005. [46] J. Zhao, “Towards A Metrics Suite f or Aspect-Oriented Software”, Technical Report SE -136-25, Information Processing Society of Japan ( IPSJ), March 2002. [47] Stephan Bode,Matthias Riebisch, Riebisch, Tracing the Implementation Implementation of Non-Functional Requirements,Copyright © 2011, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global i s prohibited. [48] Brian Lawrence, Karl Wiegers, and Christof Ebert “The Top Risks of Requirements Engineering” IEEE SOFTWARE SOFTWARE Novemb November/Dece er/December mber 2001 2001 0 7 4 0 - 7 4 5 9 / 0 1 / $ 1 0 . 0 0 © 2 0 0 1 I E E E [49] Dr. Bruno Legeard, Model-based Testing: Next Generation Functional Software Testing, Dagstuhl Dagstuhl Seminar Proceedings 10111Practical Software Testing : Tool Automation and Human Factors http://drops.dagstuhl.de/opus/volltexte/2010/2620 [50] Ibrahim K. El-Far and James A. Whittaker: Whittaker: Model-Based Software Testing Model-based Software Software Testing This paper appears in the Encyclopedia on Software Engineering (edited by J.J. Marciniak), Wiley, 2001 [51] Lawrence Chung ,Nary Subramanian, Process-Oriented Process-Oriented Metrics for Software Architecture Adaptability, Requirements Engineering, 2001. Proceedings. Fifth IEEE International Symposium on2001,Pag on2001,Page(s): e(s): 310 - 311 . [52] Ruth Malan Malan and Dana Dana Bredemeyer, Bredemeyer, Functional Functional Requirem Requirements ents and Use Use Cases, 2001 BREDEMEYER BREDEMEYER CONSULTING WHITE PAPER 8/3/01 2, http://www.bredemeyer.com/pdf_files/functreq.pdf Biography Biography of Author: Author:
Anil Kumar Kumar Tripathi (M.Sc. Engineering (computer) from Odessa National Polytechnic Polytechnic Univer University sity,Uk ,Ukrain rainee 1984, 1984, Ph.D Ph.D.. in Comp Compute uterr Engine Engineerin ering, g, Banara Banarass Hindu Hindu Univers University ity,, 1992, 1992, Varana Varanasi, si, India. India. Workin Working g as as prof professo essorr in Comput Computer er Engine Engineerin ering g Depart Departmen mentt Indian Indian Institute Institute Of Technology, Technology, (Banaras (Banaras Hindu University), University), Varanasi, Varanasi, India. India. He is engaged engaged in teaching teaching and research research at IIT( BHU) for last more than 27 years years in the the area area of of Parallel/Dis Parallel/Distribut tributed ed computing computing and Software Software engineering engineering.. He has to his credit some 50 resear research ch paper paperss in journa journals. ls. He has co-aut co-author hored ed two resear research ch monog monograp raphs: hs: one one from Springer Springer USA and the other other from from John John Wiley Wiley USA.Fourte USA.Fourteen en students students have have completed completed their Ph.D under under his supervision. Pratima Pratima Singh , MCA MCA 2001,M.Tech 2001,M.Tech from from UPTU 2009 2009 has been working working as Assistance Assistance Profes Professor sor in BBDNIT, BBDNIT,Luc Luckno know w and AKGEC AKGEC Ghaziab Ghaziabad. ad. UP. UP. since since 12 years years,. ,. She has has been been teach teaching ing Softw Software are Engin Engineer eering ing,, Softwa Software re Projec Projectt Manage Managemen mentt and Compu Computer ter Organizatio Organization n to the students students of B.Tech B.Tech and MCA .She has cleare cleared d ISTQB (Internation (Internationll Software Software Testing Qualifica Qualification tion Board) Board) Certification Certification in 2007, subsequently subsequently tested few Products Products on Adhoc Adhoc basis. basis. Presently Presently pursuing pursuing Ph.D. from from IIT BHU .
76