I keep looking at various JIRA alternatives, but no good finds so far. This is definitely not it. I don't really like the idea of bug tracker as a sort of a GUI program that acts like time management software, i.e. focuses on planning work, tracking how much effort was spent, ability to add notes to tasks etc. My ideal bug-tracking software works more like Git: it has a server-client relationship where clients query…
I really appreciate your feedback here and I see where you're coming from and can agree if you're looking at Jira as a purely bug tracking / development tool. Unfortunately, and I think important to call out -- is that most companies are trying to use these tools as a "catch all" -- "a one in all solution that solves everyone's problems" and then ultimately, half of the company refuses to use the tools because it's t…
If we accept that bug tracker is to be a planning program, then QA usually needs a lot more than a free-form JIRA story can offer. QA really needs what they call "test plans".
Usually, to test a feature QA, beside writing tests, needs to organize it as an activity, which might be also relevant to release management, but in general may touch on other product life-cycle phases. This comes from the fact that some rare activities performed by QA are not worth automating, and sometimes are very hard to automate (eg. uploading the program to some kind of third-party store, where it needs to be approved by the store's moderators, sometimes requiring back-and-forth with developers / QA / release management). Other typical QA tasks would include producing reports, producing or studying release notes, studying feature definitions, and perhaps, scheduling meetings with people responsible for the said features.
Sometimes QA needs to run a proper scientific research, with all that entails: research planning and execution which are often also quite regimented, but would need to be built on top of tools like JIRA which don't offer any structure to the story, and the existing superstructures of stories (eg. epics or various links between issues) don't cover because they act more like arrays or trees, where what you want is structs / documents.
On the other side, project managers need a structured and formal way to deliver product requirements to R&D, from which QA will later have to produce tests. Again, free-form issues aren't enough here because the structure will have to be written down as free-form text, but will be very repetitive, unverifiable and lead to feature planning mistakes.
If a bug tracker offered a more structured approach to feature planning by formalizing the aspects of this process, this may lead to generation of program stubs as well as test stubs (the promise UML made but never really delivered).