Test data in XLS or SQL database.
Could you please share your thoughts on having test data in .xls or in database tables? Currently all of my test data is in .xls and there have been discussions by the managers to have it in database. I somehow do not want to have it in database because of below,
- Need to spend lot of time inserting data into the tables by writing insert SQL statements. Import feature might work but needs lots of tweaking to the .xls sheets.
- Any modification to test data again requires understanding where the issue is by looking at multiple tables/fields. The project that I work on have many input fields.
- DB backups do not happen everyday, and someone accidentally might delete the data (i am sure it will happen ).
- When reviewing the test case / test data, it again involves looking at multiple tables in figuring out.
I feel the productivity of the QA engineer will decrease. Did any of you use test data from a database table? Please share your thoughts or experiences.
Generally I prefer to use factories, and run tests off clean databases.
Factories are like wrappers around test data creation fixtures. They handle dependencies between data, and return objects that contain the test data created.
Factory girl is one of the more popular libraries out there. Rails Testing ? Factory Girl
The cool thing about factories is they can handle dependencies between data. Say I'm testing a blog site, and I need a blog post. But a blog post requires a valid user. You just tell the factory you want a blog post, and it will create the corresponding blog user for you. After the creation is done, it'll return a data fixture that contains the id's and properties of both the blog post and the created user that you can consume in your test.
This approach is commonly used in high speed integration tests. However I find it nice to use in end-to-end tests as well to reduce the maintenance overhead with keeping data parity between dev, test, staging, and production environments.
Thanks David, will try to understand Rails Testing. Do you think that could be implemented in SmartBear's SOAP UI automation project?
I prefer working with data in .xls, not for any realistic reason other than a lot of the test analysts I've worked with prefer to work with something they know rather than start worrying about learning how to handle test data in a DB. That said, I prefer to work with test data in a DB, provided that the DBs are managed properly, it's actually a lot easier to manage the test data as a complete package rather than worrying about how the .xls files are stored, backed-up, accessed, audited, etc.
Things I'd consider when making the choice:
* Who will write and maintain the test data?
* Are you just talking about raw test data to input into fields, or are you talking about test scripts, or both? (I'm assuming from your SoapUI comment you're talking about raw test data, but I may be wrong)
* What are the advantages of keeping the test data in a DB for you and your team? If you're looking to increase the ease of maintenance for the team, think about access - will it be SQL scripts or will there be a GUI for them to use?
As for addressing some of your concerns:
* Exporting the .xls to .csv and then importing into the DB is usually straight forward enough - this will cover your initial data transfer, but isn't a very good process to use for inputting new test data (in other words, don't have team members writing test data in Excel, then importing it into the DB)
* Some pre-prepared select statements for pulling out all of the test data relevant to a particular test case would help view the data in one go, this is assuming that you'll know which test case to investigate before looking at the DB
* Who's administering the DB? If it's another team, then you (collectively) are their "customers" and so should be able to specify how often backups are done for your data. Aside from that, just set user's permissions so they can't accidentally delete or drop data.
* Test data reviews would benefit from the select statements mentioned above.
The concept is not "Rails Testing". The concept I want to communicate is the Factory Pattern, it's a very common pattern used by SDETs and STEs. I was just using Factory girl for Ruby on Rails as one example of the factory pattern. The factory pattern can be implemented with any programming language, and most programming languages will have a library you can use to do this.
Originally Posted by mittumiya
Tags for this Thread