I would like to know how the ppl are maintaining the Test data. As we are going to start a new project which is a big project I wanted to apply the best practices in our project.
And also I am mentioning my practice so that I can get you ppl views on my practices.
We are maintaining test data in XL sheets. Now I am Planning to maintain in SQL Server DB due to XL's limitations like some times XL is behaving odd, XL may get crashed and can't create primary, unique keys (as we do in database)..
a) Currently, we have one sheet in Test data spreadsheet that represents a screen in the application. All the columns except one column represents the fields. And that excepted column acts like an index i.e. this column (TestCase number) will be used to retrive the test data from XL.
b) I maintain seperate XL file to store any kind of expected messages. MessageID(index) and Message are the columns.
so do you see any cons in this structure? How do you maintain?
Please share your views and thoughts on this as TestData plays major role in automation.
It is quite possible to maintain test data in excel. You can create sheets as many as you want. Even it is under your control if you maintain in excel in you system. As you said you can create a summary sheet with link, when click the links it takes to the correponding other sheet where you can maintain you test data... even you hide the other sheet from other users.
About the structure to maintain the test data... it is typically depens on your application you are testing and how easy to access other test data reposts as soon you want.
I've found the approach you describe to be very useful for storing test data - especially in a database because using SQL is so much easier to implement in most automation tools than, say, an excel spreadsheet.
The downside that I've experienced with the framework you desribe (one table [or spreadhseet tab, etc] per application window) is that it can be very time consuming to add all the data for a new test case. But what is the alternative?
Do you use a table to list the flow of the test-case? This removes some of the business logic from the automation scripts (i.e. the data-driven model with driver script and function libraries).
Many projects I've been in that used database to store test data, all end up over-running the budget and created a LOT more mainenance headaches...Automation needs quick, easy solutions, not something to "hook up" the company for testers' job security.