When we have features, we usually break them down to tasks that take about 1-2 days. Usually our dev tasks are not ready for QA as soon as a developer finishes developing them, but only after the whole feature is ready. That means that a few tasks (and probably a few features) would already be finished by the time QA will start testing the version. We usually try to decide ahead what bugs/features the next version for QA will have.
So, When QA open bugs they won't be directly correlated to a specific dev task but more to the feature as a whole. Moreover, our QA usually test features based on their own test plan, which is not directly connected to our development tasks on JIRA.
One possible solution for this issue, is to have all tasks belonging to a specific feature, opened as subtasks under that feature. When each subtask is finished, mark it as resolved. When QA starts testing the feature, they will open bugs under that main feature (I can link the bugs to the main feature I guess), which will go back to the 'In development' stage, till all bugs opened on it are resolved.
Another option, is to have all subtasks of the main feature as resolved, but have the main feature stays in an "Waiting for QA" column. I will move it to done only once all bugs on it are fixed.
Which solution is better ? Do you see any downsides or ways to improve that process ?
My goal is to be able to confidently say how many tasks we manage as a team to finish in week/month time(or what is the cycle time of an issue) so I can more or less know once we break features into tasks, how long it will take the team to ship them. As far as I'm concerned, finished also means verified by QA. I want to find the best way to handle our current process.