DB for tracking Testing

outofpractice

Registered User.
Local time
Today, 13:22
Joined
May 10, 2011
Messages
32
First let me say I browsed but did not find anything matching this but if I missed it please feel free to point me in the right direction. Also, thanks in advance for any input.

OK - so currently when keeping track of my test cases I have a spreadsheet and just go down the list on them making then Pass/Fail. What I would like to do is to create a DB to do this instead. What I am thinking is to have a table with the "Test Case" - each test case would then be able to have X number of steps with a Yes/No box and a note field corresponding to each step - the Yes/No would equate to Pass/Fail.

Then what I would like to do is have a "Project" folder which would essential contain one Project but could have multiple "Test Cases". I could then enter in my project number on a form and go down and select from a combo box "Test Case 1" which would open up a sub-form that has a list of all of "Test Case 1" steps I could then mark Pass/fail. Close that form and if needed on the project I could then select "Test Case 2" and so on.

I am struggling with how to set this up so that each test case and its steps can be attached to many different projects and if I write a note in one of the steps it will not appear with every project that I use the test on.

I hope what I am asking for makes sense - essentially I want to be able to tie one Project to multiple tests but these tests need the ability to also be independently connected with many projects. Thanks for any assistance.
 
Based on your description, you have the following relationships:

A project can have many test cases: one-to-many relationship

A test case can have many steps: one-to-many relationship.


Two questions:
Can a step be applicable to more than one case?
Can a case be applicable to more than one project?
 
Two questions:
Can a step be applicable to more than one case?
Theoretically it could, but that is not my intention. For each test case I am thinking it should have a unique list of steps. I'll try to explain what I mean with the following example (hopefully I am being clear).

Project = Change to Form A
Test Case = Form A Testing (It has X number of steps to test changes to Form A to make sure it is still working)
One of the steps is something like "Special Characters in First Name field"

I could also have

Project = Change to Form B
Test Case = Form B Testing
One of the items I test is special characters in the first name field

Both of these tests are checking the results of special characters in the first name field, but I do not intend to have a one-to-many relationship of that test run to many different test cases. Does that make sense?


Can a case be applicable to more than one project?
Yes - for example our forms have electronic signatures which is a service that is shared amongst forms. Anytime there is form change, one of the items I check are all of the electronic signature functions to make sure it is still working. So going back to the above example, if there was a Project to make a change to Form A and one to change Form B, I would be using my list of electronic signature tests on both of those.

I hope those explinations make sense. Thanks
 
"Special Characters in First Name field"

One of the items I test is special characters in the first name field

The task sounds like it accomplishes the same thing, you just use different words. If you intend to do searches, it would make things alot easier to standardize the text.

Assuming that the steps are unique as you say in your post, the structure would look something like this:

tblProjects
-pkProjectID primary key, autonumber
-txtProjectName

tblCase
-pkCaseID primary key, autonumber
-txtCase
other fields related to the case

tblProjectCases
-pkProjectCaseID primary key, autonumber
-fkProjectID foreign key to tblProject
other fields related to the combination of project/case

tblProjectCaseSteps
-pkProjCaseStepID primary key, autonumber
-fkProjectCaseID foreign key to tblProjectCases
-txtStep

Now if you decide to standarize the steps, then you would need the following

tblSteps
-pkStepID primary key, autonumber
-txtStep

And you would modify tblProjectCaseSteps as follows

tblProjectCaseSteps
-pkProjCaseStepID primary key, autonumber
-fkProjectCaseID foreign key to tblProjectCases
-fkStepID foreign key to tblSteps
other fields
 

Users who are viewing this thread

Back
Top Bottom