4

With a quick search over stackoverflow was not able to find anything so here is my question.

I am trying to write down the testing strategy for a application where two applications sync with each other every day to keep a huge amount of data in sync. enter image description here

As its a huge amount of data I don't really want to cross check everything. But just want to do a random check every time a data sync happens. What should be the strategy here for such system?

I am thinking of this 2 approach. 1) Get a count of all data and cross check both are same 2) Choose a random 5 data entry and verify that their proprty are in sync.

Any suggestion would be great.

Samuel Rondeau-Millaire
  • 1,100
  • 2
  • 13
  • 24
KD.
  • 2,015
  • 3
  • 28
  • 59
  • 1
    It's not clear why you added unit-testing tag to this question, it looks like a system test or integration test. – Andrey Adamovich Jun 24 '13 at 09:58
  • Is "Daily Sync" a custom written application or is it some sort of packaged replication product that usually comes with database engines? – Andrey Adamovich Jun 24 '13 at 10:03
  • 1
    Also, I guess using random entries each day will give you ... well... random results. – Andrey Adamovich Jun 24 '13 at 10:05
  • Yes the random test can have issues. and Yes its a custom code which sync the two system. It uses transaction while copying the data in bulk. In system B before writing each entry it checks if the data is same or different and only writes when the data is different. – KD. Jun 25 '13 at 02:05

1 Answers1

3

What you need is known as Risk Management, in Software Testing it is called Software Risk Management.
It seems your question is not about "how to test" what you are about to test but how to describe what you do and why you do that (based on the question I assume you need this explanation for yourself too...).

Adding SRM to your Test Strategy should describe:

  • The risks of not fully testing all and every data in the mirrored system
  • A table scaling down SRM vs amount of data tested (ie probability of error if only n% of data tested versus -e.g.- 2n% tested), in other words saying -e.g.!- 5% of lost data/invalid data/data corrupption/etc if x% of data was tested with a k minute/hour execution time
  • Based on previous point, a break down of resources used for the different options (e.g. HW load% for n hours, manhours used is y, costs of HW/SW/HR use are z USD)
  • Probability -and cost- of errors/issues with automation code (ie data comparison goes wrong and results in false positive or false negative, giving an overhead to DBA, dev and/or testing)
  • What happens if SRM option taken (!!e.g.!! 10% of data tested giving 3% of data corruption/loss risk and 0.75% overhead risk -false positive/negative results-) results in actual failure, ie reference to Business Continuity and effects of data, integrity, etc loss

Everything else comes to your mind and you feel it applies to your *current issue* in your *current system* with your *actual preferences*.
Glorfindel
  • 21,988
  • 13
  • 81
  • 109