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