Saving Multiple Versions of a Record

dancole42

Registered User.
Local time
Yesterday, 22:59
Joined
Dec 28, 2012
Messages
21
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 think your best practice is the record set.
As I understood from your detailed explanation that you need to store the data of records for later inspection but you don't want a duplicated records
The best thing you do is to use the recordset on the If function as like;
On error go to ErrHandler
'Your whatever procedure for save or submit or anything you use

ErrHandler:
'Write here your code to insert the current record data into the bug table with its current information for later inspection

And on the form where you handle the errors and after fixing it you can use the recordset to update your table data for the original record location

I think the recordset is your proper Tool
 
I think your best practice is the record set.
As I understood from your detailed explanation that you need to store the data of records for later inspection but you don't want a duplicated records
The best thing you do is to use the recordset on the If function as like;
On error go to ErrHandler
'Your whatever procedure for save or submit or anything you use

ErrHandler:
'Write here your code to insert the current record data into the bug table with its current information for later inspection

And on the form where you handle the errors and after fixing it you can use the recordset to update your table data for the original record location

I think the recordset is your proper Tool

I'm sorry, I'm not sure I understand. What do you mean, "use the recordset"? What does that mean? What about the table structure?
 
For my knowledge in Access if you want to transfer data from table to another the recordset is the best tool if that is not what you are looking for then kindly wait lots of expertise are reading the posts daily you might get a better answer and am sure you will
 
Not do dampen your enthusiasm, but I am curious: why are you writing your own issue & bug management db?

I have set up two issue management systemes in companies, and this is not something I'd want to code myself, especially since there exists a plethora of open source, shareware and commercial solutions, hosted or not. Writing it yourself is like creating your own textprocessor. Even if you desire some features absolutely unique to your business, it still might be more efficient to modify some existing solution. Or is this some academic assignment?
 
Not do dampen your enthusiasm, but I am curious: why are you writing your own issue & bug management db?

I have set up two issue management systemes in companies, and this is not something I'd want to code myself, especially since there exists a plethora of open source, shareware and commercial solutions, hosted or not. Writing it yourself is like creating your own textprocessor. Even if you desire some features absolutely unique to your business, it still might be more efficient to modify some existing solution. Or is this some academic assignment?

I've looked at multiple solutions, and none of them are as streamlined as I'd like, or function exactly the way I want. I'm particularly interested in developing a system that works equally well for internal tracking as well as generating client-facing reports, like UAT guidelines and release notes.
 
I'm with spikepl on this -- there are databases out there.
http://office.microsoft.com/en-us/templates/desktop-bug-tracking-database-TC010350815.aspx you could extend if necessary.

I'm curious as to whether or not you have a list of features that you -
a) must have
b) would like to have

and have you compared the list to existing freeware/shareware offerings.

My guess is no, but I'd like to hear why you really need to design and develop this.
 
Agree with modifying an off-the-shelf to meet your standards.
I was a QA Software manager for one company that had over 40 programmers/dba for a project. Looked at and bought a $200 USD program. Other projects were large enough to where I had a staff of over a dozen QA engineers.

I actually could have developed it myself. But, the time delay would have cost the company thousands of dollars a day for the months for the extra time vs an Off-the-shelf equal system to be deployed.

My activities included the board level, investors, client level and engineering staff reports, guidlines and release notes. That is exactly why the cost-effectiveness of choosing an Off-the-shelf was so important.

None of the tracking systems I evaluated for purchase were exactly perfect as you mention. There was modification and additional modules to be created. Some parts of the off-the-shelf program, I just totally ignored as useless for my situation.

Best of luck. Just the idea of some old guy here.
 
Plenty of candidates here: http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems and here: http://en.wikipedia.org/wiki/Comparison_of_help_desk_issue_tracking_software

Honestly - developing your own is a very costly exercise, compared to tested verified systems out there, where hundreds havde contributed with bug reports, and the systems have been through the birth pangs. Your text implies you want to make some type of swiss army knife - a hybrid to tackle bug reports, but also UAT ... and perhaps usere interaction, updates of data on a single issue/ticket, the workflow with mailing/assigning/closing/following up on issues.. etc etc ... this is not a small task, even for an experienced programmer.
 

Users who are viewing this thread

Back
Top Bottom