{"id":12308,"date":"2018-07-05T09:09:25","date_gmt":"2018-07-05T09:09:25","guid":{"rendered":"https:\/\/www.bridge-global.com\/blog\/blog\/\/?p=12308"},"modified":"2019-09-17T12:08:11","modified_gmt":"2019-09-17T12:08:11","slug":"a-quick-synopsis-on-software-test-estimation","status":"publish","type":"post","link":"https:\/\/www.bridge-global.com\/blog\/a-quick-synopsis-on-software-test-estimation\/","title":{"rendered":"A Quick Synopsis on Software Test Estimation"},"content":{"rendered":"<p>Software Test Estimation is a crucial management activity in the Software Development Life Cycle (SDLC). It plays a key role in the success of a project by ensuring proper execution of tasks.<\/p>\n<p><strong>Prior to the estimation, you need to ask a couple of questions to yourself as below.<\/strong><\/p>\n<p>\u2022 What will be the different tasks that need to be performed?<br \/>\n\u2022 How much effort would each task take? (or effort estimation)<\/p>\n<p>You will move forward with a particular approach based on the available data and the time in hand to generate the estimates.<\/p>\n<p>Some of the common effort estimation approaches take into account the software size, the WBS (Work-Breakdown Structure), project history data( if available), company\u2019s estimation software and estimation models. If the above data is not available, then we could use expert judgement as well. It is better to use multiple approaches to find out the exact effort.<\/p>\n<p>If the test effort estimates are needed quickly, then we can prefer estimating activities at a summary\/group level. Then we can use another estimation approach to know if the estimates seems satisfactory.<\/p>\n<p><strong>A Sample Test Estimation using WBS<\/strong><\/p>\n<p>You will find a sample test estimation using the technique Work-Breakdown Structure (WBS) below. This approach is used mostly for bigger projects. In this, a project is divided into smaller tasks before proceeding to do the estimation.<\/p>\n<div style=\"overflow-x:auto;\" >\n<table id = \"qa_output\" >\n<tbody>\n<tr>\n<td><strong>Task<\/strong><\/td>\n<td><strong>Notes<\/strong><\/td>\n<td><strong>Cumulative effort<\/strong><\/td>\n<td><strong>Cumulative effort in hours<\/strong><\/td>\n<\/tr>\n<tr>\n<td>QA environment or Test environment preparation<\/td>\n<td>Estimate this based on hardware installation, software installation and deployment of builds as T1, say 2 hours.<\/td>\n<td>T1<\/td>\n<td>2<\/td>\n<\/tr>\n<tr>\n<td>Testing of n requirements<\/td>\n<td>Estimate testing time as per requirement (this approach is used if the requirement are given), T2. Say there are 50 requirements and each testing time is 0.5 hour.<\/td>\n<td>T1+ T2*n<\/td>\n<td>27<\/td>\n<\/tr>\n<tr>\n<td>Negative and exploratory testing<\/td>\n<td>Use 20% extra testing time per requirement<\/td>\n<td>T1+ T2*n*1.2<\/td>\n<td>32<\/td>\n<\/tr>\n<tr>\n<td>Retesting due to requirement correction or changes<\/td>\n<td>Estimate factor T3, based on requirement correctness and stability.\u00a0 eg. T3 can be 0.1 if requirements are well put and stable or 0.5 if requirements have multiple issues or are very dynamic.\u00a0 Let us use T3 as 0.2<\/td>\n<td>T1+ T2*n*1.4<\/td>\n<td>37<\/td>\n<\/tr>\n<tr>\n<td>Logging defects and re-testing fixes<\/td>\n<td>Estimate the number of defects as T4. Estimate time to log defect, say 0.25 and time to re-test a fix, say 0.25. Say 10 defects<\/td>\n<td>T1+\u00a0\u00a0\u00a0 T2*n*1.4+T4*.25+T4*0.25<\/td>\n<td>52<\/td>\n<\/tr>\n<tr>\n<td>Regression testing<\/td>\n<td>Estimate this effort based on the impact of the requirements implemented. Defect and depth needed as T5, say 5 hours<\/td>\n<td>T1+\u00a0\u00a0\u00a0 T2*n*1.4+T4*.25+T4*0.25+T5<\/td>\n<td>57<\/td>\n<\/tr>\n<tr>\n<td>Reserve<\/td>\n<td>Having this reserve helps to provide time\u00a0 to complete unforeseen tasks,\u00a0 Estimate the reserve as\u00a0 T6 between 5 and 10 % of overall effort, say 5%<\/td>\n<td>T1+\u00a0\u00a0\u00a0 T2*n*1.4+T4*.25+T4*0.25+T5 + T6<\/td>\n<td>60<\/td>\n<\/tr>\n<tr>\n<td>Communication<\/td>\n<td>Estimate the daily effort in hours on meetings and reporting as T7,say 0.5, Multiply it by team members T8 say 2 and number of testing days T9 days 4<\/td>\n<td>T1+\u00a0\u00a0\u00a0 T2*n*1.4+T4*.25+T4*0.25+T5 + T6 + (T7*T8*T9)<\/td>\n<td>64<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n<p><strong>Other Estimation Techniques<\/strong><br \/>\n<em><strong>A. Delphie Method<\/strong><\/em><br \/>\nThis method is based on surveys. It basically collects the information from participants who are experts. The moderator makes a team of knowledgeable persons who will be assigned the task of estimating a requirement. Every estimation will be collected by the moderator itself, then he\/she compares the result. If any diverging estimation is found, he\/she calls for another round and estimation will be done (only for diverging estimation). This process will be repeated until the estimation is within an acceptable range.<br \/>\n<em><strong>B. Three Point Estimation Method<\/strong><\/em><br \/>\nThis estimation method is similar to WBS. In this, tasks are broken down into subtasks and three types of estimations are done into sub pieces.<\/p>\n<p>To calculate an estimation for a task called \u201cTest Case Preparation\u201d, use the below formula:<\/p>\n<p><strong>E= (a+4m+b)\/6<\/strong><\/p>\n<p>a = best case to complete the task<br \/>\nm = Most likely case to complete the task<br \/>\nb = Worst case to complete the task<br \/>\nE= Weighted average<\/p>\n<p>The next step is to find the probability that the estimation is correct. To get this, use the below formula:<\/p>\n<p><strong>SD = (b-a)\/6<\/strong><\/p>\n<p>SD = Standard Deviation<\/p>\n<p>So to complete the task \u201cTest Case Preparation\u201d you may need E \u00b1 SD man hours.<\/p>\n<p><strong>Risks with Test Estimation<\/strong><br \/>\nBelow are a few risks associated with Test Estimation:<\/p>\n<p>\u2022 Missing of important details due to hidden factors.<br \/>\n\u2022 Over or underestimations<br \/>\n\u2022 It is based on thinking<br \/>\n\u2022 Resource risks<br \/>\n\u2022 Technical risks<\/p>\n<p><strong>Should we revise the test effort estimates?<\/strong><br \/>\nWe must revise the estimates whenever there are material changes in the project. For example: new features added to the system under test, new types of testing like load testing is needed and resource changes.<\/p>\n<p>We can also improve our test estimation by comparing the actual effort data at the end of the project.<\/p>\n<p><strong>Conclusion<\/strong><br \/>\nThere are a lot of estimation techniques available other than mentioned here, like Functional Point (Estimating by analyzing the complexity of functionalities), Use Case Point Method (based on the use cases) and Expert Judgements. If your organization has its own process for estimation, it is always better to compare your estimation hours with two or three other estimation techniques. This helps us to have a clear idea about how effective is our estimation.<\/p>\n<!-- AddThis Advanced Settings generic via filter on the_content --><!-- AddThis Share Buttons generic via filter on the_content -->","protected":false},"excerpt":{"rendered":"<p>Software Test Estimation is a crucial management activity in the Software Development Life Cycle (SDLC). It plays a key role in the success of a project by ensuring proper execution of tasks. Prior to the estimation, you need to ask &hellip;<!-- AddThis Advanced Settings generic via filter on get_the_excerpt --><!-- AddThis Share Buttons generic via filter on get_the_excerpt --><\/p>\n","protected":false},"author":102,"featured_media":12337,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,18,101],"tags":[],"class_list":["post-12308","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technology","category-software-development","category-validation-testing"],"featured_image_src":"https:\/\/www.bridge-global.com\/blog\/wp-content\/uploads\/2018\/07\/Software-Test-Estimation.jpg-final.jpg","author_info":{"display_name":"Robin Babu","author_link":"https:\/\/www.bridge-global.com\/blog\/author\/robin\/"},"_links":{"self":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts\/12308","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/users\/102"}],"replies":[{"embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/comments?post=12308"}],"version-history":[{"count":18,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts\/12308\/revisions"}],"predecessor-version":[{"id":28347,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/posts\/12308\/revisions\/28347"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/media\/12337"}],"wp:attachment":[{"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/media?parent=12308"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/categories?post=12308"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.bridge-global.com\/blog\/wp-json\/wp\/v2\/tags?post=12308"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}