Friday, 4 July 2014

22:37 | by Dragan Mestrovik | Categories: | No comments
Well, here are some tips to create a good database test plan:
1. Database testing can get complex. It may be worth your while if you create a separate test plan specifically for database testing.
2. Look for database related requirements in your requirements documentation. You should specifically look for requirements related to data migration or database performance. A good source for eliciting database requirements is the database design documents.
3. You should plan for testing both the schema and the data.
4. Limit the scope of your database test. Your obvious focus should be on the important test items from a business point of view. For example, if your application is of a financial nature, data accuracy may be critical. If you application is a heavily used web application, the speed and concurrency of database transactions may be very important.
5. Your test environment should include a copy of the database. You may want to design your tests with a test database of small size. However, you should execute your tests on a test database of realistic size and complexity. Further, changes to the test database should be controlled.
6. The team members designing the database tests should be familiar with SQL and database tools specific to your database technology.
7. I find it productive to jot down the main points to cover in the test plan first. Then, I write the test plan. While writing it, if I remember any point that I would like to cover in the test plan, I just add it to my list. Once I cover all the points in the list, I review the test plan section by section. Then, I review the test plan as a whole and submit it for review to others. Others may come back with comments that I then address in the test plan.
8. It is useful to begin with the common sections of the test plan. However, the test plan should be totally customized for its readers and users. Include and exclude information as appropriate. For example, if your defect management process never changes from project to project, you may want to leave it out of the test plan. If you think that query coding standards are applicable to your project, you may want to include it in the test plan (either in the main plan or as an annexure).

Now, let us create a sample database test plan. Realize that it is only a sample. Do not use it as it is. Add or remove sections as appropriate to your project, company or client. Enter as much detail as you think valuable but no more.

For the purpose of our sample, we will choose a database supporting a POS (point of sale) application. We will call our database MyItemsPriceDatabase.

Introduction

This is the test plan for testing the MyItemsPriceDatabase. MyItemsPriceDatabase is used in our POS application to provide the current prices of the items. There are other databases used by our application e.g. inventory database but these other databases are out of scope of this test.

The purpose of this test plan is to:
1. Outline the overall test approach
2. Identify the activities required in our database test
3. Define deliverables

Scope

We have identified that the following items are critical to the success of the MyItemsPriceDatabase:
1. The accuracy of uploaded price information (for accuracy of financial calculations)
2. Its speed (in order to provide quick checkouts)
3. Small size (given the restricted local hard disk space on the POS workstation)

Due to limitation of time, we will not test the pricing reports run on the database. Further, since it is a single-user database, we will not test database security.

Test Approach

1. Price upload test
Price upload tests will focus on the accuracy with which the new prices are updated in the database. Tests will be designed to compare all prices in the incoming XML with the final prices stored in the database. Only the new prices should change in the database after the upload process. The tests will also measure the time per single price update and compare it with the last benchmark.

2. Speed test
After analyzing the data provided to us from the field, we have identified the following n queries that are used most of the time. We will run the queries individually (10 times each) and compare their mean execution times with the last benchmark. Further, we will also run all the queries concurrently (in sets of 2 and 3 (based on the maximum number of concurrent checkouts)) to find out any locking issues.

3. Size test
Using SQL queries, we will review the application queries and find out the following:
a. Items which are never used (e.g. tables, views, queries (stored procedures, in-line queries and dynamic queries))
b. Duplicate data in any table
c. Excessive field width in any table

Test Environment

The xyz tool will be used to design and execute all database tests. The tests will be executed on the local tester workstations (p no.s in all).

Test Activities and Schedule
1. Review requirements xx/xx/xxxx (start) and xx/xx/xxxx (end)
2. Develop test queries
3. Review test queries
4. Execute size test
5. Execute price upload test
6. Execute speed test
7. Report test results (daily)
8. Submit bug reports and re-test (as required)
9. Submit final test report

Responsibilities
1. Test lead: Responsible for creating this test plan, work assignment and review, review of test queries, review and compile test results and review bug reports
2. Tester: Responsible for reviewing requirements, developing and testing test queries, execute tests, prepare individual test results, submit bug reports and re-test

Deliverables

The testers will produce the following deliverables:
1. Test queries
2. Test results (describing the tests run, run time and pass/ fail for each test)
3. Bug reports

Risks

The risks to the successful implementation to this test plan and their mitigation is as under:
1.
2.
3.

Approval
       Name        Role        Signature        Date
1. ____________________________________________________________
2. ____________________________________________________________
3. ____________________________________________________________
22:36 | by Dragan Mestrovik | Categories: | No comments
Database migration testing is needed when you move data from the old database(s) to a new database. The old database is called the legacy database or the source database and the new database is called the target database or the destination database. Database migration may be done manually but it is more common to use an automated ETL (Extract-Transform-Load) process to move the data. In addition to mapping the old data structure to the new one, the ETL tool may incorporate certain business-rules to increase the quality of data moved to the target database.

Now, the question arises regarding the scope of your database migration testing. Here are the things that you may want to test.
1. All the live (not expired) entities e.g. customer records, order records are loaded into the target database. Each entity should be loaded just once i.e. there should not be a duplication of entities.
2. Every attribute (present in the source database) of every entity (present in the source database) is loaded into the target database.
3. All data related to a particular entity is loaded in each relevant table in the target database.
4. Each required business rule is implemented correctly in the ETL tool.
5. The data migration process performs reasonably fast and without any major bottleneck.

Next, let us see the challenges that you may face in database migration testing.
1. The data in the source database(s) changes during the test.
2. Some source data is corrupt.
3. The mappings between the tables/ fields of the source databases(s) and target database are changed by the database development/ migration team.
4. A part of the data is rejected by the target database.
5. Due to the slow database migration process or the large size of the source data, it takes a long time for the data to be migrated.

The test approach for database migration testing consists of the following activities:

I. Design the validation tests
In order to test database migration, you need to use SQL queries (created either by hand or using a tool e.g. a query creator). You need to create the validation queries to run against both the source as well as the target databases. Your validation queries should cover the scope defined by you. It is common to arrange the validation queries in a hierarchy e.g. you want to test if all the Orders records have migrated before you test for all OrderDetails records. Put logging statements within your queries for the purpose of effective analysis and bug reporting later.

II. Set up the test environment
The test environment should contain a copy of the source database, the ETL tool (if applicable) and a clean copy of the target database. You should isolate the test environment so that it does not change externally.

III. Run your validation tests
Depending on your test design, you need not wait for the database migration process to finish before you start your tests.

IV. Report the bugs
You should report the following data for each failed test:
    a. Name of the entity that failed the test
    b. Number of rows or columns that failed the test
    c. If applicable, the database error details (error number and error description)
    d. Validation query
    d. User account under which you run your validation test
    e. Date and time the test was run

Keep the tips below in mind to refine your test approach:

1. You should take a backup of the current copies of the source and target databases. This would help you in case you need to re-start your test. This would also help you in reproducing any bugs.
2. If some source data is corrupt (e.g. unreadable or incomplete), you should find out if the ETL tool takes any action on such data. If so, your validation tests should confirm these actions. The ETL tool should not simply accept the corrupt data as such.
3. If the mappings between the tables/ fields of the source and target databases are changed frequently, you should first test the stable mappings.
4. In order to find out the point of failure quickly, you should create modular validation tests. If your tests are modular, it may be possible for you to execute some of your tests before the data migration process finishes. Running some tests while the data migration process is still running would save you time.
5. If the database migration process is manual, you have to run your validation queries externally. However, if the process uses an ETL tool, you have the choice to integrate your validation queries within the ETL tool.

I hope that you are comfortable with the concept of database migration testing. (whether  data is migrated between binary files and an RDBMS or between RDBMSs (Oracle, SQL Server, Informix or Sybase)). According to you, what is the main problem faced while testing database migration? What is a good way to handle this problem?
22:14 | by Dragan Mestrovik | Categories: | No comments
Many (but not all) applications under test use one or more databases. The purposes of using a database include long-term storage of data in an accessible and organizedform. Many people have only a vague idea about database testing.

Firstly, we need to understand what is database testing? As you would know, a database has two main parts - the data structures (the schema) that store the data AND the data itself. Let us discuss them one by one. 


The data is stored in the database in tables. However, tables may not be the only objects in the database. A database may have other objects like views, stored procedures and functions. These other objects help the users access the data in required forms. The data itself is stored in the tables. Database testing involves finding out the answers to the following questions:

Questions related to database structure
1. Is the data organized well logically?
2. Does the database perform well?
3. Do the database objects like views, triggers, stored procedures, functions and jobs work correctly?
4. Does the database implement constraints to allow only correct data to be stored in it?
5. Is the data secure from unauthorized access?


Questions related to data
1. Is the data complete?
2. Is all data factually correct i.e. in sync with its source, for example the data entered by a user via the application UI?
3. Is there any unnecessary data present?


Now that we understand database testing, it is important to know about the 5 common challenges seen before or during database testing:

1. Large scope of testing
It is important to identify the test items in database testing. Otherwise, you may not have a clear understanding of what you would test and what you would not test. You could run out of time much before finishing the database test.
Once you have the list of test items, you should estimate the effort required to design the tests and execute the tests for each test item. Depending on their design and data size, some database tests may take a long time to execute. Look at the test estimates in light of the available time. If you do not have enough time, you should select only the important test items for your database test.

2. Incorrect/ scaled-down test databases
You may be given a copy of the development database to test. This database may only have little data (the data required to run the application and some sample data to show in the application UI). Testing the development or test or staging databases may not be sufficient. You should also be testing a copy of the production database.

3. Changes in database schema and data
This is a particularly nasty challenge. You may find that after you design a test (or even after you execute a test), the database structure (the schema) has been changed. This means that you should be aware of the changes made to the database during testing. Once the database structure changes, you should analyze the impact of the changes and modify any impacted tests.
Further, if your test database is being used by other users, you would not be sure about your test results. Therefore, you should ensure that the test database is used for testing purpose only.
You may also see this problem if you run multiple tests at the same time. You should run one test at a time at least for the performance tests. You do not want your database performing multiple tasks and under-reporting performance.

4. Messy testing
Database testing may get complex. You do not want to be executing tests partially or repeating tests unnecessarily. You should create a test plan and proceed accordingly while carefully noting your progress.

5. Lack of skills
The lack of the required skills may really slow things down. In order to perform database testing effectively, you should be comfortable with SQL queries and the required database management tools.

Next, let us discuss the approach for database testing. You should keep the scope of your test as well as the challenges in mind while designing your particular test design and test execution approach. Note the following 10 tips:

1. List all database-specific requirements. You should gather the requirements from all sources, particularly technical requirements. It is quite possible that some requirements are at a high level. Break-down those requirements into the small testable requirements.

2. Create test scenarios for each requirement as suggested below.

3. In order to check the logical database design, ensure that each entity in the application e.g. actors, system configuration are represented in the database. An application entity may be represented in one or tables in the database. The database should contain only those tables that are required to represent the application entities and no more.

4. In order to check the database performance, you may focus on its throughput and response times. For example, if the database is supposed to insert 1000 customer records per minute, you may design a query that inserts 1000 customer records and print/ store the time taken to do so. If the database is supposed to execute a stored procedure in under 5 seconds, you may design a query to execute the stored procedure with sample test data multiple times and note each time.

5. If you wish to test the database objects e.g. stored procedures, you should remember that a stored procedure may be thought of as a simple program that (optionally) accepts certain input(s) and produces some output. You should design test data to exercise the stored procedure in interesting ways and predict the output of the stored procedure for every test data set.

6. In order to check database constraints, you should design invalid test data sets and then try to insert/ update them in the database. An example of an invalid data set is an order for a customer that does not exist. Another example is a customer test data set with an invalid ZIP code.

7. In order to check the database security, you should design tests that mimic unauthorized access. For example, log in to the database as a user with restricted access and check if you can view/ modify/ delete restricted database objects or view or view and update restricted data. It is important to backup your database before executing any database security tests. Otherwise, you may render your database unusable.
You should also check to see that any confidential data in the database e.g. credit card numbers is either encrypted or obfuscated (masked).

8. In order to test data integrity, you should design valid test data sets for each application entity. Insert/ update a valid test data set (for example, a customer) and check that the data has been stored in the correct table(s) in correct columns. Each data in the test data set should have been inserted/ updated in the database. Further, the test data set should be inserted only once and there should not be any other change in the other data.

9. Since your test design would require creating SQL queries, try to keep your queries as simple as possible to prevent defects in them. It is a good idea for someone other than the author to review the queries. You should also dynamically test each query. One way to test your query is to modify it so that it just shows the resultset and does not perform the actual operation e.g. insert, delete. Another way to test your query is to run it for a couple of iteration s and verify the results.

10. If you are going to have a large number of tests, you should pay special attention to organizing them. You should also consider at least partial automation of frequently run tests.

Now you should know what database testing is all about, the problems that you are likely to face while doing database testing and how to design a good database test approach for the scope decided by you.
22:11 | by Dragan Mestrovik | Categories: , | No comments
TestComplete is one of the best automation tool available in the market. With the increase in demand and changes in technology, this tools has made its significant place. And so we see there are lots of requirements coming up for automators with TestComplete skill set.  This post contains some commonly asked question on TestComplete at different multi-national organizations. We hope this will definitely help you prepare for the same.
Please note, some of the questions here are using VBScript as scripting language in TestComplete.
1. A general question could be like – What is TestComplete, how it works? or What do you know about TestComplete.
2. Explain name mapping concept in TestComplete.
3. Which version of TestComplete you have used ?
4. Have you worked on QTP also?If yes,what are the advantage of Testcomplete over QTP.
5. Use of USEUNIT method in TestComplete.
6. How descriptive programming can be done in TestComplete?
7. We have an object on a webpage say button,its hierarchy is getting change every-time you open that webpage.Apart from descriptive programming is there any way that we can identify that object on webpage or not?If yes then how.
8. Elaborate Object Identification Mechanism in TestComplete.
9. Difference between Find and FindAll method.
10. If any unexpected windows pop up during your script in TestComplete,how can you handle that?
11. What is Distributed testing and how it can be achieve using TestComplete.
12. Regular expression TestComplete.
13. Scripting languages that can be used in testComplete.
14. What is the purpose of TestedApps in TestComplete.
15. How can we call any application that has been added to TestedApps  in your scripts.
16. Different ways of capturing objects in TestComplete.
17. Is it possible to perform record and play  mechanism in TestComplete or not.
18. Browsers supported by TestComplete till date.
19. Regular expression in TestComplete.
20. Syntax for highlighting objects on web page.
21. Steps for calling functions located in some other file to any other file.
Hope, these questions are helpful to you. 
Happy Learning!!!

Tuesday, 24 June 2014

22:30 | by Dragan Mestrovik | Categories: , , | No comments
Have you done any Backend Testing  last project?
 
Yes. I have done backend testing. When I was
working in my last finance project, this was my
typical scenario of backend testing:
I was working on Reports. It was the scenario of testing one application used in the bank, where a customer comes to a bank’s front desk, the bank teller is requested to open a
Checking Account. The associate then asks for the personal information about the customer, which, are the primary data, such as: First Name, Last Name, Date of
Birth, Address and Social Security Number. The associate then puts these primary
data of that particular customer into the computer, which then afterwards
batch-processed (normally happens in the middle of the
night).
 Now, after the batch
process, the information of that customer goes into the central database in the
XML format. The data now from the database goes to ETL
(Extract-Transform-Load). (ETL is a tool
made by two companies ‘AbInitio’ and ‘Informatica’)
 ETL now processes the job to create a file
(output file) to produce the report. The file is now displayed in the GUI Front
End report with the help of Business Object (or Crystal Reports. These are tools that display
data in GUI format). In the GUI Front End report, let us say, if for August,
the deposit of that person was displayed as $ 2056.00. Then my job was to
validate whether this $2056 is correct or not. I validated this data by writing
SQL queries directly to the database. The data pulled from my SQL query should
match to the data in the GUI front end. In other words, my SQL query should also
display $900. If it matches, it is well and good. If it doesn’t, then it’s a
bug. This is how I have done my Back End Testing.
22:20 | by Dragan Mestrovik | Categories: , , | No comments
Database Testing Interview Questions

1. What we normally check for in the Database Testing?

In DB testing we need to check for,

1. The field size validation

2. Check constraints.

3. Indexes are done or not (for performance related issues)

4. Stored procedures

5. The field size defined in the application is matching with that in the db.

2. What is Database testing?

Data bas testing basically include the following.

1)Data validity testing.

2)Data Integritity testing

3)Performance related to data base.

4)Testing of Procedure,triggers and functions.

for doing data validity testing you should be good in SQL queries

For data integrity testing you should know about referintial integrity and different constraint.

For performance related things you should have idea about the table structure and design.

for testing Procedure triggers and functions you should be able to understand the same.

3. How to Test database in Manually? Explain with an example

Observing that opertaions, which are operated on front-end is effected on back-end or not.

The approach is as follows :

While adding a record thr' front-end check back-end that addition of record is effected or not. So same for delete,

update,...... Ex:Enter employee record in database thr' front-end and check if the record is added or not to the back-
end(manually).

4. What is data driven test?

An1:

Data driven test is used to test the multinumbers of data in a data-table, using this we can easy to replace the paramerers

in the same time from deferent locations.

e.g: using .xsl sheets.

An2:

Re-execution of our test with different input values is called Re-testing. In validate our Project calculations, test engineer

follows retesting manner through automation tool.Re-teting is also called DataDriven Test.There are 4 types of datadriven

tests.

1) Dynamic Input submissiion ( key driven test) : Sometines a test engineer conducts retesting with different input values

to validate the calculation through dynamic submission.For this input submission, test engineer use this function in TSL

scriipt-- create_input_dialog ("label");

2) Data Driven Files Through FLAT FILES ( .txt,.doc) : Sometimes testengineer conducts re-testing depends on flat file

contents. He collect these files from Old Version databases or from customer side.

3)Data Driven Tests From FRONTEND GREAVES : Some times a test engineer create automation scripts depends on

frontend objects values such as (a) list (b) menu (c) table (d) data window (5) ocx etc.,

4)Data Driven Tests From EXCEL SHEET : sometimes a testengineer follows this type of data driven test to execute their

script for multiple inputs. These multiple inputs consists in excel sheet columns. We have to collect this testdata from

backend tables .

5. How to check a trigger is fired or not, while doing database testing?

It can be verified by querying the common audit log where we can able to see the triggers fired.

6. How to Test Database Procedures and Triggers?

Before testing Data Base Procedures and Triggers, Tester should know that what is the Input and out put of the

procedures/Triggers, Then execute Procedures and Triggers, if you get answer that Test Case will be pass other

wise fail.

These requirements should get from DEVELOPER

7. Is a "A fast database retrieval rate" a testable requirement?

No. I do not think so. Since the requirement seems to be ambiguous. The SRS should clearly mention the performance or

transaction requirements i.e. It should say like 'A DB retrival rate of 5 micro sec'.

8. How to test a DTS package created for data insert update and delete? What should be considered in the above

case while testing it?What conditions are to be checked if the data is inserted, updated or deleted using a text

files?

Data Integrity checks should be performed. IF the database schema is 3rd normal form, then that should be maintained.

Check to see if any of the constraints have thrown an error. The most important command will have to be the DELETE

command. That is where things can go really wrong.

Most of all, maintain a backup of the previous database.

9.How to test a SQL Query in Winrunner? without using DataBase CheckPoints?

By writing scripting procedure in the TCL we can connect to the database and we can test data base and queries.

The exact proccess should be:

1)connect to the database

db_connect("query1",DRIVER={drivername};SERVER=server_name;UID=uidname;PWD=password;DBQ=database_nam

e ");

2)Execute the query

db_excecute_query("query1","write query u want to execute");

-Condition to be mentioned-

3)disconnect the connection

db_disconnect("query");

10. How do you test whether a database in updated when information is entered in the front end?

It depend on your application interface.. 1. If your application provides view functionality for the entered data, then you can

verify that from front end only. Most of the time Black box test engineers verify the functionality in this way. 2. If your

application has only data entry from front end and there is no view from front end, then you have to go to Database and

run relevent SQL query. 3. You can also use database checkpoint function in WinRunner.

11. How do you test whether the database is updated as and when an information are added in the front end?Give

me an example?

It depends on what level of testing you are doing.When you want to save something from front end obviously, it has to

store somewhere in the database

You will need to find out the relevant tables involved in saving the records.

Data Mapping from front end to the tables.Then enter the data from front end and save.

Go to database, fire queries to get the same date from the back end.

12. What steps does a tester take in testing Stored Procedures?

First the tester should to go through the requirement, as to why the particular stored procedure is written for.

Then check whether all the required indexes, joins, updates, deletions are correct comparing with the tables mentions in

the Stored Procedure. And also he has to ensure whether the Stored Procedure follows the standard format like

comments, updated by, etc.

Then check the procedure calling name, calling parameters, and expected reponses for different sets of input parameters.

Then run the procedure yourself with database client programs like TOAD, or mysql, or Query Analyzer

Rerun the procedure with different parameters, and check results against expected values.

Finally, automate the tests with WinRunner.

13. What are the different stages involved in Database Testing

verify field level data in the database with respect to frontend transactions

verify the constraint (primary key,forien key ....)

verify the performance of the procedures

verify the triggrs (execution of triggers)

verify the transactions (begin,commit,rollback)

14. How to use sql queries in WinRunner/QTP

in QTP

using output databse check point and database check point ,

select SQL manual queries option

and enter the "select" queris to retrive data in the database and compare the expected and actual

15. what is database testing and what we test in database testing?

An1:

Database testing is all about testing joins, views, inports and exports , testing the procedures, checking locks, indexing

etc. Its not about testing the data in the database.

Usually database testing is performed by DBA.

An2:

Database testing involves some in depth knowledge of the given application and requires more defined plan of approach

to test the data.

Key issues include:

1) Data Integrity

2) Data Validity

3) Data Manipulation and updates

Tester must be aware of the database design concepts and implementation rules.

An3:

Data bas testing basically include the following.

1)Data validity testing.

2)Data Integritity testing

3)Performance related to data base.

4)Testing of Procedure,triggers and functions.

for doing data validity testing you should be good in SQL queries

For data integrity testing you should know about referintial integrity and different constraint.

For performance related things you should have idea about the table structure and design.

for testing Procedure triggers and functions you should be able to understand the same.

16. What SQL statements have you used in Database Testing?

The most important statement for database testing is the SELECT statement, which returns data rows from one or

multiple tables that satisfies a given set of criteria.

You may need to use other DML (Data Manipulation Language) statements like INSERT, UPDATE and DELTE to manage

your test data.

You may also need to use DDL (Data Definition Language) statements like CREATE TABLE, ALTER TABLE, and DROP

TABLE to manage your test tables.

You may also need to some other commands to view table structures, column definitions, indexes, constraints and store

procedures.

17. How to test data loading in Data base testing?

You have to do the following things while you are involving in Data Load testing.

1. You have know about source data (table(s), columns, datatypes and Contraints)

2. You have to know about Target data (table(s), columns, datatypes and Contraints)

3. You have to check the compatibility of Source and Target.

4. You have to Open corresponding DTS package in SQL Enterprise Manager and run the DTS package (If you are using

SQL Server).

5. Then you should compare the column's data of Source and Target.

6. You have to check the number to rows of Source and Target.

7. Then you have to update the data in Source and see the change is reflecting in Target or not.

8. You have to check about junk character and NULLs.

18. What is way of writing testcases for database testing?

An1:

You have to do the following for writing the database testcases.

1. First of all you have to understand the functional requirement of the application throughly.

2. Then you have to find out the back end tables used, joined used between the tables, cursors used (if any), tiggers

used(if any), stored procedures used (if any), input parmeter used and output parameters used for developing that

requirement.

3. After knowing all these things you have to write the testcase with different input values for checking all the paths of SP.

One thing writing testcases for backend testing not like functinal testing. You have to use white box testing techniques.

An2:

To write testcase for database its just like functional testing.

1.Objective:Write the objective that you would like to test. eg: To check the shipment that i load thru xml is getting inserted

for perticular customer.

2.Write the method of input or action that you do. eg:Load an xml with all data which can be added to a customer.

3.Expected :Input should be viewd in database. eg: The shipment should be loaded sucessfully for that customer,also it

should be seen in application.4.You can write ssuch type of testcases for any functionality like update,delete etc.

An3:

At first we need to go through the documents provided.

Need to know what tables, stored procedures are mentioned in the doc.

Then test the functionality of the application.

Simultaneously, start writing the DB testcases.. with the queries you have used at the backend while testing, the tables

and stored procedures you have used in order to get the desired results. Trigers that were fired. Based on the stored

procedure we can know the functionality for a specific peice of the application. So that we can write queries related to that.

From that we make DB testcases also.

19;What is Database testing?

An1:

here database testing means test engineer should test the data integrity, data accessing,query

retriving,modifications,updation and deletion etc

An2:

Database tests are supported via ODBC using the following functions:

SQLOpen, SQLClose, SQLError, SQLRetrieve, SQLRetrieveToFile, SQLExecQuery, SQLGetSchema and SQLRequest.

You can carry out cursor type operations by incrementing arrays of returned datasets.

All SQL queries are supplied as a string. You can execute stored procedures for instance on SQL Server you could use

“Exec MyStoredProcedure” and as long as that stored procedure is registered on the SQL Server database then it should

execute however you cannot interact as much as you may like by supplying say in/out variables, etc but for most

instances it will cover your database test requirements

An3:

Data bas testing basically include the following.

1)Data validity testing.

2)Data Integritity testing

3)Performance related to data base.

4)Testing of Procedure,triggers and functions.

for doing data validity testing you should be good in SQL queries

For data integrity testing you should know about referintial integrity and different constraint.

For performance related things you should have idea about the table structure and design.

for testing Procedure triggers and functions you should be able to understand the same.

An4:

Data base testing generally deals with the follwoing:

a)Checking the integrity of UI data with Database Data

b)Checking whether any junk data is displaying in UI other than that stored in Database

c)Checking execution of stored procedures with the input values taken from the database tables

d)Checking the Data Migration .

e)Execution of jobs if any

20. What we normally check for in the Database Testing?

An1:

In DB testing we need to check for,

1. The field size validation

2. Check constraints.

3. Indexes are done or not (for performance related issues)

4. Stored procedures

5. The field size defined in the application is matching with that in the db.

An2:

Database testing involves some indepth knowledge of the given application and requires more defined plan of approach

to test the data. Key issues include :

1) data Integrity

2) data validity

3) data manipulation and updates.


Tester must be aware of the database design concepts and implementation rules