Explain Manual Testing Estimation Models with Examples?

Manual testing estimation is the process of estimating the time and resources required to complete manual testing activities.

It involves breaking down the manual testing process into smaller tasks, estimating the time required to complete each task, and then aggregating the estimates to determine the overall testing effort.

There are several manual testing estimation models are available that can be used as below

1)Expert Judgment:

In this manual test estimation model relies on the overall experience and expertise of individual manual testers or test teams to estimate the manual testing effort required.

Manual Testers with experience in similar projects can provide more accurate estimates.

Expert Judgment Estimation Model Example

A testing manager with experience or gut feeling in testing similar applications can estimate the time required to complete manual testing based on the size, complexity, and technology used in the current project.

2) Three-Point Estimation Model :

In this estimation model testers estimating the best-case, worst-case, and most likely time required for each testing task, and then calculating the average estimate.

Three-Point Estimation Model Example:

For a specific manual testing task, a manual tester might estimate

• the best-case scenario to be 2 hours,
• the worst-case to be 8 hours, and
• the most likely time to be 4 hours.
• The average estimate would be (2+8+4)/3 = 4.67 hours.

3) Work Breakdown Structure(WBS):

This estimation model involves breaking down the manual testing process into smaller, more manageable tasks, estimating the time required to complete each task, and then aggregating the estimates to determine the overall testing effort.

WBS Login page Example :

To get the estimation for the web application login functionality testing, overall testing process can be broken down into tasks such as

• Test Planning – 3 hours
  • Define testing objectives and scope for login functionality – 1 hr
  • Identify testing resources required for login functionality testing – 1 hr
  • Determine test methods and techniques for login functionality testing – 0.5 hr
  • Develop a test plan and schedule for login functionality testing – 0.5 hr

• Test Design – 3 hours
  • Identify test scenarios and cases for login functionality testing – 1 hr
  • Develop test cases for positive and negative test scenarios – 1 hr
  • Create test data for login functionality testing – 1 hr

• Test Execution – 5.0 hours
  • Execute test cases for login functionality testing – 0.5 hr
  • Verify that users can login with valid credentials – 0.5 hr
  • Verify that users cannot login with invalid credentials 0.5 hr
  • Verify that error messages are displayed for invalid credentials 0.3 hr
  • Verify that the login page is secure and cannot be bypassed 0.2 hr
  • Test the “Remember Me” functionality 0.5 hr
  • Test the “Forgot Password” functionality 0.5 hr

• Defect Management – 3 hours
  • Report and track defects found during login functionality testing 1 hr
  • Verify that defects have been fixed in subsequent releases 1 hr
  • Retest defects to confirm they have been resolved 1 hr

• Test Closure – 2 hours
  • Analyze the results of login functionality testing 0.5 hr
  • Create a test report for login functionality testing 0.5 hr
  • Evaluate the overall success of the testing effort for login functionality 0.5hr
  • Identify and document any lessons learned from login functionality testing. 0.5 hr

Each task can be estimated individually, and the estimates can be aggregated to determine the overall testing effort – 16 hours

4)Function Point Analysis:

This estimation model involves estimating the size and complexity of the software application, and then calculating the testing effort required based on the size and complexity.

Function Point Analysis Estimation Example:

Assume that we are developing a web-based application login functionality

Based on the requirements, we can identify the following three types of functions:

• External Inputs (EI): These are user-initiated inputs that affect the state of the web application login. For example, entering a username and password to log in.
• External Outputs (EO): These are user-initiated outputs that provide information to the user. For example, displaying an error message if the username or password is incorrect.
• External Inquiries (EQ): These are user-initiated inquiries that request information from the web application login. For example, requesting a password reset email.

Next step , we need to assign weights to each of these function types based on their level of complexity. We can use the following weight scale:

Simple: 3
Average: 4
Complex: 6

For the login functionality, let’s assume the following function point counts:

• 1 External Input (EI), with an average complexity weight of 4
• 1 External Output (EO), with a Complex complexity weight of 6
• 1 External Inquiry (EQ), with a Complex complexity weight of 6
• Based on these counts and weights, we can calculate the total function points for the login functionality as follows:

Total Function Points = (1 x 4) + (1 x 6) + (1 x 6) = 16

For example, assuming a productivity rate of 8 function points per person-day, we can estimate that the login functionality will require approximately 2 person-day of effort.