Most of the apps take the
input from the user thru UI, do some logic, store the data in a file or
database, finally show a success or failure message on the UI. Checking
the message alone is not good enough; what if the data was truncated or
wrongly formatted or wrongly stored or lost? This is why you need to
check the data in files and database. Testers can see the results of a test case on the UI or in a file or in database tables. Checking the text on UI is very simple as one can immediately see it in front of the eyes. But Checking the results in a file takes some more time and a few extra steps.
Let us take the file storage first. First of all, the tester must know the folder and filename in which the app stores the results. The file may be a flat file or a csv or a tsv or an XML file. Hence the tester must also know the format of the file. First, the tester must manually enter data thru UI and save the record and see how the file stores the data. Imagine the app stores the employee record like this (one record per one line): emp_code,emp_name,emp_dob,designation,salary,branch,emp_doj. This is a csv format. Here, we do not know the length of the line; it can vary based on the length of the name or other fields. But all I know is that if I give some data in the UI, the same must appear in the file, in the given order. Hence, to check whether the data is present in the file or not, we must know how to open a file, read the records from file, compare the data with expected results and then close the file. All tools provide a fiel interface thru file system object (VBScript) or file input stream (Java). Using these commands, one must read record after record, compare with expected results and close the file.
If the app stores data in XML file, it is a little bit easier. Because, every scripting language provides simple commands to check whether a node (<tag> </tag>) is present, how many child nodes are present and the data embedded within a specific tag. These commands use XML object to store the file data. Tools like HP QTP provide a very good UI also to view the whole XML structure like a tree and we need not even write code to check data in an XML file.
When it comes to checking records in a database, you need to know the tables and their structure. Soon after every add, edit or delete transaction thru the app UI, we must do a select query from the respective table, extract the data and compare whether the same is correct or not. The important point in writing the query is to narrow down the data that is very very specific to the test. Do not grab a lot of records that are not required for the test; for example, if I cancel a ticket with reservation number XB45890, I need to just select the record for that reservation number only; so that I get only the record I want to compare. Try to select records based on some unique key values, rather than a generic where clause.
When you use file or database checkpoints, make sure you close the file or database connection, soon after the checkpoint.
Let us take the file storage first. First of all, the tester must know the folder and filename in which the app stores the results. The file may be a flat file or a csv or a tsv or an XML file. Hence the tester must also know the format of the file. First, the tester must manually enter data thru UI and save the record and see how the file stores the data. Imagine the app stores the employee record like this (one record per one line): emp_code,emp_name,emp_dob,designation,salary,branch,emp_doj. This is a csv format. Here, we do not know the length of the line; it can vary based on the length of the name or other fields. But all I know is that if I give some data in the UI, the same must appear in the file, in the given order. Hence, to check whether the data is present in the file or not, we must know how to open a file, read the records from file, compare the data with expected results and then close the file. All tools provide a fiel interface thru file system object (VBScript) or file input stream (Java). Using these commands, one must read record after record, compare with expected results and close the file.
If the app stores data in XML file, it is a little bit easier. Because, every scripting language provides simple commands to check whether a node (<tag> </tag>) is present, how many child nodes are present and the data embedded within a specific tag. These commands use XML object to store the file data. Tools like HP QTP provide a very good UI also to view the whole XML structure like a tree and we need not even write code to check data in an XML file.
When it comes to checking records in a database, you need to know the tables and their structure. Soon after every add, edit or delete transaction thru the app UI, we must do a select query from the respective table, extract the data and compare whether the same is correct or not. The important point in writing the query is to narrow down the data that is very very specific to the test. Do not grab a lot of records that are not required for the test; for example, if I cancel a ticket with reservation number XB45890, I need to just select the record for that reservation number only; so that I get only the record I want to compare. Try to select records based on some unique key values, rather than a generic where clause.
When you use file or database checkpoints, make sure you close the file or database connection, soon after the checkpoint.
For free lessons on automation tools, visit us at http://www.openmentor.net.
