So I guess this is kind of a theory / best practices question.
I'm writing a bug and issue tracking database for a small business that's going to involve issues at multiple levels (e.g. account managers, product managers, developers, QA, clients, etc.). I envision the issues going through a series of queues, and I'd like to save the issue as it appears in each queue:
Submitted => Reviewed & Confirmed => In Progress => Ready for QA => QAed => In Production
The database will record things like name of bug, URL, steps to reproduce, etc. In the end, something like "steps to reproduce" will become "steps to test." For example:
Step 1 - Enter password
Step 2 - Submit
Step 3 - Error 404
Becomes:
Step 1 - Enter Password
Step 2 - Submit
Step 3 - Log In Successful
What I'd like to do is save versions of the bugs as they appear in each queue. That way, it's easy for the devs to copy the steps to reproduce and turn them into QA testing steps, QA can compare and verify that the bug as resolved matches the correct resolution to the bug as reported, etc.
I'd also like this system to be extensible, so if I wanted to add "Sales Review" as a potential step it's simply a matter of adding a record to a list of queues.
One option I considered was something like:
tbl_Bugs
bug_id
BugName
Queue_id
field1
field2...
tbl_Queue
queue_id
QueueName
And then on the form, whenever the bug moves to a different queue, the record gets duplicated in tbl_Bugs but tied to a different queue. The original bug is saved as-is in tbl_Bugs (or moved to something like tbl_BugArchive), and the new instance of the bug can be modified at will.
The problem with this is that, if only one or two fields end up needing to be changed, you end up with a ton of duplicate data. I'm not worried about storage, it just seems like a bad practice.
Another alternative would be to store every field that MIGHT be modified through queues, such as Steps, in their own table. The problem there is that, what happens if a field I hadn't considered now needs to be modified?
Another alternative would be to have a separate bug table for each queue that only stores information needed for that particular queue. For example, a developer might record a QA URL for testing, but that wouldn't be stored with the original bug submission from a client. The issue here is that you again run into some duplication, and if I need to add or remove a queue it means creating new tables for each queue.
Any suggestions?
Thanks!
I'm writing a bug and issue tracking database for a small business that's going to involve issues at multiple levels (e.g. account managers, product managers, developers, QA, clients, etc.). I envision the issues going through a series of queues, and I'd like to save the issue as it appears in each queue:
Submitted => Reviewed & Confirmed => In Progress => Ready for QA => QAed => In Production
The database will record things like name of bug, URL, steps to reproduce, etc. In the end, something like "steps to reproduce" will become "steps to test." For example:
Step 1 - Enter password
Step 2 - Submit
Step 3 - Error 404
Becomes:
Step 1 - Enter Password
Step 2 - Submit
Step 3 - Log In Successful
What I'd like to do is save versions of the bugs as they appear in each queue. That way, it's easy for the devs to copy the steps to reproduce and turn them into QA testing steps, QA can compare and verify that the bug as resolved matches the correct resolution to the bug as reported, etc.
I'd also like this system to be extensible, so if I wanted to add "Sales Review" as a potential step it's simply a matter of adding a record to a list of queues.
One option I considered was something like:
tbl_Bugs
bug_id
BugName
Queue_id
field1
field2...
tbl_Queue
queue_id
QueueName
And then on the form, whenever the bug moves to a different queue, the record gets duplicated in tbl_Bugs but tied to a different queue. The original bug is saved as-is in tbl_Bugs (or moved to something like tbl_BugArchive), and the new instance of the bug can be modified at will.
The problem with this is that, if only one or two fields end up needing to be changed, you end up with a ton of duplicate data. I'm not worried about storage, it just seems like a bad practice.
Another alternative would be to store every field that MIGHT be modified through queues, such as Steps, in their own table. The problem there is that, what happens if a field I hadn't considered now needs to be modified?
Another alternative would be to have a separate bug table for each queue that only stores information needed for that particular queue. For example, a developer might record a QA URL for testing, but that wouldn't be stored with the original bug submission from a client. The issue here is that you again run into some duplication, and if I need to add or remove a queue it means creating new tables for each queue.
Any suggestions?
Thanks!