checkpoint maintenance
Hi, i'm standing in front of a conflict. i created a script that test an installation/uninstall in english.this script has checkpoints through all the way.now, there are other installation f...
Forum Discussion
As powerful as checkpoints are, this is one of the disadvantages of them in that, for many situations, they are effectively "hard coded" for the situation in which they were created. This is where a data-driven test scenario would work best where you have some sort of data source (CSV, Excel, etc) that contains the values to be compared to the actual on screen values and then call that data during the course of your tests. You could, then, have different data files for different language sets so that all you would have to do is replace one file with another and re-run your tests.
Roughly, what I would do, is have something like an EnglishCheckpoints.CSV, a JapaneseCheckPoints.CSV, etc. Each CSV file would contain two columns. The first column would be the component name whose property/value you are checking. The second column would be the value to be checked. Then, as you run through your code, you would call up the record from the CSV based upon the component and compare the value in the file then to the value on the screen.
Roughly, what I would do, is have something like an EnglishCheckpoints.CSV, a JapaneseCheckPoints.CSV, etc. Each CSV file would contain two columns. The first column would be the component name whose property/value you are checking. The second column would be the value to be checked. Then, as you run through your code, you would call up the record from the CSV based upon the component and compare the value in the file then to the value on the screen.
