Thursday, April 22, 2010

Security Testing concept and checklist


Security Testing
Security testing is a process to determine that an information system protects data and maintains functionality as intended.
Security testing is the process that determines that confidential data stays confidential (i.e. it is not exposed to individuals/ entities for which it is not meant) and users can perform only those tasks that they are authorized to perform (e.g. a user should not be able to deny the functionality of the web site to other users, a user should not be able to change the functionality of the web application in an unintended way etc.).
The purpose of the security test is to discover the vulnerabilities of the web application so that the developers can then remove these vulnerabilities from the application and make the web application and data safe from unauthorized actions.
Why Security Testing Required:
· Direct financial loss
· Loss of Reputation
Some Terms related to Security Testing
Vulnerability: This is a weakness in the web application. The cause of such a “weakness” can be bugs in the application, an injection (SQL/ script code) or the presence of viruses
URL manipulation: Some web applications communicate additional information between the client (browser) and the server in the URL. Changing some information in the URL may sometimes lead to unintended behavior by the server
SQL injection: This is the process of inserting SQL statements through the web application user interface into some query that is then executed by the server
XSS (Cross Site Scripting): When a user inserts HTML/ client-side script in the user interface of a web application and this insertion is visible to other users, it is called XSS
Spoofing: The creation of hoax look-alike websites or emails is called spoofing
For Security testing tester require skills like
  • Knowledge of HTTP protocol
  • How client and server request communicate with each other using HTTP
  • Basics of sql injection and XSS
For security testing tester should careful about
  • Configuration of the application or the server
  • Services running on the server
  • Existing user or customer data hosted by the application
  • Security testing should not perform on production environment
Checklist for Security testing
  • Password cracking
  • SQL Injection
  • URL Manipulation
  • XSS cross site scripting
  • Site functionality should be examined to ensure that access to sensitive data and administrative functions is protected appropriately. This applies to OS and server level functions, as well as application level.
  • Only services necessary for the business process should be running on web-facing servers (the more different systems, the greater the likelihood of serious flaw
  • Network traffic should be monitored to check for plain text transmission of user names and passwords (whether related to site users or to back office functions such as databases)

Wednesday, April 21, 2010

Data Migration Testing concept and checklist for testing

Data Migration Testing

Data migration is a process which involves the migration of data from an existing database to a new database. Whenever an organization decides to upgrade or change its database, it will need to transport the existing data to the new database.

The scope of data migration is much more than what the term suggests. Data migration activity typically will include everything that is required with respect to data to ensure that the new database is up and running without any defects and it also contains all the legacy data ( data that is present in the existing database) , and the data has been migrated to correct table(s) and column(s).

Consequently it involves more activities than only migration of existing data as the name suggests.

In a typical scenario it can include following activities:-

A. Migration of existing data to the new database.

B. The new database can have some 'Master Tables'. And Master tables need to be populated with data first to account for various referential constraints. In such cases data migration includes the activity of setting up (master) data in master tables.

C. The new database can have some tables or attributes which are not present in the existing database. Thus a completely new set of data will be setup in these tables.

While data migration is different, first understand the data migration process. Data migration is the process of shifting the whole production data from one database to other new database. This process might be done by using data migration tool which is developed as per the data migration requirements.

During this data migration process there may be possibility of data missing or data corruption. So after the data migration process one has to test whether the whole data is migrated successfully or not, whether something is missing or gets currepted during migration.

So data migration testing is to compare migrated data with original data to find out any discrepancies.

When we are speaking database migration testing. We can say ETL testing. Database migration is extracting the database from source and loads the data to target database.

Two types of Loading:

1. Direct Loading.

2. Incremental Loading.

Direct Loading:

The direct loading is nothing copy the data from source to target. The number of rows should be equal source and target.

Incremental Loading:

The Incremental loading, when loading the data from source to target, applying some transformations. Cleaning the data or load the data with specific conditions.

Challenge is two different databases have their own structures so just simple table/record import export function will not work. We need a tool (say ETL) in between source database and destination database where we will write the transformation logic, done by the Dev team. Testing team will validate that all those business rules in ETL are actually working in migration testing

Types of Migration

Migration of data from one database to another can be further classified into various subsets.

a. Direct Migration from the source database to the target:

In this type of migration the data elements that are present in the source database is directly transferred into the target database

b. Migration after performing certain transformations on the source data:

This migration requires some transformation of the source data before it is migrated to the new database.

For e.g., a field ‘Priority’ in the source database may allow only one out of the three values High, Medium and Low. But in the target database the same field allows one out of the three values 1, 2 and 3. Thus the a High value in the source database will be transformed to a value 1 and will then be migrated to the target database.

Different types of migrations are listed below. These are the migrations which were encountered during testing of data migration project(s). There could be some more types of migration and presently are not part of the below list.

1. Change in datatype.

a. Data in the source table may be present as a character, but in the target table the mapped column is an integer.

2. Concatenation of two or more columns.

3. Mathematical transformations (e.g. summing up of fields etc)

4. Migration of values depending on other fields/tables present in the source database.

c. Target Generated Data:

This is the data that is generated at the target database. These values will not be present the source database but will be generated each time an insertion or an update takes place on a table. These columns generally are the primary key of a table.

d. Reference at target system generated.

This type of migration deals with data that has to comply with referential integrity constraints. This data is generated at the new database but the data comes from the parent attribute. A reference key in the target database is usually encountered when a table in the source database is split up into two or more tables in the target.

e. Manual setup data in the target database.

Certain tables have to be populated before the migration takes place. These tables can be termed as ‘Master Tables’. These tables are the parent tables to the various referential constraints that are to be implemented in the child tables. The data for these tables may not come from the source database but will be setup manually in the target database.

Checklist for test Data Migration Testing

1. We can check for the table row count.

2. We have to check database integrity.

3. We have to check the referential integrity.

4. Whether the data are loaded in the target database correctly.

5. Check the constraints.

6. All the entities are transformed or not like tables, SPs, Views, functions etc

7. Check the functionality of your application with target database, it should work as it is supposed to work

Data Migration Testing Life Cycle

The following are the steps to be followed in the process of Data Migration Testing:-

1. Data Migration Requirement Analysis

2. Test Strategizing

3. Creation of POC

4. Test Planning

5. Design of Automated Test Scripts

6. Test Environment Setup

7. Test Execution

8. Result and Defect Analysis

Useful links:

http://www.datamigrationpro.com/data-migration-articles/2009/11/30/how-to-implement-an-effective-data-migration-testing-strateg.html

http://www.agiledata.org/essays/databaseTesting.html

Tuesday, April 20, 2010

Test checklist for Window Services


Checklist for Test Window Services
  • Check when your PC not in network
  • Check when your PC is log off
  • Check when automatically shutdown
  • Check when automatically restart
  • Check when power off condition
  • Service is automatically stopped by any of the reason
  • Window service pick the job on time
  • Compatibility with Operating system
  • For any schedule job if multiple recipient found and even next timeslot comes but yet not complete first schedule job
Cases for Email sender window service
  • If no recipient found
  • If many recipient found
  • Email address wrong
  • Email address blank
  • If attachment is attached
  • If attachment size is too long
  • If so many attachment is there
  • If port address is not mentioned
  • SMTP IF address differ or not configured
  • IP address differ
  • Mail server down

Test Checklist for Wireless Application

Checklist for test Wireless Application

1. Validating implementation: Ensuring that application does what it is supposed to do by checking functionality of it

2. Usability or GUI testing: Focus on external interface and relationship among screen of application

a. Is the navigation path appropriate for each particular function?

b. Does application minimize text entry- painful on wireless phone, or should it provide more selection menu?

c. Can screens of all supported device display the content without truncating it?

d. If you expect to deploy application on foreign devices, does it support international character set?

3. Network Performance testing: Verify that the application perform well in the hardest of condition, battery is low or passing through tunnel

4. Server side script testing

5. Navigation Checklist : application name, keep the user informed, readable text, repainting screens, soft buttons, screen navigation, portability

6. Network Checklist : Sending/receiving data, name resolution, sensitive data, error handling and interruptions

7. Other issues: Successful startup and exit, classes outside MIDP and CLDC specification, user manual

Monday, April 19, 2010

Bulk Insert Query useful for Test Data


Bulk insert Query
To bulk upload data from csv to sql tables, import csv file to sql table or load comma deliminated file into sql, use BULK INSERT query. This is very useful when you want to insert test data from csv files to sql.
Follow below steps.
  • Create database with TestDatabase
  • Create table with CSVTest using below query
  • Create csvtest.txt file in C:
  • If your database server is local then file keep in local C:
  • If your database server is remote then file keep in remote database server’s C:
  • Value of txt file should be in order of your table structure (refer example)
  • Run bulk insert query
  • Verify content of your table
--use current database
use TestDatabase
--create csvtest table with fields
GO
CREATE TABLE CSVTest
(ID INT,
FirstName VARCHAR(40),
LastName VARCHAR(40),
BirthDate SMALLDATETIME)
GO
-- create csvtest.txt file in c:\csvtest.txt with
1,James,Smith,19750101
2,Meggie,Smith,19790122
3,Robert,Smith,20071101
4,Alex,Smith,20040202
--bulk insert query from text file
BULK
INSERT dbo.CSVTest
FROM 'c:\test.txt'
WITH
(
FIELDTERMINATOR = ',',
ROWTERMINATOR = '\n'
)
GO
--Check the content of the table.
SELECT *
FROM CSVTest
GO