For the completion of any project, estimation of testing and proper execution is equally essential as the development cycle. To make a good reputation with the client, sticking to the estimation Experience plays a major role in estimating the “Software Testing Efforts”. Working on varied projects helps us to prepare an accurate estimation of the testing cycle.
Evidently, one cannot simply enter several days for any testing activity. Test estimation should be both practical and precise.
This article will cover some crucial hints that will be quite useful in preparing proper test estimation in a very straightforward method.
It is the process of finding out an estimate, or approximation, which is a number that might be used for some purpose even when the input data is partial, ambiguous, or unstable. [Source: Wikipedia]
As professionals, we all encounter various jobs, obligations, and deadlines; today, there are two ways to find a solution to a problem.
The first method is a reactive strategy in which we attempt to discover a solution to the issue only after it has occurred.
In the second method, known as the Proactive Approach, we first prepare ourselves with our previous experiences long before the issue arises, and then we use our past experiences to attempt to find a solution to the difficulty when it arises.
Estimation may therefore be seen as a method used when we take a proactive approach to an issue.
Estimation may therefore be used to estimate how much effort, in terms of both time and money, would be needed to accomplish a certain job. Once the testing team has an approximation of the issue at hand, it will be simpler for them to come up with a solution that is optimal for the situation at hand.
Estimation may therefore be defined more formally as an approximation of the likely cost of a piece of labor
The fundamental essentials for the Test Estimation Process are listed below.
Insights gained from previous experience: It is usually a good idea to spend some time reflecting on previous initiatives that presented difficulties comparable to the current one.
The accessible papers or artifacts: In these kinds of situations, the test management repository solutions come in useful since they hold the requirements and clarification documents. The testing team may refer to these papers to properly describe the project's scope.
Assumptions regarding the nature of the job: Previous job experience helps in establishing project assumptions. Hiring experienced experts is critical in this situation. Testing managers may select these people's brains to produce the required outcomes.
Calculation of Potential Dangers and Threats: The testing team must also envision the potential risks, threats, and traps that the team may face in the future.
Determining whether or not the documents have been baselined: The testing team must also assess whether or not the requirements have been baselined. If the documents have not been baselined, it is critical to establish the frequency of the changes.
All duties and dependencies must be clearly defined − The organization must identify the roles and responsibilities of all individuals who will be conducting the estimate process.
Evaluating noted documentation and following: All relevant information to the estimation process should be written down.
Tasks to be completed throughout the test estimating process −
Create a team to conduct estimates.
Deconstruct the project into project stages and component activities.
Estimate based on prior projects and professional expertise.
Prioritize potential hazards and devise strategies to minimize those risks.
Examine and record the pertinent portions of the job.
Send the work to the appropriate stakeholders.
Some of the most significant test estimation methods are −
Test point estimate is a basic and easy-to-understand estimating method that is extensively utilized in the software testing industry. The most significant characteristics of this method are its iterative stages and simplicity.
Work-phase based estimation is an estimating method in which a guess estimate is made on a certain phase (often the shortest and simplest of the phases) and then the testing team progressively adds additional phases into the original estimation to arrive at an acceptable estimation.
The Use-Case Point estimation method is used to estimate software testing on use cases using unadjusted actor weights and unadjusted use case weights.
Let us attempt to put the above concept to use in another context.
Assume we have a test requirement with five test scenarios to test.
Assume that Test Scenario 1 has 5 est anticipated results, Test Scenario 2 has 6 test expected results, Test Scenario 3 has just 2 test expected results, Test Scenario 4 has 9 test expected results, and Test Scenario 5 likewise has 9 test expected results.
We divide the test scenarios into three categories: difficult, simple, and moderate, depending on the total number of anticipated outcomes in each.
Complex classes will have more than 7 anticipated outcomes, while basic classes will have fewer than 5 expected results, and intermediate situations would have 4 to 7 expected results.
As a result, we categorize test situations 1 and 2 as intermediate, scenarios 5 and 6 as difficult, and test scenario 3 as basic.
All of these situations will now be subjected to test points. We used five test points for complicated classes, three for intermediate classes, and two for basic situations.
In each of these test situations, we multiply the assumed test points by the total number of anticipated outcomes. As a result, we arrive to the following approximations −
Scenario 1: 3 test points * 5 anticipated test outcomes = 25 adjusted test points
Scenario 2: There are three exam points. * 6 anticipated test outcomes = 30 adjusted test points
Scenario 3: There are two test points. * 2 anticipated test outcomes = 4 adjusted test points
Scenario 4: There are five exam points. * 9 anticipated test outcomes = 45 adjusted test points
Scenario 5: There are five exam points. * 9 anticipated test outcomes = 45 adjusted test points
So, assuming we need to apply for, say, 5 Person Hours for each modified test point, we obtain the following approximation.
Test Scenario 1: 25 modified test points multiplied by 5 person hours is 125 person hours.
Scenario 2: 30 modified test points multiplied by 5 person hours equals 150 person hours.
Scenario 3: four modified test points * 5 man-hours Equals 20 man-hours
Scenario 4: 45 adjusted test points multiplied by 5 person hours is 225 person hours.
Scenario 5: 45 adjusted test points multiplied by 5 person hours is 225 person hours.
As a result, the total estimated person-hours are: 745 Person Hours
Given here the detailed process of the use case point estimation procedure −
Break down the universal requirement into use cases and more accurately into the actors
Count the total numbers of used case actors for all the used cases
Categorize the requirements as negative positive and exceptional according to the use actor counts
Assign an unprocessed actor weight to each of the use case actors according to their classe
Repeat the process until we received the unprocessed actor weights for all the actors
Obtain the unprocessed use case point with the unadjusted use case weight and the unadjusted actor weights
Multiply the unprocessed use case point with a pre-defined constant to obtain the real use case point estimation
As an example, in a certain need, we have 5 use cases, use case 1, use case 2, and use case 5. Consider that use case 1 has six actors, use case 2 has fifteen, and use cases 3, 4, and 5 have three, four, and five actors, respectively.
Any use case in which the total number of actors is fewer than 5 is considered negative, any use case in which the total number of actors is equal to or more than 5 and less than or equal to 10 is considered positive, and any use case with more than 10 actors is considered extraordinary.
We chose to award two points for extraordinary use cases, one point for good use cases, and one point for negative use cases.
Based on our assumptions, we classify use cases 1 and 5 as positive, use case 2 as extraordinary, and use cases 3 and 4 as negative.
As a result, the Unprocessed actor weights = Use case 1 = (total number of actors) 5 * 1 (assigned point) = 5. Similarly
Case number 2 = 15 * 2 = 30.
Repeating the procedure for the remaining use cases yields Unprocessed actor weights = 33.
Unprocessed use case weight = total number of use cases multiplied by 5
Unprocessed use case point = Unadjusted actor weights plus Unadjusted use case weight = 33 + 5 = 38
Processed use case point = 38 * [0.65+ (0.01 * 50] = 26.7 or roughly 28 Person Hours
The work phase breakdown method is explained in the stages below.
Divide the entire project into stages.
Begin with the simplest step and give an estimate value to it.
Then, after this phase is finished, determine the next potential step that may be started.
Determine a potential set of approximation values that may be applied to this phase and choose the greatest value from the list of approximation values.
Add the current phase effort estimation value to the previously existing value to get the approximated estimate value.
Steps 3–5 should be repeated until all of the stages indicated in the first step have been exhausted.
Accept the final approximation estimate value as the final word.
Assume there are five necessary stages in a requirement. In the first phase, we assume that the total effort required is 35 person-hours, and then we go on to phase 2, where we have four comparison assumptions of 35, 45, 55, and 65, respectively.
We consider the maximum value of 65 person-hours here. Estimates for phases 3 and 4 are (12, 33, 43, 54), (15, 10, 7, 8) and (2, 16, 5, 13), respectively. Using the aforementioned concept, we arrive to 185 Person Hours.
Software test estimation necessitates the participation of skilled experts as well as the use of industry-wide best practices such as test case point and use case point techniques.
It is also critical to have an open mind while customizing the necessary procedures. The effective application of these procedures leads to an improvement in the testing process as a whole.