TRAINING REPORTOF

1 YEAR CO-OPT INDUSTRIAL TRAINING, UNDERTAKEN

AT

“INFORMATICA BUSINESS SOLUTIONS PVT. LTD.”

IN

“MDM (Master Data Management)”

ON

“PRODUCT TESTING AND AUTOMATION”

SUBMITTED IN PARTIAL FULFILLMENT OF THE DEGREE

OF

BE (CSE)

Under the Guidance of: Submitted By:Name: Mr Gopi Namani Name: Vishal SharmaDesignation: Manager, University ID No.:B110010387Department: MDM QA team

Chitkara University, Baddi, India

ACKNOWLEDGEMENT

I take this opportunity to express our gratitude and respect to all those who have helped me

throughout my working period on the real time company environment. Doing internship in a

product based company help us a lot to understand the new technology and how to grow in a

corporate world. Our special thanks is to our mentor Mr. Gopi Namani (Manager,MDM-QA),

who helps us a lot to show us the right path how to work in a company.

I owe my regards to the entire faculty of the department of Computer Science at Chitkara

University, Baddi from where we learnt the basics of Computer Science and we express our

sincere thanks to all our fellow course mates who supported us in the project through various

informal discussions which were very valuable to the successful completion of the project.

Vishal Sharma

i

DECLARATION

I hereby declare that the project work titled, “Software Testing and Automation MDM QA

team” submitted as part of Bachelor’s degree in COMPUTER SCIENCE & ENGG at

Chitkara University, H.P., is an authentic record of our own work carried out at Informatica

Business Solutions Pvt. Ltd. Bangalore as part of the 1 year Co-opt industrial training under

the supervision of Mr. Gopi Namani Manager MDM QA team.

Place: Bangalore Verified by:

Mr. Gopi Namani

Manager MDM QA team

Date: 27-05-2015

Name: Vishal Sharma

ii

COMPANY’S PROFILE

Informatica Corporation is a software development company founded in 1993. It is headquartered in Redwood City, California. It was founded by Diaz Nesamoney and Gaurav Dhillon. Sohaib Abbasi is the company's chairman and CEO.

Informatica’ s product is a portfolio focused on Data Integration: ETL, Information Lifecycle

Management, B2B Data Exchange, Cloud Data Integration, Complex Event Processing, Data

Masking, Data Quality, Data Replication, Data Virtualization, Master Data Management,

Ultra Messaging; currently at version 9.6 These components form a toolset for establishing

and maintaining enterprise-wide data warehouses. It has a customer base of over 5,000

companies.

In 2006, Informatica launched its Informatica Cloud business.

In 2010, the Informatica Marketplace was launched offering a data integration eco-system for

Partners, Customers, Developers and Informatica to share and leverage data integration

solutions. As of Sept 2014, it features over 1,300 pre-built mappings, templates, connectors

and add-ons for Informatica data integration and cloud data integration products.

On April 7, 2015, Permira and Canada Pension Plan Investment Board announced that a

company controlled by the Permira funds and CPPIB has signed a definitive agreement to

acquire Informatica for approximately US$5.3 billion.

iii

CONTENTS OF THE REPORTS

S. No Contents Page no.

i Acknowledgment iii Declaration iiiii Company’s profile iii

1 Master data management 1 2 Screenshots-MDM console 14

3 Testing 174 Manual Testing 225 Automation Testing 226 Tools used for testing 307 Snapshot-junit 328 IBM-RFT 339 Snapshot-RFT 341011121314

Continuous integration (CI)JenkinsSnapshot-JenkinsConclusionReference

3536384041

iv

WHAT IS MASTER DATA MANAGEMENT?

Master data management (MDM) is a methodology that identifies the most critical

information within an organization—and creates a single source of its truth to power business

processes.

MDM involves a number of technology solutions, including data integration, data quality,

and business process management (BPM). It delivers:

A single view of the data—creating a single, authoritative view of business-critical data from

disparate, duplicate, and conflicting information lets you see, for instance, that Rob Barnes

and Robert Barnes are the same person.

A 360-degree view of the relationships—Business rules let you identify the relationships

among the data, so you can combine data showing Robert Barnes owns a Razor scooter with

data showing he bought it at a Target store.

A complete view of all interactions—integrating the transactions and social interactions that

have occurred with that product, customer, channel partner, or other data element gives you a

complete view of that customer.

Marketers that say they could generate more revenue if they had better customer information

1

Your business runs many applications that store data—financial systems, marketing systems, customer service systems, and so on. Each application has built its own version of data “truth.” But which one is right? Not knowing can cost your organization significantly.

You know you’re in trouble when business processes start breaking down. You don’t know what products your customers have bought. You don’t know which products are selling well, or through which channels. You can’t get important compliance documents completed on time. You can’t get marketing campaigns out the door, and when you finally do, ROI suffers

The amount that the median Fortune 1000 company could boost revenue annually by increasing data usability 10%.

WHAT TO LOOK FOR?

Not all MDM solutions are created equal. When considering options, look for these features:

Flexibility—MDM is a journey. Although your business may first buy a product for one type

of data integrity problem, you should be able to use that solution to solve additional ones.

Built for data variability—likewise, it needs to handle multiple data types: customer records

as well as products, locations, accounts, and all related elements.

Designed for complexity—not understanding relationships can cost your company money.

You should know if two people belong to the same household or if a customer owns more

than one of your products.

Scalability from small to big projects—Many MDM problems are exceedingly complex. But

you don’t want to take a year for the initiative to get off the ground. You want the ability to

break down a data problem into smaller components.

Configurable—An MDM system shouldn’t require coding, which comes with testing and

maintenance headaches.

2

The customer retention rate of best-in-class companies who have established a consistent view of customers across systems compared to laggards.

WHY INFORMATICA?

Informatica Master Data Management is the only MDM solution that is both easy to deploy and flexible enough to solve your unique business challenges.

Agility—our solution can be deployed rapidly and easily, and includes the full assortment of data integrity, data quality, and BPM capabilities required to successfully complete any MDM project.

Business user-focused—we deliver value directly to your business users by immediately improving business processes and helping them discover relationships in the data that gives them powerful insights.

Focused on customer success—A dedicated group within Informatica’ s MDM division, our customer success team was created with the sole purpose of ensuring customer satisfaction. As a result, Informatica has been named number one for customer loyalty nine years in a row by independent research firm TNS.

Informatica has been #1 in customer loyalty for nine years running.

3

Key Features

Self-contained capabilities : - Get a complete solution, with data integration, data quality, and business-process management capabilities embedded in the software.

Intelligence Search : - Rapidly retrieve any master data information using free-form text.

MDM-aware Application : - Create MDM-aware applications using composite objects, services, and an application development kit.

360-degree Overview : - Uncover the complete, 360-degree view of any business entity, complete with rich images, hierarchies, and social information.

Intelligent Security : - Secure business critical data with dynamic data masking to ensure that only the right people gain access to data.

Data Control : - Seamlessly adds advanced master data components to CRM, ERP, and other enterprise applications.

The Truth about Master Data

Master data is the DNA of your company. It’s the mission-critical data that describes your core business entities – including customer, supplier, material, financial account, and other fundamental domains that drive business processes and decisions. It can also be generated and consumed anywhere – by internal users and systems, by business partners, or by external data providers such as data pools, vendors, and Dunn & Bradstreet. This makes maintaining a single view of master data across the enterprise quite a challenge.

4

The two directions of MDM

Every organization faces two problems when it looks at its current data issues:

1. How to clean up the existing mess

2. How to put in place the processes to manage master data going forward.

These lead to two clear, but related, directions for MDM. The first is the look-back challenge of cleaning up the data pollution that currently exists. This is about uplifting the quality of data to ensure that the look-forward strategy is working from a more stable base and to address the immediate concerns of the business with regards to data policy. The second, and most important, is the forward looking approach which modifies business processes and user input of information to ensure that the quality is increased and organizational policies enforced. This approach looks to ensure that the data in the company never degrades again to its current level and will, over time, lift the quality of current information.

Informatica Master Data Management Delivers a Single, Trusted View.

The Informatica® master data management product family empowers companies to improve operations with business-user access to consolidate and reliable business-critical data, even when it’s scattered across the enterprise. The product family delivers true multidomain master data management, empowering you with limitless opportunities to start with any type of business-critical data and add as many different domains as you like. Widely recognized for its best-of-breed performance, Informatica master data management products provide comprehensive support for all MDM requirements on a single platform, including data integration, profiling, quality, and master data management.

With the Informatica master data management family of products, you can:

• Address unique MDM business requirements, using the flexible business model–driven approach of Informatica MDM.

• Efficiently search and match identity data, using Informatica Identity Resolution.

5

Informatica MDM Hub Administration

Informatica MDM Hub administrators have primary responsibility for the configuration of the Informatica MDM Hub system. Administrators access Informatica MDM Hub through the Hub Console, which comprises a set of tools for managing an Informatica MDM Hub implementation.Informatica MDM Hub administrators use the Hub Console to perform the following tasks:

•Build the data model and other objects in the Hub Store.•Configure and execute Informatica MDM Hub data management processes.•Configure external application access to Informatica MDM Hub functionality and resources.•Monitor ongoing operations.•Maintain logs needed by Global Customer Support for troubleshooting the Informatica MDM Hub.

Key Adoption Drivers for Master Data Management

Organizations are implementing master data management solutions to achieve the following goals:

•Regulatory compliance, such as financial reporting and data privacy requirements.

•Avoid corporate embarrassments. For example, you can improve recall effectiveness and avoid mailing to deceased individuals.

•Cost savings by streamlining business processes, consolidating software licenses, and reducing the costs associated with data administration, application development, data cleansing, third-party data providers, and capital costs.

•Productivity improvements across the organization by reducing duplicate, inaccurate, and poor-quality data, helping to refocus resources on more strategic or higher-value activities.

•Increased revenue by improving visibility and access to accurate customer data, resulting in increased yields for marketing campaigns and better opportunities for cross-selling and up-selling to customers and prospects.

•Strategic goals, such as customer loyalty and retention, supply chain excellence, strategic sourcing and contracting, geographic expansion, and marketing effectiveness.

6

Informatica MDM Hub as the Enterprise MDM Platform

About Informatica MDM Hub

Informatica MDM Hub is the best platform available today for deploying MDM solutions across the enterprise. Informatica MDM Hub offers an integrated, model-driven, and flexible enterprise MDM platform that can be used to create and manage all kinds of master data.

Informatica MDM Hub implements these characteristics in the following ways:

Integrated: Informatica MDM Hub provides a single code-base with all data management technologies, and handles all entity data types in all modes (for operational and analytical use).

Model-Driven: Informatica MDM Hub models an organization’s business definitions according to its own requirements and style. All metadata and business services are generated on the organization’s definitions. Informatica MDM Hub can be configured with history and lineage.

Flexible: Informatica MDM Hub implements all types of MDM styles registry. Reconciled trusted source of truth and styles can be combined within a single hub. Informatica MDM Hub also coexists with legacy hubs.

Core Components

Hub Store

The Hub Store is where business data is stored and consolidated. The Hub Store contains

common information about all of the databases that are part of a Informatica MDM Hub

implementation. The Hub Store resides in a supported database server environment.

The Hub Store contains:

•all the master records for all entities across different source systems.

•rich metadata and the associated rules needed to determine and continually maintain only the most reliable cell-level attributes in each master record.

•logic for data consolidation functions, such as merging and unmerging data.

Hub Server

The Hub Server is the run-time component that manages core and common services for the

Informatica MDM Hub. The Hub Server is a J2EE application, deployed on the application

server that orchestrates the data processing within the Hub Store, as well as integration with

external applications.

7

Process Server

The Process Server cleanses and matches data and performs batch jobs such as load,

recalculate BVT, and revalidate. The Process Server is deployed in an application server

environment. The Process interfaces with cleanse engines to standardize the data and to

optimize the data for match and consolidation.

Hub Console

The Hub Console is the Informatica MDM Hub user interface that comprises a set of tools for administrators and data stewards. Each tool allows users to perform a specific action, or a set of related actions, such as building the data model, running batch jobs, configuring the data flow, configuring external application access to Informatica MDM Hub resources, and other system configuration and operation tasks.The Hub Console is packaged inside the Hub Server application. It can be launched on any client machine through a URL using a browser and Sun’s Java Web Start.

Inbound and Outbound Data Flows

The main inbound flow into Informatica MDM Hub is called reconciliation.

In Informatica MDM Hub, business entities such as customers, accounts, products, or employees are represented in tables called base objects. For a given base object:

•Informatica MDM Hub obtains data from one or more source systems, an operational system or third-party application that provides data to Informatica MDM Hub for cleansing, matching, consolidating, and maintenance. Reconciliation can involve cleansing the data beforehand to optimize the process of matching and consolidating records. Cleansing is the process by which data is standardized by validating, correcting, completing, or enriching it.

•An individual entity (such as a specific customer or account) can be represented by multiple

records (multiple versions of the truth) in the base object

•Informatica MDM Hub then reconciles multiple versions of the truth to arrive at the master

record, the best version of the truth, for each individual entity. Consolidation is the process of

merging duplicate records to create a consolidated record that contains the most reliable cell

values from the source records.

8

Main Outbound Data Flow (Distribution)

The main outbound flow out of Informatica MDM Hub is called distribution. Once the

master record is established for a given entity, Informatica MDM Hub can then (optionally)

distribute the master record data to other applications or databases.

For example, if an organization’s billing address has changed in Informatica MDM Hub, then

Informatica MDM Hub can notify other systems in the organization (through JMS

messaging) about the updated information so that master data is synchronized across the

enterprise.

Batch and Real-Time Processing

Informatica MDM Hub has a well-defined data management flow that proceeds through

distinct processes in order for the data to get reconciled and distributed. Data can be

processed by Informatica MDM Hub into two different ways: batch processing and real-time

processing. Many Informatica MDM Hub implementations use a combination of both batch

and real-time processing as applicable to the organization’s requirements.

Batch Processing

For batch processing, you load data from source systems and process the data in the MDM Hub. The data that you load from source systems goes through the following series of processes:

Step 1: LandTransfers data from a source system that is external to the MDM Hub to landing tables in the Hub Store. The land process populates landing tables using one of the following methods:

Batch processingA third-party ETL (Extract-Transform-Load) tool or other external process writes the data into one or more landing tables. Such tools or processes are not part of the Informatica MDM Hub suite of products.

9

On-line, real-time processingAn external application populates landing tables in the Hub Store. This application is not part of the Informatica MDM Hub suite of products.

Step 2: StageRetrieves data from the landing table, cleanses it, and copies it into a staging table in the Hub Store. Part of the reconciliation process.

Mappings help the transfer and cleansing of data between landing and staging tables during the stage process. A mapping defines which landing table column the MDM Hub must use to populate a column in the staging table. A mapping defines the standardization and verification that the MDM Hub must perform before it populates a staging table.

The MDM Hub standardizes and verifies data by using the cleanse functions that you configure. Use cleanse functions for specialized cleansing functionality, such as address verification, address decomposition, gender determination, text casing, and white space compression. The output of the cleanse function becomes the input to the target column in the staging table. Step 3: LoadLoads data from the staging table into the corresponding Hub Store table called the base object. Part of the reconciliation process.

If a column in a base object derives its data from multiple source systems, Informatica MDM Hub uses trust to help with comparing the relative reliability of column data from different source systems. For example, the Orders system might be a more reliable source of billing addresses than the Sales system.Trust provides a mechanism for measuring the confidence factor associated with each cell based on its source system, change history, and other business rules. Trust takes into account the age of data, how much its reliability has decayed over time, and the validity of the data. Trust is used to determine survivorship (when two records are consolidated) and whether updates from a source system are sufficiently reliable to update the master record.Trust is often used in conjunction with validation rules, which tell Informatica MDM Hub the condition under which a data value is not valid. When data meets the criterion specified by the validation rule, then the trust value for that data is downgraded by the percentage specified in the validation rule. For example:Downgrade trust on First_Name by 50% if Length < 3

Step 4: TokenizeGenerates match tokens in a match key table that the match process uses to identify candidate base object records for matching.

The tokenize process generates match tokens that are used subsequently by the match process to identify candidate base object records for matching. Match tokens are strings that represent both encoded (match key) and unencoded (raw) values in the match columns of the base object. Match keys are fixed-length, compressed, and encoded values, built from a combination of the words and numbers in a name or address, such that relevant variations have the same match key value.

10

The generated match tokens are stored in a match key table associated with the base object. For each record in the base object, the tokenize process stores one or more records containing generated match tokens in the match key table. The match process depends on current data in the match key table, and will run the tokenize process automatically if match tokens have not been generated for any of the records in the base object. The tokenize process can be run before the match process, automatically at the end of the load process, or manually, as a batch job or stored procedure.

Step 5: MatchCompares records for points of similarity (based on match rules), determines whether records are duplicates, and flags duplicate records for consolidation. Part of the reconciliation process.The match process identifies data that conforms to the match rules that you have defined. These rules define duplicate data for Informatica MDM Hub to consolidate. Matching is the process of comparing two records for points of similarity. If sufficient points of similarity are found to indicate that the two records are probably duplicates of each other, then Informatica MDM Hub flags those records for consolidation.In a base object, the columns to be used for comparison purposes are called match columns. Each match column is based on one or more columns from the base object. Match columns are combined into match rules to determine the conditions under which two records are considered to be similar enough to consolidate. Each match rule tells Informatica MDM Hub the combination of match columns it needs to examine for points of similarity. When Informatica MDM Hub finds two records that satisfy a match rule, it records the primary keys of the records, as well as the match rule identifier. The records are flagged for either automatic or manual consolidation according to the category of the match rule.External match is used to match new data with existing data in a base object, test for matches, and inspect the results without actually loading the data into the base object. External matching is used to pre-test data, test match rules, and inspect the results before running the actual match process on the data.

Step 6: ConsolidateMerges data in duplicate records to create a consolidated record that contains the most reliable cell values from the source records. Part of the reconciliation process.

Step 7: PublishPublishes the best version of the truth to other systems or processes that use outbound JMS message queues.

11

Content Metadata

For each base object in the schema, Informatica MDM Hub automatically maintains support

tables containing content metadata about data that has been loaded into the Hub Store.

Base Objects

A base object (sometimes abbreviated as BO) is a table in the Hub Store that is used to describe central business entities, such as customers, accounts, products, employees, and so on. The base object is the end-point for consolidating data from multiple source systems. In a Informatica MDM Hub implementation, the schema (or data model) for an organization typically includes a collection of base objects.

The goal in Informatica MDM Hub is to create the master record for each instance of each unique entity within a base object. The master record contains the best version of the truth (abbreviated as BVT), which is a record that has been consolidated with the best, most-trustworthy cell values from the source records. For example, for a Customer base object, you want to end up with a master record for each individual customer. The master record in the base object contains the best version of the truth for that customer.

Cross-Reference (XREF) Tables

Cross-reference tables, sometimes referred to as XREF tables, are used for tracking the lineage of data, which systems and which records from those systems contributed to consolidated records, and also for tracking versions of data.For each source system record, Informatica MDM Hub maintains a cross-reference record that contains an identifier for the system that provided the record, the primary key value of that record in the source system, and the most recent cell values provided by that system. In case of timeline-enabled base objects, the associated XREF tables include the period start and end date values for the records. If the same column (for example, phone number) is provided by multiple source systems, the XREF table contains the value from every source system.

Each base object record has one or more cross-reference records. XREF tables are used for merge and unmerge operations, delete management (removing records that were contributed by a particular source system), and to manage versions of business entities and relationships.

History Tables

History tables are used for tracking the history of changes to a base object and its lineage

back to the source system. Informatica manages several different history tables, including

base object and cross-reference history tables, to provide detailed change-tracking options,

including merge and unmerge history, history of the pre-cleansed data, history of the base

object, and history of the cross-reference.

12

Hierarchy Management

The Hierarchy Manager allows users to manage hierarchy data that is associated with the records managed in the MDM Hub.

Relationships

In Hierarchy Manager, a relationship describes the affiliation between two specific entities. Hierarchy Manager Relationships are defined by specifying the relationship type, hierarchy type, attributes of the relationship, and dates for when the relationship is active. Information about a Hierarchy Manager entity is stored in a relationship base object. A relationship type describes classes of relationships. A relationship type defines the types of entities that a relationship of this type can include, the direction of the relationship (if any), and how the relationship is displayed in the Hub Console.

Hierarchies

A hierarchy is a set of relationship types. These relationship types are not ranked, nor are they necessarily related to each other. They are merely relationship types that are grouped together for ease of classification and identification. The same relationship type can be associated with multiple hierarchies. A hierarchy type is a logical classification of hierarchies.

Entities

In Hierarchy Manager, an entity is any object, person, place, organization, or other thing that has meaning and can be acted upon in your database. Examples include a specific person’s name, a specific checking account number, a specific company, a specific address, and so on. Information about a Hierarchy Manager entity is stored in an entity base object, which you create and configure in the Hub Console. An entity type is a logical classification of one or more entities. Examples include doctors, checking accounts, banks, and so on. All entities with the same entity type are stored in the same entity object.

Timeline

Timeline lets you manage versions of business entities and their relationships.The versions of business entities and their relationships are defined in terms of their effective periods. Timeline provides two dimensional visibility into data based on effective periods and history, and equips you with the ability to track past, present, and future changes to data.

You can enable timeline for base objects through the MDM Hub console. When you enable timeline for base objects, state management and history are also enabled by default.

13

SCREENSHOTS-MDM CONSOLE

1. MDM-multidomain

2. MDM-Login Console

14

3. MDM-multidomain

4. Schema Viewer

15

5. MDM-Batch Viewer

6. DATA in TABLES

16

TESTING

“Program testing can be used to show the presence of defects, but never their absence!”

--Dijkstra

What is Software Testing?

• “Testing is the process of exercising or evaluating a system or system component by manual or automated means to verify that it satisfies specified requirements, or to identify differences between expected and actual results.” IEEE

• “The process of executing a program or system with the intent of finding errors.” (Myers)

• “The measurement of software quality.” (Hetzel)

What Does Testing Involve?

• Testing = Verification + Validation

• Verification: building the product right.

• Validation: building the right product.

• A broad and continuous activity throughout the software life cycle.

• An information gathering activity to enable the evaluation of our work, e.g. – Does it meet the users’ requirements? – What are the limitations? – What are the risks of releasing it?

17

18

Unit Testing

• A unit is typically a method/class/a cluster

• Testing done to each unit, in isolation, to verify its behaviour

• Typically the unit test will establish some sort of artificial environment and then invoke methods in the unit being tested

• It then checks the results returned against some known value

• When the units are assembled we can use the same tests to test the system as a whole

Acceptance Testing

• The objective here is to determine whether or not the system is ready for operational use.

• Focuses on user requirements and user involvement is high since they are typically the only people with “authentic” knowledge of the systems intended use.

• Test cases are typically designed to show that the system does not meet the customers’ requirements; if unsuccessful then the system is accepted.

• Acceptance testing is very much to do with validation, i.e. have we built the right product, rather than verification, i.e. have we built the product right.

19

Regression Testing

• Regression testing is applied to code immediately after changes are made.

• The goal is to assure that the changes have not had unintended consequences on the behaviour of the test object.

• We can apply regression testing during development and in the field after the system has been upgraded or maintained in some other way.

• Good regression tests give us confidence that we can change the object of test while maintaining its intended behaviour.

• So, for example, we can change to a new version of some piece of infrastructure in the environment, make changes to the system to take account of that and then ensure the system behaves as it should.

• Regression testing is an important way of monitoring the effects of change.

• There are many issues but the balance of confidence against cost is critical.

20

Agile Testing

A software testing practice that follows the principles of agile software development is called Agile Testing. Agile is an iterative development methodology, where requirements evolve through collaboration between the customer and self-organizing teams and agile aligns development with customer needs.

Advantages of Agile Testing

Agile Testing Saves Time and Money Less Documentation Regular feedback from the end user Daily meetings can help to determine the issues well in advance

Principles of Agile Testing

Testing is NOT a Phase: Agile team tests continuously and continuous testing is the only way to ensure continuous progress.

Testing Moves the project Forward: When following conventional methods, testing is considered as quality gate but agile testing provide feedback on an ongoing basis and the product meets the business demands.

Everyone Tests: In conventional SDLC, only test team tests while in agile including developers and BA's test the application.

Shortening Feedback Response Time: In conventional SDLC, only during the acceptance testing, the Business team will get to know the product development, while in agile for each and every iteration, they are involved and continuous feedback shortens the feedback response time and cost involved in fixing is also less.

Clean Code: Raised defects are fixed within the same iteration and thereby keeping the code clean.

Reduce Test Documentation: Instead of very lengthy documentation, agile testers use reusable checklist, focus on the essence of the test rather than the incidental details.

Test Driven: In conventional methods, testing is performed after implementation while in agile testing, testing is done while implementation.

Manual Testing

21

Manual testing is a testing process that is carried out manually in order to find defects without the usage of tools or automation scripting.

A test plan document is prepared that acts as a guide to the testing process in order to have the complete test coverage.

A key step in the process is, testing the software for correct behavior prior to release to end

users.

For small scale engineering efforts (including prototypes), exploratory testing may be

sufficient. With this informal approach, the tester does not follow any rigorous testing

procedure, but rather explores the user interface of the application using as many of its

features as possible, using information gained in prior tests to intuitively derive additional

tests. The success of exploratory manual testing relies heavily on the domain expertise of the

tester, because a lack of knowledge will lead to incompleteness in testing. One of the key

advantages of an informal approach is to gain an intuitive insight to how it feels to use the

application.

Large scale engineering projects that rely on manual software testing follow a more rigorous

methodology in order to maximize the number of defects that can be found. A systematic

approach focuses on predetermined test cases and generally involves the following steps.[1]

1. Choose a high level test plan where a general methodology is chosen, and resources

such as people, computers, and software licenses are identified and acquired.

2. Write detailed test cases, identifying clear and concise steps to be taken by the tester,

with expected outcomes.

3. Assign the test cases to testers, who manually follow the steps and record the results.

4. Author a test report, detailing the findings of the testers. The report is used by

managers to determine whether the software can be released, and if not, it is used by

engineers to identify and correct the problems.

Automation testing

Test Automation demands considerable investments of money and resources. Successive

development cycles will require execution of same test suite repeatedly. Using a test

automation tool it's possible to record this test suite  and re-play it  as required. Once the  test

suite is automated,  no human intervention is required . This improved ROI of Test

Automation.

Goal of Automation is to reduce number of test cases to be run manually and not eliminate

manual testing all together.

Manual or Automation Testing?

22

Test automation may be able to reduce or eliminate the cost of actual testing. A computer can

follow a rote sequence of steps more quickly than a person, and it can run the tests overnight

to present the results in the morning. However, the labor that is saved in actual testing must

be spent instead authoring the test program. Depending on the type of application to be

tested, and the automation tools that are chosen, this may require more labor than a manual

approach. In addition, some testing tools present a very large amount of data, potentially

creating a time consuming task of interpreting the results.

  Automated testing is important due to following reasons: 

Manual Testing of all work flows, all fields , all negative scenarios is time and cost

consuming

It is difficult to test for multi lingual sites manually

Automation does not require Human intervention. You can run automated test unattended

(overnight)

Automation increases  speed of test execution

Automation helps increase  Test Coverage

Manual Testing can become boring and hence error prone.

23

 Which Test Cases to Automate?

Test cases to be automated can be selected using the following criterion to increase the

automation ROI

High Risk - Business Critical test cases

Test cases that are executed repeatedly

Test Cases that are very tedious or difficult to perform manually

Test Cases which are time consuming

The following category of test cases is not suitable for automation:

Test Cases that are newly designed and not executed manually  at least once

Test Cases for which the requirements are changing frequently

Test cases which are executed on ad-hoc basis.

Automation Process

Test tool selection

Test Tool selection largely depends on the technology the Application Under Test is built on. For instance QTP does not support Informatica.  So QTP cannot be used for testing Informatica applications. It's a good idea to conduct Proof of Concept of Tool on AUT

24

Principles of Test Automation

In considering how to approach a systematic and productive test automation effort, it may help to keep the following principles in mind. They are culled from the experience of many test automation engineers and managers, over the last 15 years. Some of them I have explained in detail in my article Test Automation Snake Oil, and in my book Lessons Learned in Software Testing.

1) Test automation cannot duplicate human testers.

Human testers, even ones who have no special skill or training, are capable of doing and noticing things that no conceivable test automation can do or notice. It’s true that, even with its limitations, automation can have substantial value. But, it’s usually more productive to think of automation as extending the reach of human testing, rather than replacing it. Effective automation efforts therefore begin with effective thinking about testing. Absent good test strategy, automation typically becomes just a lot of repetitive activity that rarely uncovers a bug.

2) Test automation is more than test execution.

Most people who hear about test automation immediately envision some variation of “testing while we sleep.” In other words, they want the computer to run tests. This is indeed one useful kind of automation. But, there’s so much more to it. For instance, any one of the items in the list below can be automated to some extent, even if the other items remain manual processes. ƒ

Test generation (data and script generators). Tools might create specialized data such as randomized email messages, or populate databases, or generate combinations of parameters that we’d like to cover with our tests. ƒ

System configuration. Tools might preserve or reproduce system parameters, set systems to a particular state, or create or restore “ghosted” disk drives. ƒ

Simulators. Tools might simulate sub-systems or environmental conditions that are not available (or not yet available) for testing, or are too expensive to provide live on demand. ƒ

Test execution (harnesses and test scripts). Tools might operate the software itself, either simulating a user working through the GUI, or bypassing the GUI and using an alternative testable interface. ƒ

Probes. Tools might make visible what would otherwise be invisible to humans. They might statically analyze a product, parse a log file, or monitor system parameters. ƒ

Oracles. An oracle is any mechanism by which we detect failure or success. Tools might automatically detect certain kinds of error conditions in a product. ƒ

Activity recording & coverage analysis. Tools might watch testing as it happens and retrospectively report what was and was not tested. They might record actions for later replay in other tests. ƒ

25

3) Test automation is vulnerable to instant obsolescence.

Software projects revolve around production code. Test code is not production code. So the priorities of a typical software project allow production code to change even when that breaks test code. This is normal, and generally speaking it’s a reasonable, economically justified behaviour. Assuming that the product will change, you have basically two options: invest in test code to be robust in the face of such change, or make test code so inexpensive and easy to fix that you don’t mind if product changes break it.

4) Test tools are many and varied.

Most people, especially managers, think of test tools as those tools on the market that are sold as “test tools”. They tend to be quite expensive. But, in fact, almost anything can be a test tool, and many utilities sold for other purposes are especially useful for testing. Some tools are free, some are provided in repositories for developers.

The resources I use include:

MSDN Universal Library Any Microsoft development tool (they always include useful utilities) Microsoft compatibility toolkit and other free tools Web-based web testing resources (HTML checkers, accessibility analyzers) Windows Resource Kits (available from Microsoft) ƒ Scripting languages (e.g. Perl, Ruby, TCL) and associated libraries ƒ Shareware repositories ƒ O/S monitoring tools ƒ Open source test ware Spyware for monitoring exploratory tests ƒ The cubicle next door (often people a few paces away have already created the

necessary tools)

5) Test automation depends on product testability.

Some kinds of test automation become cost effective only if the product under test is designed to facilitate testing—or at least not designed to be exceptionally difficult to test. The two big pillars of testability are controllability and observability. GUI’s are not very testable compared to command-line, batch, or programmatic interfaces, because the latter provide greater controllability. Similarly, observability is increased when log files, probes, or queriable databases are available to augment information visible through the GUI.

6) Test automation can distract you from good testing.

Sometimes the technological focus of test automation can lead to a situation where automators become cut off from the mission of software testing, and produce a lot of tools and scripts that might look good, but have little value in terms of a coherent test strategy that makes sense for the business.

26

Principles of Agile Test Automation

I propose these as operating principles for getting strong, ongoing results from test automation: ƒ

Test automation means tool support for all aspects of a test project, not just test execution. ƒ

Test automation is directed by testers. ƒ Test automation progresses when supported by dedicated programmers (toolsmiths). Test toolsmiths advocate for testability features and produce tools that exploit those

features. ƒ Test toolsmiths gather and apply a wide variety of tools to support testing. Test automation is organized to fulfill short term goals. ƒ Long term test automation tasks require a compelling business case.

Transitioning to Agile Test Automation

1) Establish and announce the role of the test automation team to developers and testers.

2) Establish a reporting system and a dispatching system for the automation team.

3) Make an inventory of known testware within the company.

4) Make a quick survey of testware available outside the company.

5) Have toolsmiths sit with testers, understand how they test, and identify test automation opportunities

6) Create the experience for the testers of making a request and seeing it rapidly granted.

7) Review the progress of the automation effort no less frequently than every two weeks.

8) Continue to improve the training of the testers, so that they are better able to conceive of sophisticated test strategies.

27

Agile Testing Quadrants

Test Automation Pyramid

28

Testing Tool Spectrum

Benefits of automated testing

Following are benefits of automated testing:

70% faster than the manual testing

Wider test coverage of application features

Reliable in results

Ensure Consistency

Saves Time and Cost

Improves accuracy

Human Intervention is not required while execution

Increases Efficiency

Better speed in executing tests

Re-usable test scripts

Test Frequently and thoroughly

More  cycle of execution can be achieved through

automation

29

Tools used for testing

1. Automated Unit Testing-Junit2. Regression Testing-IBM-RFT3. Acceptance Testing-IBM-RFT4. Continuous integration-Jenkins

JUnit

JUnit is a unit testing framework for the Java Programming Language. It is important in the test driven development, and is one of a family of unit testing frameworks collectively known as xUnit. JUnit promotes the idea of "first testing then coding", which emphasis on setting up the test data for a piece of code which can be tested first and then can be implemented. This approach is like "test a little, code a little, test a little, code a little..." which increases programmer productivity and stability of program code that reduces programmer stress and the time spent on debugging.

Features

JUnit is an open source framework which is used for writing & running tests.

Provides Annotation to identify the test methods.

Provides Assertions for testing expected results.

Provides Test runners for running tests.

JUnit tests allow you to write code faster which increasing quality

JUnit is elegantly simple. It is less complex & takes less time.

JUnit tests can be run automatically and they check their own results and provide immediate feedback. There's no need to manually comb through a report of test results.

JUnit tests can be organized into test suites containing test cases and even other test suites.

What is a Unit Test Case?

A Unit Test Case is a part of code which ensures that the another part of code (method) works as expected. To achieve those desired results quickly, test framework is required .JUnit is perfect unit test framework for java programming language. A formal written test-case is characterized by a known input and by an expected output, which is worked out before the test is executed. The known input should test a precondition and the expected output should test a post condition. There must be at least two test cases for each requirement: one positive test and one negative test. If a requirement has sub-requirements, each sub-requirement must have at least two test cases as positive and negative.

30

31

Snapshot-Junit

Snapshot-Test Result

32

IBM-RFT

IBM Rational® Functional Tester software enables the automation of functional and regression testing. Designed with a deep understanding of Java™, Web, SAP, Siebel and Microsoft® Visual Studio .NET Windows® Forms technologies, Rational Functional Tester software combines a robust recorder of user actions with multiple customization options and intelligent script maintenance capabilities to help ensure a test creation and execution process that’s resilient in the face of application change. Rational Functional Tester software— accessible to novices and experts alike—is suitable for testers, GUI developers and anyone else on the project team who needs to ensure effective software development.

Rational Functional Tester Features

The following are the key features of RFT. Use Add-ins to support multiple environments

· Projects · Test Object Inspector

· Test Object Map · Recording test scripts

· Replay test scripts · Debug scripts · Java Scripting

· Create Verification points – GUI, Bitmap, Menu

· Databases sample scripts

· Data Pool the test cases · Suite (Batch Run)

In RFT, Project needs to be created on which multiple scripts can be generated with record reply or with scripting. Rational supports java and vb scripting, Rational can identify windows based objects only on installing .net frame work. Before staring of Rational Functional tester, the test application needs to be configured for easy handling. This can be done using Configure tab. This will enable Functional tester to start the application to test during the recording event. Also this makes the functional tester more reliable.

33

Snapshot-IBM_RFT

34

Continuous integration (CI)

“Continuous Integration is a software development practice where members of a team

integrate their work frequently; usually each person integrates at least daily - leading to

multiple integrations per day. Each integration is verified by an automated build (including

test) to detect integration errors as quickly as possible” – Martin Fowler

Continuous integration (CI) is the practice, in software engineering, of merging all developer

working copies with a shared mainline several times a day. It was first named and proposed

by Grady Booch in his method but he did not advocate integrating several times per day. It

was adopted as part of extreme programming(XP), which did advocate integrating more than

once per day, perhaps as many as tens of times per day. The main aim of CI is to prevent

integration problems, referred to as "integration hell" in early descriptions of XP. CI isn't

universally accepted as an improvement over frequent integration, so it is important to

distinguish between the two as there is disagreement about the virtues of each.

Continuous Integration, also known as CI, is a cornerstone of modern software development.

In fact it is a real game changer—when Continuous Integration is introduced into an

organization, it radically alters the way teams think about the whole development process. It

has the potential to enable and trigger a series of incremental process improvements, going

from a simple scheduled automated build right through to continuous delivery into

production. A good CI infrastructure can streamline the development process right through to

deployment, help detect and fix bugs faster, provide a useful project dashboard for both

developers and non-developers, and ultimately, help teams deliver more real business value

to the end user. Every professional development team, no matter how small, should be

practicing CI.

35

CI – What does it really mean?

At a regular frequency (ideally at every commit), the system is:

Integrated All changes up until that point are combined into the project

Built The code is compiled into an executable or package

Tested Automated test suites are run

Archived Versioned and stored so it can be distributed as is, if desired

Deployed Loaded onto a system where the developers can interact with it

But Continuous Integration is a mindset as much as a toolset. To get the most out of CI, a

team needs to adopt a CI mentality. For example, your projects must have a reliable,

repeatable, and automated build process, involving no human intervention. Fixing broken

builds should take an absolute priority, and not be left to stagnate. The deployment process

should be automated, with no manual steps involved. And since the trust you place in your CI

server depends to a great extent on the quality of your tests, the team needs to place a very

strong emphasis on high quality tests and testing practices. In this book we will be looking at

how to implement a robust and comprehensive Continuous Integration solution using Jenkins

or Hudson.

Jenkins

Jenkins, originally called Hudson, is an open source Continuous Integration tool written in

Java. Boasting a dominant market share, Jenkins is used by teams of all sizes, for projects in a

wide variety of languages and technologies, including .NET, Ruby, Groovy, Grails, PHP and

more, as well as Java. So what has made Jenkins such a success? And why use Jenkins for

your CI infrastructure? Firstly, Jenkins is easy to use. The user interface is simple, intuitive,

and visually appealing, and Jenkins as a whole has a very low learning curve. As we will see

in the next chapter, you can get started with Jenkins in a matter of minutes. However Jenkins

does not sacrifice power or extensibility: it is also extremely flexible and easy to adapt to

your own purposes. Hundreds of open source plugins are available, with more coming out

every week. These plugins cover everything from version control systems, build tools, code

quality metrics, build notifiers, integration with external systems, UI customization, games,

and much more. And installing them is quick and easy. Last, but certainly not least, much of

Jenkins’s popularity comes from the size and vibrancy of its community. The Jenkins

community is a large, dynamic, reactive and welcoming bunch, with passionate champions,

active mailing lists, IRC channels and a very vocal blog and twitter account. The

development pace is fast, with releases coming out weekly with the latest new features, bug

fixes, and plugin updates.

Why Jenkins? Flexibility!

36

Jenkins is a highly configurable system by itself

The additional community developed plugins provide even more flexibility

By combining Jenkins with Ant, Gradle, or other Build Automation tools, the

possibilities are limitless Jenkins is released under the MIT License

There is a large support community and thorough documentation

It’s easy to write plugins Think something is wrong with it? You can fix it!

Continuous integration is a necessity on complex projects due to the benefits it provides regarding early detection of problems A good continuous build system should be flexible enough to fit into pre-existing development environments and provide all the features a team expects from such a system Jenkins, a continuous build system, can be an integral part of any continuous integration system due to its core feature set and extensibility through a plugin system.

Snapshot-Jenkins

37

38

CONCLUSION

39

Thanks to the internship, which helped me discovering new skills and polish my old ones? I made good friends in Informatica which helped me wherever I get stuck. I do not regret anything in this experience and I thank all those who have allowed such a thing feasible

And I feel extremely satisfied by the fact that I have managed to develop the project of my

course with equal contribution from my team members. I think I have exploited the

opportunity that came my way to the fullest extent by increasing my technical know-how and

also gaining the valuable work experience apart from studying the other subjects in our

curriculum.

REFERENCES

40

WEBSITES:

www.W3Schools.com http://www-03.ibm.com/software/products/en/functional http://www.cs.colorado.edu/~kena/classes/5828/s12/presentation-materials/

bowesjesse.pdfwww.javatpoint.com http://www.bogotobogo.com/DevOps/Jenkins/images/Intro_install/jenkins-the-

definitive-guide.pdf http://www.vogella.com/tutorials/Jenkins/article.html http://www.tutorialspoint.com/junit/junit_tutorial.pdf www.wikipedia.com http://smartbear.com/all-resources/articles/what-is-agile-testing/ https://www.iiitd.edu.in/~jalote/jalotesebook/JaloteSEbook/tmp/UnitTesting.pdf

BOOKS:

JavaBeans: Developing Component Software in Java Thinking In Java By Bruce Eckel

Professionaltester

41