I have been very busy the last months both at work and at home (I switched from a Mumbai to Hyderabad)...
...but now I thought I should try to explain my test data model which I use for administrating tests and test environments.
First out is an overview picture of all tables and perhaps the most important table, TEST_CASE including some brief information. I will gather all table information in an RTF-document which should be available for download here: http://dl.dropbox.com/u/8538167/TestFiles/TEST_DATA_MODEL.zip
...but now I thought I should try to explain my test data model which I use for administrating tests and test environments.
First out is an overview picture of all tables and perhaps the most important table, TEST_CASE including some brief information. I will gather all table information in an RTF-document which should be available for download here: http://dl.dropbox.com/u/8538167/TestFiles/TEST_DATA_MODEL.zip
A snapshot document of my test framework data model is now available for download:
http://dl.dropbox.com/u/8538167/TestFiles/TEST_DATA_MODEL_090420.zip
What to use it for?
I think it mainly can serve as an inspiration source on how to (or how not to...) model your test framework as it is difficult to use it "as is" since it requires SQL logic (in code or in store procedures) and a bunch of GUIs (some has been published earlier).
When I read the document I realize that some things should be refactored (bit instead of varchar for True/False columns for example) but all design decisions made sense to me at the time of creation. The database is "hand-made" from scratch using SQL Server GUI to create and change tables. Columns and tables have been added from time to time ever since.
One of the reason why I choosed to use SQL Server instead of excel was that my AUT required of lot of parameters...if I do
http://dl.dropbox.com/u/8538167/TestFiles/TEST_DATA_MODEL_090420.zip
What to use it for?
I think it mainly can serve as an inspiration source on how to (or how not to...) model your test framework as it is difficult to use it "as is" since it requires SQL logic (in code or in store procedures) and a bunch of GUIs (some has been published earlier).
When I read the document I realize that some things should be refactored (bit instead of varchar for True/False columns for example) but all design decisions made sense to me at the time of creation. The database is "hand-made" from scratch using SQL Server GUI to create and change tables. Columns and tables have been added from time to time ever since.
One of the reason why I choosed to use SQL Server instead of excel was that my AUT required of lot of parameters...if I do
select distinct test_case_parameter_name from test_case_parameter the answer is 192...
