Interview Questions On Data Base Testing:-

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 Integrity 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 referential 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

Ans :
Observing that operations, which are operated on front-end is effected on back-end or not.
The approach is as follows :
While adding a record the front-end check back-end that addition of record is effected or not.
So same for delete, update
Ex: Enter employee record in database the front-end and check if the record is added or not to the back-
end(manually).

Latest Testing Interview Questions and Answers.

1. What is acceptance testing?

A: Acceptance testing is black box testing that gives the client/customer/project manager the opportunity
to verify the system functionality and usability prior to the system being released to production. The
acceptance test is the responsibility of the client/customer or project manager, however, it is conducted
with the full support of the project team. The test team also works with the client/customer/project
manager to develop the acceptance criteria.

2. What is alpha testing?

A: Alpha testing is testing of an application when development is nearing completion. Minor design
changes can still be made as a result of alpha testing. Alpha testing is typically performed by a group that
is independent of the design team, but still within the company, e.g. in-house software test engineers, or
software QA engineers.

3. What is beta testing?

A: Beta testing is testing an application when development and testing are essentially completed and final
bugs and problems need to be found before the final release. Beta testing is typically performed by end-
users or others, not programmers, software engineers, or test engineers.

4. What is a Test/QA Team Lead?

A: The Test/QA Team Lead coordinates the testing activity, communicates testing status to management
and manages the test team.

5. What is a Test Configuration Manager?

A: Test Configuration Managers maintain test environments, scripts, software and test data. Depending on
the project, one person may wear more than one hat. For instance, Test Engineers may also wear the hat
of a Test Configuration Manager.

6. What is software testing methodology?

A: One software testing methodology is the use a three step process of...

1. Creating a test strategy;

2. Creating a test plan/design; and
3. Executing tests.

This methodology can be used and molded to your organization's needs. Rob Davis believes that using this
methodology is important in the development and ongoing maintenance of his clients' applications.

7. What is the general testing process?

A: The general testing process is the creation of a test strategy (which sometimes includes the creation of
test cases), creation of a test plan/design (which usually includes test cases and test procedures) and the
execution of tests.

8. How do you create a test plan/design?

A: Test scenarios and/or cases are prepared by reviewing functional requirements of the release and
preparing logical groups of functions that can be further broken into test procedures. Test procedures
define test conditions, data to be used for testing and expected results, including database updates, file
outputs, report results. Generally speaking...

- Test cases and scenarios are designed to represent both typical and unusual situations that may occur in
the

application.
- Test engineers define unit test requirements and unit test cases. Test engineers also execute unit test
cases.
- It is the test team that, with assistance of developers and clients, develops test cases and scenarios for
integration

and system testing.

- Test scenarios are executed through the use of test procedures or scripts.
- Test procedures or scripts define a series of steps necessary to perform one or more test scenarios.
- Test procedures or scripts include the specific data that will be used for testing the process or
transaction.
- Test procedures or scripts may cover multiple test scenarios.
-Test scripts are mapped back to the requirements and traceability matrices are used to ensure each test
is within scope.

9. How do you execute tests?

A: Execution of tests is completed by following the test documents in a methodical manner. As each test
procedure is performed, an entry is recorded in a test execution log to note the execution of the procedure
and whether or not the test procedure uncovered any defects. Checkpoint meetings are held throughout
the execution phase. Checkpoint meetings are held daily, if required, to address and discuss testing
issues, status and activities.

- The output from the execution of test procedures is known as test results. Test results are evaluated by
test engineers to determine whether the expected results have been obtained. All discrepancies/anomalies
are logged and discussed with the
software team lead, hardware test lead, programmers, software engineers and documented for further
investigation and resolution. Every company has a different process for logging and reporting bugs/defects
uncovered during testing.

- A pass/fail criteria is used to determine the severity of a problem, and results are recorded in a test
summary report.

The severity of a problem, found during system testing, is defined in accordance to the customer's risk
assessment and

recorded in their selected tracking tool.

- Proposed fixes are delivered to the testing environment, based on the severity of the problem. Fixes are
regression tested and flawless fixes are migrated to a new baseline. Following completion of the test,
members of the test team prepare a summary report. The summary report is reviewed by the Project
Manager, Software QA Manager and/or Test Team Lead.

10. How do you create a test strategy?

A: The test strategy is a formal description of how a software product will be tested. A test strategy is
developed for all levels of testing, as required. The test team analyzes the requirements, writes the test
strategy and reviews the plan with the project team. The test plan may include test cases, conditions, the
test environment, a list of related tasks, pass/fail criteria and risk assessment.

11. What is load testing?

A: Load testing simulates the expected usage of a software program, by simulating multiple users that
access the program's services concurrently. Load testing is most useful and most relevant for multi-user
systems, client/server models, including web servers.

For example, the load placed on the system is increased above normal usage patterns, in order to test the
system's response at peak loads.

12. What is the difference between stress testing and load testing?

A: Load testing generally stops short of stress testing.

During stress testing, the load is so great that the expected results are errors, though there is gray area
in between stress testing and load testing.

Load testing is a blanket term that is used in many different ways across the professional software testing
community.

The term, load testing, is often used synonymously with stress testing, performance testing, reliability
testing, and volume testing.

Testing: A Sample Test Plan:-

If you decide to use the ‘10 step process for developing a test plan’, I have provided a fairly
comprehensive description of the tasks and events involved. But, I thought that having an example of a
test plan created using the process may clarify some questions and better illustrate the result. Keep in
mind that this is a completely fictional project. Any resemblance to a real project is purely coincidental…

INTRODUCTION

This is the Master Test Plan for the Reassigned Sales Re-write project. This plan will address
only those items and elements that are related to the Reassigned Sales process, both
directly and indirectly affected elements will be addressed. The primary focus of this plan is
to ensure that the new Reassigned Sales application provides the same level of information
and detail as the current system while allowing for improvements and increases in data
acquisition and level of details available (granularity).
The project will have three levels of testing, Unit, System/Integration and Acceptance. The
details for each level are addressed in the approach section and will be further defined in the
level specific plans.
The estimated time line for this project is very aggressive (six (6) months), as such, any
delays in the development process or in the installation and verification of the third party
software could have significant effects on the test plan. The acceptance testing is expected to
take one (1) month from the date of application delivery from system test and is to be done
in parallel with the current application process.
TEST ITEMS

The following is a list, by version and release, of the items to be tested:

A. EXTOL EDI package, Version 3.0
If a new release is available prior to roll-out it will not be used until after installation. It
will be a separate upgrade/update project.
B. DNS PC EDI transaction package, Version 2.2
If a new release is available prior to roll-out it will not be used until after installation. It
will be a separate upgrade/update project.
C. Custom PC EDI transaction package (two distributors only).
D. New reassigned sales software, initial version to be Version 1.0
A detailed listing of programs, databases, screens and reports will be provided in the
system and detailed design documents.
E. Order Entry EDI interface software, Current version at time of pilot. Currently, version
4.1.
F. Reassigned Sales System requirements document, SST_RQMT.WPD version 4.1
G. Reassigned Sales System Design Document, SST_SYSD.WPD version 3.02
H. Reassigned Sales Detail Design Document, SST_DTLD.WPD version 3.04

SOFTWARE RISK ISSUES

There are several parts of the project that are not within the control of the Reassigned Sales
application but have direct impacts on the process and must be checked as well.
A. The local AS/400 based vendor supplied EDI software package. This package will be
providing all the reformatting support from the ANSI X12 EDI formats to the
internal AS/400 data base file formats.
B. The PC based software package installed at each distributor's location (both custom
written and vendor supplied) will be providing the formatting of the distributors data
into the correct EDI X12 formats.
C. Backup and Recovery of the EDI transmission files, local databases and restart of the
translation process, must be carefully checked.
D. The ability to restart the application in the middle of the process is a critical factor to
application reliability. This is especially true in the case of the transmission files as
once the data is pulled from the mail box it is no longer available there and must be
protected locally.
E. Database security and access must be defined and verified, especially for files shared
between the Order Entry application and the Reassigned Sales process. All basic
security will be provided through the AS/400 systems native security process.

FEATURES TO BE TESTED

The following is a list of the areas to be focused on during testing of the application.
A. New EDI data acquisition process.
B. Redesigned On-line screens.
C. Redesigned/Converted reports.
D. New Automated Archive process.
E. Interface to the Order Entry system and data bases.
F. Computation of Sales Activity by region for commissions.

FEATURES NOT TO BE TESTED

The following is a list of the areas that will not be specifically addressed. All testing in these
areas will be indirect as a result of other testing efforts.
A. Non-EDI Order Entry processes.
Only the EDI interface of the Order Entry application will be verified. Changes to the EDI
interface to support Reassigned Sales are not anticipated to have an impact on the
Order Processing application. Order Entry is a separate application sharing the data
interface only, orders will continue to process in the same manner.
B. Network Security and dial-in access.
Changes to include EDI transactions for reassigned sales will have no impact on the
security aspects of the network or the EXTOL/EDI interface.
C. Operational aspects of the EDI process.
Changes to include EDI transactions for reassigned sales will have no impact on the
operational aspects of the EXTOL/EDI interface.
D. PC based spreadsheet analysis applications using Reassigned Sales data.
These applications are completely under the control of the customer and are outside the
scope of this project. The necessary data base format information will be provided to
the customers to allow them to extract data. Testing of their applications is the
responsibility of the application maintainer/developer.
E. Business Analysis functions using Reassigned Sales data.
These applications are completely under the control of the management support team
and are outside the scope of this project. The necessary data base format
information will be provided to the support team to allow them to extract data.
Testing of their applications is the responsibility of the application
maintainer/developer.
F. Marketing/Forecasting processes using Reassigned Sales data.
These applications are completely under the control of marketing and are outside the scope
of this project. The necessary data base format information will be provided to marketing to
allow them to extract data. Testing of their applications is the responsibility of the application
maintainer/developer.

APPROACH

Testing Levels

The testing for the Reassigned Sales project will consist of Unit, System/Integration
(combined) and Acceptance test levels. It is hoped that there will be at least one full time
independent test person for system/integration testing. However, with the budget
constraints and time line established; most testing will be done by the test manager with the
development teams participation.
UNIT Testing will be done by the developer and will be approved by the development team
leader. Proof of unit testing (test case list, sample output, data printouts, defect information)
must be provided by the programmer to the team leader before unit testing will be accepted
and passed on to the test person. All unit test information will also be provided to the test
person.
SYSTEM/INTEGRATION Testing will be performed by the test manager and development
team leader with assistance from the individual developers as required. No specific test tools
are available for this project. Programs will enter into System/Integration test after all critical
defects have been corrected. A program may have up to two Major defects as long as they
do not impede testing of the program (I.E. there is a work around for the error).
ACCEPTANCE Testing will be performed by the actual end users with the assistance of the
test manager and development team leader. The acceptance test will be done in parallel with
the existing manual ZIP/FAX process for a period of one month after completion of the
System/Integration test process.
Programs will enter into Acceptance test after all critical and major defects have been
corrected. A program may have one major defect as long as it does not impede testing of the
program (I.E. there is a work around for the error). Prior to final completion of acceptance
testing all open critical and major defects MUST be corrected and verified by the Customer
test representative.
A limited number of distributors will participate in the initial acceptance test process. Once
acceptance test is complete, distributors will be added as their ability to generate the
required EDI data is verified and checked against their FAX/ZIP data. As such, some
distributors will be in actual production and some in parallel testing at the same time. This
will require careful coordination of the control tables for the production system to avoid
posting test data into the system.

Configuration Management/Change Control

Movement of programs from the development portion of the ‘RED’ system to the test
portion of the ‘RED’ system will be controlled through the existing Configuration
Management application process, ‘EXTRACT’. This will ensure that programs under
development and those in full test will have the same version controls and tracking of
changes. The same extract process will be used to migrate the programs from the
Development/Test ‘RED’ system to the production ‘BLUE’ system once all
testing has been completed according to published plans and guidelines.
All Unit and initial system testing will be performed on the Development AS/400 ‘RED’
system. Once the system has reached a reasonable level of stability, no critical or major
defects outstanding, initial pilot testing will be done on the production AS/400 ‘BLUE’
system. All testing done on the ‘BLUE’ system will be done in a parallel mode will all
controls set to prevent actual updating of the production files.
This will allow some early testing of the numbers received through the old ZIP/FAX process
and the higher level of detail received through the new EDI process. This will also help
identify potential problems with the comparison of the two sets of numbers.
All changes, enhancements and other modification requests to the system will be handled
through the published change control procedures. Any modifications to the standard
procedures are identified in the project plan change control section.

Test Tools

The only test tools to be used are the standard AS/400 provided utilities and commands.
A. The Program Development Manager (PDM) will be used as the source version
configuration management tool in conjunction with the in-house check-in/check-out
control utility. The check-in/out utility is part of each developers standard AS/400
access menu.
B. The initial prototypes for the new screens will be developed using the AS/400 Screen
Design Aid (SDA). The initial layout and general content of the screens will be shown
to the sales administration staff prior to proceeding with testing and development of
the screens.
C. All editing, compiling and debugging will be done using the Source Entry Utility (SEU).
D. Data acquisition will be from actual production files where available using the AS/400
data base copy command CPYF and it's various functions. Additional data will be
created and modified as needed using the Data File Utility (DFU). No changes will
ever be made to actual production files under any circumstances.
E. Initial data for EDI testing will be done using one or two beta sites and replicating the
data at the mailbox location or locally in the control files, to create high volume data
and to simulate multiple distributors sending in data.

Meetings

The test team will meet once every two weeks to evaluate progress to date and to identify
error trends and problems as early as possible. The test team leader will meet with
development and the project manager once every two weeks as well. These two meetings
will be scheduled on different weeks. Additional meetings can be called as required for
emergency situations.
Measures and Metrics
The following information will be collected by the Development team during the Unit testing
process. This information will be provided to the test team at program turnover as well as be
provided to the project team on a biweekly basis.
1. Defects by module and severity.
2. Defect Origin (Requirement, Design, Code)
3. Time spent on defect resolution by defect, for Critical & Major only. All Minor defects
can be totaled together.
The following information will be collected by the test team during all testing phases. This
information will be provided on a biweekly basis to the test manager and to the project
team.
1. Defects by module and severity.
2. Defect Origin (Requirement, Design, Code)
3. Time spent on defect investigation by defect, for Critical & Major only. All Minor
defects can be totaled together.
4. Number of times a program submitted to test team as ready for test.
5. Defects located at higher levels that should have been caught at lower levels of
testing.

ITEM PASS/FAIL CRITERIA

The test process will be completed once the initial set of distributors have successfully sent in
reassigned sales data for a period of one month and the new EDI data balances with the old
ZIP/FAX data received in parallel. When the sales administration staff is satisfied that the
data is correct the initial set of distributors will be set to active and all parallel stopped for
those accounts.
At this point the next set of distributors will begin the parallel process, if not already doing
so. Only the initial set of distributors must pass the data comparison test to complete the
testing, at that point the application is considered live. All additional activations will be on an
as ready basis. When a distributor is ready, and their data is verified, they will then also be
activated.

SUSPENSION CRITERIA AND RESUMPTION REQUIREMENTS

A. No Distributors are ready for testing at pilot initiation.

The pilot project will be delayed until at least three Distributors are ready to initiate the pilot
process. No additional elements will be added to the Reassigned Sales project during this
delay.
B. Unavailability of two EDI mail boxes.
In the event two production lines and mail box facilities cannot be obtained the current single
production line and mail box will continue to be used until a second line becomes available.
This will necessitate careful coordination between the Order Entry department and the
Reassigned Sales group.
C. Distributor PC EDI software delays.
In the event of a delay in the delivery or availability of the PC software package, the only
major delay will be in pilot testing. Unit, Integration and Systems testing can continue using
limited data until such time as the PC software is ready.
This will also add time to the lower levels of testing as full complete testing cannot be done
without reasonable amounts of data. The data can only be derived from actual transmissions
from the PC software package.

TEST DELIVERABLES

Acceptance test plan

 System/Integration test plan
 Unit test plans/turnover documentation
 Screen prototypes
 Report mock-ups
 Defect/Incident reports and summaries
 Test logs and turnover reports

REMAINING TEST TASKS

TASK Assigned To Status

Create TM, PM, Client

Acceptance
Test Plan
Create TM, PM, Dev.
System/Inte
gration Test
Plan
Define Unit TM, PM, Dev.
Test rules
and
Procedures
Define TM, Dev
Turnover
procedures
for each
level
Verify Dev, Client, TM
prototypes
of Screens
Verify Dev, Client, TM
prototypes
of Reports
ENVIRONMENTAL NEEDS

The following elements are required to support the overall testing effort at all levels within
the reassigned sales project:
A. Access to both the development and production AS/400 systems. For development,
data acquisition and testing.
B. A communications line to the EDI mailbox facility. This will have to be a shared line
with the Order Entry process as only one mailbox is in use. There will have to be a
coordinated effort to determine how often to poll the mailbox as the order entry
process requires that data be accessed every hour and the sales process really only
needs to be pulled once a day.
C. An installed and functional copy of the AS/400 based EDI vendor package.
D. At least one distributor with an installed copy of the PC based EDI vendor package for
sales data.
E. Access to the master control tables (data bases) for controlling the production/testing
environment on both production and development systems.
F. Access to the nightly backup/recovery process.

STAFFING AND TRAINING NEEDS

It is preferred that there will be at least one (1) full time tester assigned to the project for
the system/integration and acceptance testing phases of the project. This will require
assignment of a person part time at the beginning of the project to participate in reviews
etc... and approximately four months into the project they would be assigned full time. If a
separate test person is not available the project manager/test manager will assume this role.
In order to provide complete and proper testing the following areas need to be addressed in
terms of training.
A. The developers and tester(s) will need to be trained on the basic operations of the
EDI interface. Prior to final acceptance of the project the operations staff will also
require complete training on the EDI communications process.
B. The sales administration staff will require training on the new screens and reports.
C. At least one developer and operations staff member needs to be trained on the
installation and control of the PC based distributors EDI package. The distributors
personnel will also have to be trained on the PC based package and its operational
characteristics.