When your Product Owner ask a general question on how you QAs performed this year, you need to give three dimensional answer:
Estimation that gives the results of entire team (Refer no.1 section in answer)
Estimation that gives special efforts from QA (Refer no.2 section in answer)
Estimation specific to Test Automation (if any) (Refer no.3 section in answer)
1. Important Estimations for the Agile Testing Activities:
Test Estimation Formulas in Agile Testing Projects
Once you have worked in the team for some time using some method you can then calculate the velocity of the team.
‘Velocity in simple terms means how many story points on an average can we manage to finish in one sprint of a particular length with X number of developers.’
With time the calculation will get better and better and your predictions will then get more accurate.
Personally me and my team currently have a favorite method called ‘sorting poker’ method. We mixed two methods available out there and made one of our own. What we do in our sprint planning is first we go through all the stories to be done in the backlog in this sprint and then identify the smallest task on the board. After that we start sorting all the other stories with regards to the smallest story and sort it in ascending order. Once all the stories are sorted we start with planning poker. Everyone in the development team gets to pick one number for the smallest story. If there are different number, then we put time for discussion and agree on one smallest number for the story as our base story point for the sprint. Then we move on to the second story which is identified as slightly bigger than the smallest story and we play poker again, decide on a number when everyone is in agreement. When we move on to the 3rd story we remove the number used for the smallest story if the second story point was higher than the first one. This makes its so much easier to estimate further stories. Surely, it takes time for going through all the stories and sorting it in the beginning but when we utilize the first hour of our meeting doing the sorting the estimation goes so fast that we sometimes finish the sprint planning way before time as the estimation then becomes super easy.
Pro-Tip: I usually have a pre-sprint planning with my development team where I do a walk through for them explaining them the user stories and the goal. I usually do this one week before to the sprint planning just for an hour and then give them that week to think about how we can achieve that goal. This makes it easier for all the developer to come up with the easiest solution and also think through multiple variation of possibilities before the sprint planning.
- Test Estimation on various Test Estimates and respective calculation:
Case: Surendar Singh, a test manager of Aditi Solution Tech. Ltd. has planned three weeks testing of 15 working days to complete the testing cycles of approximately 850 test cases. It has been planned as follows: 850/(154)=14 test cases per person/per day, henceforth, he has targeted at least 15 test cases to be performed to meet the deadline. Paul from the team has gone in surprise leave on the very first week for 4 days and this would have affected 414 test cases =52 test cases of the project in a particular module. As a twist to the story, another team staff has gone in sick leave for two days in the middle of the test cycle which created additional backlog of 28 test cases on top of 52 existing backlogs, and Surendar has no other option than increasing the duration of the project at the last week which has created tension around the delivery date. This situation shows a clear example of poor planning from the test management. If leaves were organized earlier and Surendar had planned at least 16 working days of tests to include 2 days as backup, then it would have sort out the leave issues on time. Because the total backlog of tests 80 (means 52+18) would have executed with the help of last working day availability.
- Test Automation Estimation Techniques:
Time and complexity for a given testware architecture implementation
While the effort estimation for a TAS project is the responsibility of a TAM, a TAE needs to support a TAM
in this by providing good estimates for the time and complexity of a TAA design. Methods for estimations
and examples include the following:
- Analogy-based estimation such as such as functions points, three-point estimation, wideband
delphi, and expert estimation
- Estimation by use of work breakdown structures such as those found in management software or
- Parametric estimation such as Constructive Cost Model (COCOMO)
- Size-based estimations such as Function Point Analysis, Story Point Analysis, or Use Case
- Group estimations such as Planning Poker
https://www.youtube.com/watch?v=vTRUXAd7E4U (Very Important Reference)