How to implement QA time estimate in a simple manner

[Ivar]

We held a discussion regarding the difficulties encountered by QAs. One of the identified issues that usually affects the team as a whole is that the rest of the team (specially the developers) are somehow "blind" when it comes to the complexity and/or amount of time that the QAs might be needing for a certain issue to be extensively tested. This is due to the fact that the estimation of story points are based on the developer's intuition and in turn partially disregards QA's perspective.

As such, QAs are proposing to have some sort of a "QA time estimate" on each JIRA issue so that the team would be better equipped with information as to the amount of time that the issue will consume for testing. This will also help us as a guide in identifying "issues (or story points) versus time remaining" in a certain sprint.

This can of course be done by just adding an additional field and add either story points for QA, time estimates or just enable it as a dropdown with default values. Or is there any other way?

[Nic Brough -Adaptavist- · Accepted solution]

I'd be strongly tempted to create a sub-task type of QA and then use the timetracking in there. It'll roll up to the main issue and remain independent of the development work.

[Ivar]

I guess I would have to estimate them in hours instead of story points to avoid them having an impact on the dev. burndown..?

[Ivar]

Nice idea. And then estimate as "usual".

[Nic Brough -Adaptavist-]

The issue sub-type is mostly a really useful construct here - your QA people can easily run filters for "QA stuff only", and your developers can ignore them :-) It also frees you up to have a different workflow and fields on QA items if you want. The only downside is remembering to create them...

[Deleted user]

Nice Idea Nic & Ivar

[Manohar Venkataraman]

If I have an Enhancement, I want to promote it from BA-->Dev-->QA-->UAT and have a way to have 4 different time estimates and 4 ways to record time against the same issue while having them roll up to a single number. Adding 4 different subtasks to this single issue vastly overcomplicates what should be the standard SDLC scenario.

Please vote for this ticket which addresses this: https://jira.atlassian.com/browse/JRA-872

[Carlos Lopez]

This enhancement would be so helpful for QAs we dont like how Sub-task work and are visually displayed in JIRA, So we put all the time (including testing) in a JIRA (developer) ticket. It would be beneficial when logging time to a ticket and it pulls from either Developer time, QA timer, Migration Time, and etc. 

[Nic Brough -Adaptavist-]

Atlassian closed that issue years ago as pretty much "won't do", because Jira is pitched at an Agile market, and doing testing/QA separately from the delivery is a failure to be agile. 

If you are trying to be Agile, testing is built into the team's work, you don' t estimate it separately outside the team.  

Go back and have a look at your "definition of done" for each team.  I suspect you will find that the problem is that your teams are working in an waterfall manner, but asking an agile tool to support it.   That won't work.