Should testers estimate effort only for themselves

Question

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?

Answer 1

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:

• every role gives their own estimate, so as a Tester, I give an estimate of only my work, testing effort
• Tester is not even asked for estimates, so everyone hopes (for the best) the Tester will not delay anyone for an unnecessary period of time

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.

Answer 2

I think the effort depends on the definition of "done".

1. If QA is included in the definition of done, meaning a user story is marked as done only if QA is completed then the effort should include both development and testing efforts
2. If the definition of Done is "Qualified for QA testing" then only development and integration/unit test is considered
3. If, you are working on a separate test user story, independent from the development process eg in TDD. Then the only testing effort is considered

Answer 3

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:

• Testing complexity: How hard is test automation, do we have technical test debt, time to configure the system under test.
• Functional complexity: How many steps, how many permutations, how simple is the workflow
• Technical complexity: How many systems do we change, how many systems interact with this change.
• Development complexity: How complex is our high level solution

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.

Answer 4

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.