Welcome to Scribd, the world's digital library. Read, publish, and share books and documents. See more
Standard view
Full view
of .
Look up keyword
Like this
0 of .
Results for:
No results containing your search query
P. 1
Test Effort Estimation

Test Effort Estimation



|Views: 2,389|Likes:
Published by kalyanbandi
software testing
software testing

More info:

Published by: kalyanbandi on Jan 02, 2008
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Quality Week 2001, San Francisco, California, USA, June 2001Suresh Nageswaran
Copyright(c) 2001, Cognizant Technology Solutions All rights reserved 
Test Effort Estimation Using Use Case Points
Suresh Nageswaran
Cognizant Technology Solutions,National Games Road,Yerwada, Pune – 411006.Maharashtra, India(+91-020) 669 19 60
This paper presents a new approach to theestimation of software testing efforts based onUse Case Points [UCP] as a fundamental  project estimation measure. From preliminaryapplications on our web-based projects, weconjecture that this could in fact be morereliable than FP. The caveat here is that the V-model must be in use and use case generationmust start becoming available right at therequirements gathering phase. The acceptancetest plan is then prepared with the use cases from the requirement documents as input. Further work could provide a more exact relationship between the two.
Probably the most crucial difference between themanufacturing industry and the software industryis that the former is able to stick to schedulesmost of the time. The reason why softwaredevelopment schedules are so unpredictable isnot because workers in this industry are lazy or incompetent. To estimate the time make a product from scratch, and in many cases, without prior experience of the technology is no meanfeat. However, conventional estimationtechniques address only the development effortthat goes into it.It is known that a use case to test case mappingis possible. This means that the UCP figure for development can be indirectly used to provide afigure for the number of test cases. Usingorganizational test execution time metrics it isnow possible to arrive at a figure for the total testeffort. This is a viable and systematic approachtowards test effort estimation and it makes a leapin providing more realistic figures. This meansthat the cost of testing can now be factored into projects. The other advantage is that testengineering gets treated as a process and notsimply as another lifecycle phase.
Software Test Engineering
Test Engineering covers a large gamut of activities to ensure that the final product achievessome quality goal. These activities must be planned well in advance to ensure that theseobjectives are met. Plans are based onestimations.In the early years, the Waterfall model has beenapplied to software development. This modellooks upon test engineering as merely a stage inthe entire development lifecycle. Whentechniques evolved over the years for estimatingdevelopment time and effort, the concept of estimating test-engineering time was overlookedcompletely.Test engineering is seldom planned for in mostorganizations and as a result, products enter themarket insufficiently tested. Negative customer reactions and damage to the corporate image isthe natural consequence.To avoid this, the correct development lifecyclemust be chosen and planning should be doneearly on in the cycle.
Quality Week 2001, San Francisco, California, USA, June 2001Suresh Nageswaran
Copyright(c) 2001, Cognizant Technology Solutions All rights reserved 
Software Project Estimation
According to Rubin [2], the stage-wise effortdistribution on software projects is as shown inthe pie chart below.Estimation is basically a four-step approach:1.
Estimate the size of the development product. This is either in LOC [Lines of Code] or FP [Function Points]. The conceptof using UCP [Use Case Points] is still in itsinfancy.2.
Estimate the effort in person-months or  person-hours.3.
Estimate the schedule in calendar months.4.
Estimate the cost in currency.
Conventional Approach to TestEffort Estimation
Test engineering managers use many differentmethods to estimate and schedule their testengineering efforts. Different organizations usedifferent methods depending on the type of  projects, the inherent risks in the project, thetechnologies involved etc.Most of the time, test effort estimations areclubbed with the development estimates and noseparate figures are available.Here is a description of some conventionalmethods in use:1.
Ad-hoc methodThe test efforts are not based on anydefinitive timeframe. The efforts continueuntil some pre-decided timeline set bymanagerial or marketing personnel isreached. Alternatively, it is done until the budgeted finances run out.This is a practice prevalent in extremelyimmature organizations and has error margins of over 100% at times.2.
Percentage of development timeThe fundamental premise here is that testengineering efforts are dependent on thedevelopment time / effort. First,development effort is estimated using sometechniques such as LOC or Function Points.The next step is using some heuristic to pega value next to it. This varies widely and isusually based on previous experiences.This method is not defendable since it is not based on any scientific principles or techniques. Schedule overruns could rangefrom 50 – 75% of estimated time. Thismethod is also by far the most used.3.
From the Function Point estimatesCapers Jones [1 ] estimates that the number of test cases can be determined by thefunction points estimate for thecorresponding effort. The formula is Number of Test Cases = (Function Points)
The actual effort in person-hours is thencalculated with a conversion factor obtainedfrom previous project data.The disadvantage of using FP is that theyrequire detailed requirements in advance.Another issue is that modern object-orientedsystems are designed with Use Cases inmind and this technique is incompatible withthem.
Quality Week 2001, San Francisco, California, USA, June 2001Suresh Nageswaran
Copyright(c) 2001, Cognizant Technology Solutions All rights reserved 
Use Cases
Alistair [5] has this description of a use case:A use case captures a contract between thestakeholders of a system about its behavior. Theuse case describes the system’s behavior under various conditions as it responds to a requestfrom one of the stakeholders, called the
r. The primary actor initiates an interactionwith the system to accomplish some goal. Thesystem responds, protecting the interests of allthe stakeholders. Different sequences of  behavior, or scenarios, can unfold, depending onthe particular requests made and conditionssurrounding the requests. The use case collectstogether those different scenarios.
Mapping Use Cases to Test Cases
Use cases in their most primitive forms are basically representative of what the user wantsfrom a system. The advantages of Use Cases arethat they start becoming available early on in the project lifecycle. The appropriate projectlifecycle model is the V-Model. The figure below illustrates the same.The model clearly has one test engineeringactivity associated with a correspondingdevelopment activity. The topmost rung of themodel associates the business requirementidentification with the acceptance plan preparation. Each successive step makes surethat the test documentation becomes completeand comprehensive. If the estimation process isfitted in the second rung after the businessrequirements are available, it is obvious that usecases will serve as the inputs.The identification of the number of test caseshere can be made quite directly. Each scenarioand its exception flows for each use case areinput for a test case. Subsequently, theestimation calculations can commence.As the requirements become clearer further downstream, the estimates will also undergorevision.
UCP Approach to Estimation
Estimation using UCP [Use Case Points] israpidly gaining a faithful following. Theapproach for estimation using UCP only needsslight modification in order to be useful toestimate test efforts.1.
Determine the number of actors in thesystem. This will give us the UAW – theunadjusted actor weights.Actors are external to the system andinterface with it. Examples are end-users,other programs, data stores etc.Actors come in three types: simple, averageand complex. Actor classification for testeffort estimation differs from that of development estimation.End users are simple actors. In the contextof testing, end-user actions can be capturedeasily using automated tool scripts. Averageactors interact with the system through some protocols etc. or they could be Data stores.They qualify as average since the results of test case runs would need to be verifiedmanually by running SQL statements on thestore etc. Complex users are separatesystems that interact with the SUT throughan API.The test cases for these users can only bewritten at the unit level and involves asignificant amount of internal system behavioral knowledge.
Actor Weights
 Actor TypeDescription Facto
SimpleGUI1AverageInteractive o protocol-driver interface2

Activity (20)

You've already reviewed this. Edit your review.
1 hundred reads
1 thousand reads
Pradeep Dash liked this
dgE liked this
dgE liked this
babu1076 liked this
David Carter liked this
Deepak Konnur liked this
Nitu Bele liked this

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->