Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
When estimating effort for a user story, is tester supposed to estimate only the testing effort or the whole team effort?
If the story is technically challenging but relatively easy to test should I vote with a high or a low vote?
And vice versa, maybe it is easy to implement, but complex to test. In that case, let's say the developer and the analyst vote with 3 and I vote with 8, who would be listened to?
I think that estimation should be given by people who will eventually do the work. That means every role gives and estimate and you put them together.
It will always be a bit innacurate, but to me, it still seems much better than when someone else who does not do my type of work estimates how much I will spend on something. The room for error seems bigger in this case.
My personal experience is with two situations:
Scenario #2 really works only because I'm overly communicative when it comes to saying and promising when something is completed. So I manage to communicate more real estimates to the team even though no one really asks me. This approach also crumbles in many situations, but it's not completely up to me to change it in the company, even though I point this out every now and then.
So, to answer your question: based on what I think works better is a Tester estimating only their work (testing effort), and other people/roles estimate their work.
I think the effort depends on the definition of "done".
We estimate in relative complexity using Fibonacci points, as a Tester I compare the following complexities to give my overall gut-feeling effort in points, compared to recent delivered features.
I consider the following, from top to bottom:
We as a team all vote on complexity on the same time. If testers disagree with developers, it sometimes is because they did not take test complexity in consideration. I then explain what I think and then we re-vote. We nearly always take the highest number in the room of the second vote.
So I like it if the whole team, including testers consider the whole delivery in their estimation, but focus on parts that other roles might forget.
Considering only complexity and not hours does have it flaws. Watch the short talk: 7 minutes, 26 seconds, and the Fundamental Theorem of Agile Software Development. It is about essential complication versus accidental complication. I think this is also the reason that estimating software development is so hard.
Testers should not estimate effort only for themselves, but rather they should collaborate with the other members of the team to estimate the effort required to complete a user story. The effort estimate should take into account the testing effort as well as the effort required for development, analysis, and any other tasks that will be required to complete the story.
When a story is technically challenging but relatively easy to test, it would typically be voted with a high vote. This is because while the implementation of the story may require a significant amount of effort, the testing of the story will likely not be as time-consuming.
On the other hand, if a story is easy to implement but complex to test, the tester may vote with a higher number than the developer and analyst. However, the final vote would depend on the team's consensus, as each member's perspective and expertise is important for determining the effort required for the story. Ultimately, the team should come to an agreement on the final vote, taking into account all the perspectives and expertise in the team.
Yes, we generally provide effort in hours from QA point of view as well. Because when we are planning the sprint, we consider QA efforts as well in considering the user story done. It is a good practice that every one in the team provide estimates so that your proposed time line does not get affected.
