Testing data updates to data stores
I'm currently writing tests for a Data Registration system. In summary, a data provider will supply a daily update file that will be processed by the registration system and if they pass the validation checks, the registration system will update the data it stores for those records contained in the update file.
I've been given a list of 85 different update scenarios - that is 85 different ways the data can be updated in the database, which consists of a series of related tables. Having had a look at these scenarios, I don't think that it would be necessary to test all 85 scenarios. The system is however implemented on large scale and is a nationwide system. For confidentiality, I cannot reveal details about the system, so lets take an example of a Police motoring system. So lets say, for example, the system accepts a daily update file from Vehicle Insurance companies containing changes to their records for details of the cars and owners they cover. Lets say that their are 85 different forms of update they can send - So 85 different update scenarios. An example scenario may be a change of Address of owner. Another scenario may be Change of Address and car of owner. A third scenario may be a change of name of owner and license type of owner, etc... The daily update file may contain an update for a single record i.e a driver or thousands. From what I have seen, these update scenarios seem to be categorised - 20 scenarios related to updating owner details, 25 scenarios relating to adding new vehicle owner, etc....
So my question is how would I write tests for these update scenarios without having to write tests for all 85? Is it a simple case of choosing a subset of scenarios from each category and write test for those? So for example, In the 'update owner details' category, I could have one test that updates all the owners details using the assumption that if that works, then a test for updating the owners name only, will work.
The testing environment is manual.
Your input is appreciated.
In my experience update scenarios i think you can cover in minimum number of test cases covering all the fields and scenarios.
Most crucial part would be after update is it getting reflected properly in all the places, is something which you have to focus on.
So first list down the fields to be updated and places where its getting reflected and make sure you are verifying those scenarios.
Its my suggestion, if anyone else has any other please let know.
The best way to write tests (& have the max coverage) is to write tests in such a way, that all the scenarios are covered. The most important point here that you stated is - that the system contains a series of related tables.
There are 3 important points here, that you should cover.
Point 1: Cover all Scenarios but Simplify Test Management.
To keep it simple, group the scenarios (such as updating owner details, adding new vehicle owner... etc...) and create a "excel matrix" for each group.
Your 1 group would be 1 test case, although it would cover the complete matrix for the given group.
This way, you create less test cases, but cover everything.
Point 2: Understand the inter-relationships of the DB tables & find out how you can break them. Create additional scenarios, if there are limited or no validations on the application that would ensure the DB integrity.
This way, you also create negative cases, whereby internal relationships get exploited & unearthed.
Point 3: Although, you have not stated anything about external dependencies/relationships, in case if this data is being referenced / used by an external system (or other internal modules), then you may wan to do a check on the appropriate interfaces as well.
This will ensure, that no aspect of the application is being overlooked.
Of course, I am assuming that your test design already covers aspects of UI & other batch related aspects.
Hi i need test cases with examples plz send me