vasu4q

 Profile Answers by vasu4q 

• Oct 26th, 2006

 

Dear Friend as per my knowldge i can say like if we use the tracability matrix we can able to know weather did we cover all parts of the application by executing the testcases as shown in the tracibilty matrix.

becaz in tracabilty matrix it shows the relation between the requiremtns to the test cases with bugs.

swapna

• Oct 30th, 2006

 

I dont agree with the answer posted.As far as to my knowledge test estimation is based on the requirements specified in the functional specs.The Test estimation is initially prepared before start testing.This test estimation includes the the time taken for testcases preparation,execution of test cycles..

subbu

• Oct 30th, 2006

 

Based on the requirements, we should design test inputs by considering the risk.

payal

• Oct 31st, 2006

 

Test estimation is done during the time of planing.Test estimation determines how much time will testing take.

Raju Mandapaty

• Nov 7th, 2006

 

Test estimation determines how much time testing will take. This is the total time of testcase preparation+testcase execution+test results documentation. Generally it would be 60% of development time of that particular requirement.

Raju Mandapaty

 Profile 

• Nov 7th, 2006

 

TESTING estimation is done during the time of planing.Testing estimation determines how much time testing will take. Testing include preparation of testcases+testcases execution+test results documentation. Testing estimation should be done 60% of the development time for that particular requirement.

Pavan Kumar

• Dec 19th, 2006

 

Test Estimation will be done based on three attributes.

 - Size

 - Effort

 - Schedule.

Size - The size of the project needs to be determined in order to estimate the testing. Size can be measured in 3 ways, 1. LOC(Lines of Code) 2. Function Points(Functions, Features in the application has to be taken as inputs) 3. No. of Screens/Forms. While estimating the size, we should take the time required for automation and number of configuration the application to be tested.

Effort - Once the Size estimation is done, the effort requried to be estimated which can be done using the Size estimates+Productivity(Time that can be taken for Test authoring/execution per organization standards)+amount of time takes to test the product on multiple combinations.

Schedule - The testing should be categorized into different phases and based on the effort estimated for the project, the schedule will be estimated. It will be done using the WBS(Work Breakdown structure) with start and end dates for each activity.

WBS units can be taken while estimating the Size and Effort also.

Regards

Pavan

Khalid

• Aug 14th, 2007

 

That was one line definition but exactly how is it done and what are the various approaches for it?
Like using usecase points, test points, statechart diagrams etc.

G.D.S.Prasad

 Profile Answers by G.D.S.Prasad Questions by G.D.S.Prasad

• Mar 10th, 2009

 

There are different analysis for test estimation like Function Test Point (FTP) analysis, Test Case point (TCP) analysis... etc

Test Case Points (TCP) – Test Case Point deals with the estimation of the
effort needed for testing projects. It is technology independent & supports the
need for estimating, project management & measuring quality. This approach
enables separate effort estimates for different phases of testing viz. Test Case
Generation, Automated Test Cases & Test Case Execution.

Function Test
Points (FTP) – It estimates size & efforts for testing activities. Each test
requirement is decomposed into possible atomic logical functions & mapped them
with complexity factor.

kurtz182

 Profile Answers by kurtz182 Questions by kurtz182

• Nov 18th, 2009

 

No single answer covers all cases.  Nevertheless, here are some guidelines:
 
1) All testing estimations are company and project specific.

2) When developers, partners, testers give you an estimate on the time and resources needed to complete their projects, double them.  People tend to be more optimistic than realistic, and they tend to ignore factors that consume their time and resources.  In fact, triple their estimates if there is a great deal of multi-tasking and task switching going on.  It takes time to get reoriented and to ramp up on new projects.  Take into account that people don't actually perform their core duties during an 8-hour day; there's meetings to attend, and email to read and respond to, and interruptions.  You can account for this in your schedule by allocating only 6 hours per day on core activites.  No workload estimation tool will do this for you.  Your estimation will be an extrapolation from the work that has already been done to the work that needs to get done.  Use your best judgement. 

3) Factor all of the activities that testers must perform in order to adequately complete their test projects.  In some companies, each tester will be responsible for producing their own Test Plans and ensuring that test environments are set up properly for their own testing purposes.  You must factor all of these activities into the test estimate as well. 

4) Take into account the complexity of the software under test.  You can divide software modules and/or functional areas into levels of complexity: high, medium, and low complexity.   Based on past experience, you can calculate the average number of test cases and the average amount of time to execute them.   

5) The complexity of the software will also determine how many iterations of testing (test runs) are likely to occur in order for the software to meet a level of quality that the company can live with (its exit criteria).  The number and length of test runs is a significant factor when estimating a test project.

6) According to many sources, testing takes between 30% and 40% of the total project effort.  This is consistent with my experience.

7) There are different methods to perform test estimation and it depends upon the organization estimation techniques.  I find it best to understand the requirements, discuss them with your team while gaining information from them such as the time these requirements might take to test and apply this information into your test estimation model.  This will give you a number.  Then you can add any risk mitigation to buffer against possible code delays, requirement changes, and so forth.   This should help to reach to a close figure which can then be used as a baseline for future estimation.

Jeff Kurtz