HomeTag: Software Testing Estimation Technique

Software Testing Estimation Technique

1
Feb

Project Estimation Rules

By globalsqa No comments yet , ,

Below Project Estimation Rules should be recalled when doing Estimation of a Testing Project: 

 

1st Rule: Software requirements are considered for Estimation

Software requirements are indeed essential for test estimation as it is based completely on what would be tested. The development team has much involvement in the software requirements as compared to the testing team and the requirements are mostly established by the development team. When all the estimation are done related to the project cost, duration of the project then the development team asks the testing team that how much time will be required by them in order to complete the testing of the application. The answer given by the testing team is considered for the SDLC process.

Testing team plays a vital role in estimation of the project because testing is an essential part of SDLC. Testing application, one can deliver a bug free application to the client.

2nd Rule: Expert judgment matters for the Estimation of the Project

The testing team classifies the requirements before estimating them in the following categories:

  • Critical: The development team has slight knowledge in how to implement it;
  • High: The development team has worthy knowledge in how to implement it but the task is not easy at all;
  • Normal: The development team has decent knowledge in how to implement. 

The expert opinion in each requirement suggests how long it would take for testing them.  The categories would eventually help the experts in estimating the effort for testing the requirements.

3rd Rule: Previous projects matter most for Estimation of project

Previous project knowledge and experience are used for the estimation of the project. If new project is introduced then its estimation is based on similar projects which have been executed previously. 

4th Rule: Metrics Helps in Estimation

Organization should create an Organization Process Database which is also referred as OPD, where the project metrics are recorded and referred for future projects.

5th Rule: The past should never be ignored while doing Estimation

Spreadsheets and Old process is still used by the testing team in order to estimate the project completely. If new rules are introduced during the process then the testing team follows that and at the same time compares the old process too so as to get complete idea in test Estimation.

The results which come from the new estimate process should be faster and cheaper as compared to the old process and in percentage of 20 to 20%. If different percentage are measured by the testing team then they go back to the old process to check whether they are missing something during the process or not.

 6th Rule: Recording of Estimation is indeed essential

During testing of the process all the results should be recorded in order to refer it for future projects. It is also beneficial when requirements of the projects change and hence the recording will eventually help the testing members in estimating the project. This will help testing team to not return all the steps again and will further help in taking same decisions. It also gives the opportunity to test the estimation before making any changes to it. 

7th Rule: Tools should be used while doing Estimation

A spreadsheet containing metrics eventually helps reaching the estimation as quickly as possible. The spreadsheet will calculate it automatically hence giving ease to the team members. It also helps in tracking the duration and time of the projects. 

Risk Table, and free notes should be included in the template and need to be filled in the tool. These tools also help in showing different options for testing which actually aids the customer in deciding which types of test he needs practically.

8th Rule: Estimation should continuously be verified

All estimation should be verified in a certain period of time.  Along with this, another spreadsheet for recording the estimations should be created.  The estimation is compared to the previous ones recorded in a spreadsheet so as to see if they have similar trend.  If the estimation has any deviance from the recorded ones, then it is indeed essential to a re-estimation of the entire project.

9th Rule: Risk factors should be covered in Estimation

Product down time, resource unavailability, skill improvement and learning capability are some of the risks that should be covered in test estimation.

Scenario for an Estimation:

Assume you have a project and you have estimated that it will take a 10 person team 300 days to complete. (3000 workdays – Sunny day scenario)

Knowing that there are 365 working days in a year (52 weeks x 5 days), without holidays, means that the project, at best, will take 1.13 years or 13.6 months to complete.

Suppose the average year includes 12 days company holidays (total impact = 12×10 people = 120 daysx1.13years = 136 days) and average employee takes 4 sick days and 3 comp days off a year (total impact = 7 x 10 people = 70 x 1.13 = 79)

Average employee takes 7 work days of vacation a year (total impact = 7 x 10 people = 70 x 1.13 = 79)

Suppose also that each employee drops 3 days out of each year for training (30 days)

Total duration change due to employee holidays, sick time, vacation and training = 136+79+79+30=324

Total workdays for the project is now 3000+324 = 3324 or a 10.8% increase in duration (300 day schedule is now 333 days or 15.1 months.)

Latest Posts
31
Jan

Project Estimation Techniques

By globalsqa No comments yet , ,

If you want to be successful in Project Test Estimation then you should have execution knowledge which is eventually very significant in Software Testing Life Cycle. Software Test Estimation Techniques are indeed essential to make good reputation with your client when you bid for testing projects. It also gives you idea that how your approach should be during the execution of the project.

In case, you have experience in various software testing life cycle then chances are higher that you estimate your project very well as your experience may help you in providing various ideas & techniques for that testing project. It is practically not possible to put some number of days or estimate with old time formula of one third of the development effort. The requirement keeps on changing from client side & we have to adjust the same accordingly. Some companies which offer testing services use this formula which isn’t correct as it is not based on any scientific techniques or principles.

Following factors are indeed essential for any software test estimation and they are highly recommended in any software testing organization.

  • Team Knowledge on the subject/skills
  • Historical data for the previous estimation for improvement and accuracy
  • Domain Knowledge and core requirements
  • Risks and complexity of the application
  • Team Knowledge on the subject/skills
  • Bug cycles for the project
  • Estimation should include buffer time
  • Resources availability (Like vacations, holidays, and sick days can have a great impact on your estimates)
  • Bug cycles for the project

Many techniques are used in recent years that have been developed for test estimation of the software.

Some of the Estimation Techniques are:

 Following are the popular Test Estimation Techniques:-

Use – Case Point Method:

Use-Case Point Method is completely based on the use cases that we calculate the un-adjusted actor weights to determine the software test estimation.

Use case is a document which well specifies systems, different users or other stakeholders that interact with the concerned application. They are certainly named as ‘Actors’. The interactions achieve some defined goals hence protecting the interest of all stakeholders via flow termed or different behavior as scenarios. 

The formula used for this technique is:

  • Unadjusted actor weights = total no. of actors (positive, negative and exceptional)
  • Unadjusted use case weight = total no. of use cases.
  • Unadjusted use case point = Unadjusted actor weights + Unadjusted use case weight
  • Determine the technical/environmental factor (TEF) ( if not available take as 0.50)
  • Adjusted use case point = Unadjusted use case point * [0.65+ (0.01 * TEF]
  • Total Effort = Adjusted use case point * 2

3-Point Software Testing Estimation Technique:

3-Point Software Testing Estimation Technique is completely based on statistical methods where each testing task is broken down into sub tasks and further into three types on each tasks.

The formula used by this technique is:

Test Estimate = P + (4*N) + E / 6

Whereas P = Positive Scenarios or Optimistic Estimate (Best case scenario in which nothing goes wrong and all conditions are optimal.)

N = Negative Scenarios or Most Likely Estimate (most likely duration and there may be some problem but most of the things will go right.)

E = Exceptional Scenarios or Pessimistic Estimate (worst case scenario which everything goes wrong.)

Standard deviation for the technique is calculated as,

Standard Deviation (SD) = (N – E)/6

Work Breakdown Structure:

This method is created by breaking down the test project into small pieces. Modules are separated into sub-modules. Sub modules are then further separated into functionalities and functionalities are then separated in sub-functionalities.

You should review all the requirements from Requirement Document so as to make sure that they are added in WBS. Later, figure out the number of tasks your team needs to complete. Estimate properly the duration of each task.

Wideband Delphi Estimation Technique:

Following the same procedure as above in WBS. In this, work breakdown structure is disintegrated for each task and further distributed to a team comprising of say 3-7 members so as to re-estimate the task. The final estimate is the consequence of the brief estimates that are based on the team consensus. This method actually speaks more on experience instead of any statistical formula. Moreover, this method is initially popularized by Barry Boehm to emphasize on the group iteration so as to reach to a consensus where the team visualize on the different aspects of problems whereas estimating the test effort.

Function Point/Testing Point Analysis:

The Function Point technique is a direct pointer of the functionality of software application from the user’s viewpoint. This technique is the most accepted technique that is used to estimate the size of a software project. 

This technique is also a part of TMap. In function point technique, function points are converted into test points. In Test Point analysis, we carry out following:

  • Static Test Points
  • Dynamic Test Points
  • Environmental Factor
  • Control Factor
  • Productivity Factor
  • Primary Test Hours
  • Total Test Hours
  • Control Factors

In Software Testing, estimation is generally based on previously created application prototype or requirement specification document. To calculate FP for a project, some of the major components are required.  

The major components required are:

Unadjusted Data Function Points:

  1. Internal Files
  2. External Interfaces 

Unadjusted Transaction Function Points:

  1. User Inputs
  2. User Outputs & User Inquiries

Capers Jones basic formula: 

Number of Test cases = [Number of Function Points] x 1.2

Total Actual Effort, TAE = (Number of Test cases) * (Percentage of development effort /100) 

This method is used when requirement document or a detailed low level design document is available. Previous data for development and testing & measure of function point is available.

Latest Posts