2

I'm currently trying to decide what is the better place to store my test results; database (sql/nosql) or in a spreadsheet placed in google docs.

I have the impression that storing it into a database will be a bit more work initially but will have lots of benefits in the future, where as placing them in a spreadsheet could be quicker to implement but will be limited in the future.

This project is a bit time sensitive but I definitely want to do it the right/best way.

There will be quite a bit of test results generated from all the automated test run.

The test results will need to be analyzed daily possibly hourly. On a daily basis the results would be used to generate reports/graphs.

My concern with using google docs is that consolidating data and combining data together could be an expensive operation. Although google docs already has a front end implemented so users can manually manipulate data.

Also the database implementation seems to be more scalable than using spreadsheets.

Because of the time constraints it's hard for me to test out by solutions so any thoughts, personal experiences, and expertise would be greatly appreciated.

2

Unless you have a clear demand on automated processing I would tend to storing results in Google Sheets. Here are few points for the choice:

  1. You can easily manage the data from wherever you are since it is world-wide accessible service (and has the client applications implemented for all the famous platforms)
  2. Sheets provide some data analytics tool-set
  3. You can easily control the access of other people to your data
  4. Google Sheets support programmatic usage via API

These points will let you feel comfortable with your test result management. Even more if you develop the proper data structure for your test result you will be able to migrate data from Google Sheets to your own database (for example for the sake of scalability, however I don't believe this would be critical issue unless you have terabytes of data)

1

I think based on your second paragraph mentioning future benefits of SQL-style, plus the need to bring in a lot of results, go that way now. The points made by Alexey R are good though.

Designing a database to hold test results can be tricky. Ensure you have something to uniquely identify each run, and info to hold SUT configet info, parameters, so forth.

Work backwards; spec out in Excel or other spreadsheet what your typical summary report needs to look like. That gets you started on the columns that need to be in the database.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.