Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How to implement QA time estimate in a simple manner

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?

2 answers

1 accepted

1 vote
Answer accepted

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.

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

Nice idea. And then estimate as "usual".

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...

Nice Idea Nic & Ivar

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:

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. 

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.

Suggest an answer

Log in or Sign up to answer

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you