A company I've started working for uses a QA process I haven't come across before, and it seems flawed to me. I'm keen to know what we should do to fix this process.
We use a JIRA workflow. After our developers have sent a new/fixed software item to QA, we will fail the item if the new/fixed functionality is incorrect. We will also fail the item if regression testing fails, indicating that the change has introduced a new bug.
What I haven't come across before is our process if any of the following come to light during testing:
A baseline bug is discovered (i.e., a bug that was already present in the software before the new version was created);
The usability of a new feature is realized not to be ideal, so that although the new version meets the specification, we need to specify it differently and make a new change to the software;
A new business requirement comes to light, such that we need to re-spec and make a new change to the software.
In cases like these we are encouraged by management not to create a new work item, so we regularly have to return such items to the developers as "failed" in order for the new software change to be made. This makes it somewhat complicated to keep track of changes in JIRA, as any one JIRA item can become somewhat confusing, with different issues at different stages of completion logged against the one item, whose title may no longer be meaningful in the context of the current focus. Also it does create bad feeling with the developers, who understandably feel their fix has not "failed", and can even end up being disciplined by the company for items taking longer to develop than originally estimated, or the number of times their items have been returned as failed from QA .
What change should we make to our QA process to overcome this issue?