Quick Test Pro Vs UFT XX (11.50,51,52,53)

Quick Test Pro Vs UFT XX (11.50,51,52,53)

·         Licenses for QTP or ST will work for UFT, but they can restrict some features. It’s recommendable to upgrade to UFT Licenses to take advantage to the complete functionality provided by the tool.

·         If you just need API Testing, you can use HP Service Test Standalone, however this option it’s not available for GUI testing.

·         HP Unified Functional Testing offers new Add-ins for GUI testing as such as: QT and Flex.

·         HP Unified Functional Testing is not considered to be newer version of either Quickest Professional or Service Test.

·         Insight Recording for GUI Tests, it enables us to record control(object) displayed on screen, even if it UFT does not recognizes the object technology.

·         Removed menus from UFT: Insert, Automation , Debug Menus

·         Added Menus under UFT : Search , Design, Record, Run, ALM

Unified Functional Testing - Introduction

Unified Functional Testing = Quick Test Pro (QTP) + Service Test(ST)

Here Quick Test Professional (QTP) is a functional automation testing tool and Service Test (ST) is used for API testing(non GUI)

UFT 11.5 can support mobile testing as well ,using this feature we can test out multiple mobile devices as well in simulators.

HP Unified Functional Testing [UFT] is a new tool released in December of 2012

Supported Technology: Windows 2012, Firefox 22-24, Chrome 27-30, IE10, HTML5 enhancement, .NET Framework 4.5, Citrix 6.5, PeopleSoft 9.53, Flex SDK 4.6.

Features:

New look and feel for BPT test editing inside UFT

Create web service activities from Network Capture Data (PCAP file)

Have checkpoints for PDF, Txt ,word , HTML AND RTF files

HP UFT Insight

Key Elements in UFT Window

Active Screen: Provides a snapshot of your application as it appeared when you performed a certain step during the recording session

Data Table: Assists you in parameterizing your test. The Data Table contains the Global tab and a tab for each action

Debug Viewer: Assists you in debugging your document. The Debug Viewer pane contains the Watch, Variables, and Command tabs

Information: Displays a list of syntax errors found in your test and function library scripts

Missing Resources: Provides a list of the resources that are specified in your test but cannot be found, such as missing calls to actions, unmapped shared object repositories, and parameters that are connected to shared object repositories

UFT Licenses Types Type of QuickTest/UFT Licenses

1.Demo

2.Seat License

3.Concurrent License

Add In

•Install all add-ins over a single UFT installation

•Select which add-ins to use for a particular QuickTest session

•Built-in support: Standard windows

•Other core add-ins: Web ActiveX Visual Basic

•External Add-ins DotNet Delphi SAP MultiMedia Terminal Emulator Java Stingray Siebel Small Talk Oracle PeopleSoft ………………………..and many more

UFT-11.5x Basics Training

•      Automation Concepts

•      QTP vs UFT

•      Overview of UFT, Licenses & Add-ins

•      UFT Settings (high level only)

•      Recording a Test

•      Running & Analyzing a test

Why Testing Tools?

Automated Testing Life Cycle

Which Test Case to Automate?

• Tests that need to be run for every build of the application (sanity check, regression test)
• Tests that use multiple data values for the same actions (data driven tests)
• Stress/load /Web-Service /Smoke Testing  test cases are good candidates for automation.
• Tests requiring a great deal of precision ,complex in nature and consume huge manual effort.
• Functionalities which are stable and live under production system.
• Test cases through which are required from good ROI perspective.
• Test cases which are mainly suitable from business user perspective.
• More repetitive execution! Better candidate for automation.

Introduction on Selenium Tool

Selenium is a free (open source) automated testing suite for web applications across different browsers and platforms. It is quite similar to HP Quick Test Pro (QTP) only that Selenium focuses on automating web-based applications.


Selenium is not just a single tool but a suite of software's, each catering to different testing needs of an organization. It has four components.


· Selenium Integrated Development Environment (IDE): selenium Integrated Development Environment (IDE) is the simplest framework in the Selenium suite and is the easiest one to learn. It is a Firefox plugin that you can install as easily as you can with other plugins.


· Selenium Remote Control (RC): Selenium RC was the flagship testing framework of the whole Selenium project for a long time. This is the first automated web testing tool that allowed users to use a programming language they prefer.


· WebDriver: It implements a more modern and stable approach in automating the browser's actions. WebDriver, unlike Selenium RC, does not rely on JavaScript for automation. It controls the browser by directly communicating to it.


· Selenium Grid: Selenium Grid is a tool used together with Selenium RC to run parallel tests across different machines and different browsers all at the same time. Parallel execution means running multiple tests at once.






Why do we need to automate?


§ To avoid human intervention


§ To make it fast and productive


§ To make it reusable or repeatable 

§ To make it reliable

What is Automation Testing

• Developing Scripts to Run the Test Cases Automatically and to Log the Results
•  Software Test Automation is the process of automating the steps of manual test cases using an automation tool Or utility to shorten the testing life cycle with respect to time…
•  When application undergoes regression, some of the steps might be missed out or skipped which can be avoided in Automation…
•  Automation helps to avoid human errors and also expedite the testing process…
•  To implement the Test Automation detailed planning and effort is required

Importance of Automation Testing

In today’s environment of reducing cycle times, test automation becomes an increasingly critical and strategic necessity. Especially in the new explosive pace of web-enabled deployment, if retaining satisfactory test coverage and reducing risk is required, then either more people have to be put on manual testing, or a greater level of test automation is required to keep the pace. After all, a reduction in project cycle times generally correlates to a reduction of time for test.

There are certain other aspects which make automation more helpful, some of them are listed below.

§ Increased speed of execution

§  Machine results are more replicable than human results

§  Parallel execution, Re-use of test cases etc are some additional   benefits.

Automation Fundamental Concepts

• Automation life cycle is a subset of the entire test life cycle…
•  Automation planning can be initiated in parallel to the test planning phase…
•  Factors to be considered in automation planning,
•             Stability of AUT (Application under test)
•             No of regression cycles to be performed
•             Compatibility of App platform with testing tools
•             Cost benefit analysis (ROI)
•             Availability of skilled resources

Defect Management

Defect Management Process

The primary goal of Defect Management is to detect and track the defects to closure, implementing the processes required for coordination between the teams for the defect prevention and defect closure. The Defect Management Approach defines

Defect Triage and Prioritization Process

o Stages of Defect

· Defect Discovery

· Defect Resolution

· Defect Tracking

o Defect Discovery

· Find a Defect

· Report Defect

· Acknowledge Defect

o Defect Resolution

· Prioritize: Determine the importance of fixing a particular defect.

· Categorize: Classify defects with end users.

· Fix: Developers fix defects in order of importance.

· Report: Developers notify all relevant parties how and when the defect was repaired.
Defect Tracking

§ Monitoring Defects from the time of recording until satisfactory resolution has been determined
Prioritization Process



Priority

Label

Description

Priority1

Critical

Priority 1 defects prevent the operation of the Site or Application


Priority2

Major

Priority 2 defects limit the ability to operate the business efficiently but a Loblaw’s approved workaround is defined.


Priority3

Minor

Minor defects that do not significantly affect the operation or appearance of the Sites.


Priority4

Trivial

Cosmetic defect which do not affect the flow of the workflow.


Table 4.1 Proirity

4.2 Defect Management Process



Figure 4.3 Stages of Defect



4.3 TEST STATUS REPORT
4.3.1 Daily Status Reports

The daily reports would be made by the testers which will be consolidated and submitted to the client. In these reports we would be updating the client regarding the daily proceedings with the various test cases i.e. which have been executed, which have not been executed and what all would be done on that day
4.3.2 Weekly Status Reports

These reports would be submitted by each track lead which would update the client regarding the work done on each of the tracks
4.3.3 Application Health Check Report

This would be submitted by the QA Manager telling the big picture regarding the overall work done.

4.4 OVERALL COMPLETION CRITERIA FOR TESTING



Figure 4.4 Completion Criteria

A critical aspect of monitoring the progress and acceptance of the end result of Testing for the Version 1.0 will be a clear understanding and agreement on completion criteria.

One key aspect of this is the successful identification and resolution of issues/defects.

Issues/defects are categorized as follows:

CRITICAL:

Causes system to crash or does not support critical functional requirements tied to Key Performance Parameters. No acceptable work-around. Unable to demonstrate completed business scenario.

HIGH:

Causes significant system degradation or a difficult work-around to support critical functional requirements tied to Key performance Parameters. Business scenario can be completed with difficulty.



MEDIUM:

Causes moderate system degradation or a work-around to support critical functional requirements tied to Key performance Parameters. Business scenario can be completed with moderate to minor impact to business process.

LOW

Causes minor system degradation or minor work-around to support critical functional requirements tied to Key performance Parameters. Business scenario can be completed with minor to no impact to business process.



Completion criteria for Pre-System Test have been established as following:

· Each business Test Case exercised

· Each required conversion, interface and enhancement completed

· No CRITICAL unresolved issues/defects, may allow HIGH if necessary, but have

· an action plan.

· Action plans exist for remaining HIGH, MEDIUM and LOW issues/defects

· Security and Privileges(Profiles) established and tested

Completion criteria for System Test have been established as following:

· Each business Test Case exercised

· Each required conversion, interface and enhancement completed

· No CRITICAL, HIGH and MEDIUM unresolved issues/defects remain

· Action plans exist for remaining LOW issues/defects

· Security and Privileges (Profiles) established and tested

Completion criteria for Beta Test have been established as following:

· Each business Test Case exercised and

· Each required conversion, interface and enhancement completed

· No CRITICAL, HIGH, MEDIUM and LOW unresolved issues/defects remain

· Security and Privileges (Profiles) established and tested

Business Users

A non-Sapient employee who serves as an independent observer/assessor of the system during testing. While acting as a Business User, the person represents others with the same functional specialty and provides input from that perspective. Input includes functional issues, any other business requirements and other documentation, and overall assessment of the system.

Business Users will be assigned to scenarios and testing sessions based on their skill set at Mercury Tours.

Changes

Changes to any of the testing documents will be done at the end of each testing cycle.

The only exception to this will be in the event of a change request event or change that is needed.

Test Scenarios

A test scenario is a string of business processes, which lead to an expected outcome.

Changes to the Test Scenarios must be submitted by the test team member to the Test Team Manager for signoff.

Communications

Communications between the entire Test Team and Mercury Tours POC is critical during testing. There may be many activities going on at one time and all resources will be called upon to assist in the successful execution of all testing cycles. It is everyone’s responsibility to review the issues database for progress on issues related to testing.

Testing Tool:

The following tools should be provided to the QA Team prior to commencement of testing:

1. Defect Logging and Tracking tool: Quality Center or JIRA

2. Selenium For Functional and Regression Testing



3. Apache Jmeter: For Load Testing.

TEST PROCESS

Work Products Creation (Deliverables)

During the Testing phases, various deliverables will be provided as outcome. These are listed as follows

· Gap Analysis Report

· Requirement Traceability Matrix

· Test Strategy

· Estimation Report

· HLP/MLP for the release

· High Level Test Scenarios

· Selenium Script

· Defect Status Report

· Test Completion Report
4.1.1 Gap Analysis Report

After getting the Project Requirements, we have logged our various queries in Requirement Query Log and discussed these in the client meetings. The Gaps in understandings were logged into this document.
4.1.2 Requirements Traceability Matrix (RTM)

After the requirements have been frozen by the client and the test cases are signed off by the user. The QA Team would form the Requirement Traceability Matrix and get it signed off from the client confirming that all the requirements have been covered
4.1.3 HLP/MLP

During this iteration for quality assurance, the team has been working in synchronization with the High-level plan and Mid-Level Plan
4.1.4 Estimation Report

Various Time and Effort estimations were included in the Estimation Report. These estimations are mapped with the HLP also.
4.1.5 Defect Status Report

Depending upon the outcome of each and every test case executed defects would be logged and the number of defects that are found would be logged and reported back to the stakeholders. All the defects encountered during test execution are logged in Jira and a Defect Status Report is generated.
4.1.6 High Level Test Scenarios (HLTS)

The High Level Test Scenarios have been created by test leads and the QA Manager.
4.1.7 Test Cases

All the test cases would be created by the Test Analyst and would be validated by the Test Lead to make sure that the test cases map back to the requirements the user had defined.
4.1.8 Test Scripts

All the test cases once manually tested will be automated into scripts using Selenium
4.1.9 Test Completion Report

After execution of all tests, it is recorded in the Test Completion Report which explains the number of test executed or gated or passed or failed and the overall test coverage.

4.2 Work Products Review Process
· Test Deliverables Review

Each of the deliverables would be reviewed by the test lead and the QA Manager before being delivered to the client.
· Maintenance of Test Cases/Scripts

The various test cases and scripts would be regularly updated and versioned by the QA Team in order to make things coordinate much better. If in case the test cases/scripts have been changed by the user depending upon change in defect or requirements, due to versioning of scripts we would be able to map defects to the version of case/script that caused it.

4.3 TEST MANAGEMENT

4.3.1 Test Environments
· System Test Environment

QA team will create both manual and automated test scripts based on the requirements mentioned in the wireframes and FSD’s. These scripts will be executed on the local QA environment which will consist of both authoring as well as publishing instances. This environment will be based locally within Sapient environment.
· System Integration Test Environment

Once all test scripts have been successfully executed on the system test environment and there are no open P1’s and P2’s on the test environment. Along with the system test scripts, QA team will create and execute End 2 End test scripts on the SIT environment. Please note that the SIT environment will be a scaled down version of the production environment which will consist of both authoring as well as publishing instances. This environment will be based locally within stakeholder environment.
· UAT Environment

This environment will also be used as the Production environment wherein UAT test scripts (created by Stakeholder) will be executed and finally a Go/No Go sign-off decision will be provided. Post UAT sign-off, application will be deployed on the Production environment (during the cutover phase) and application sanity will be tested on the production environment. Please note that all System Test scripts will not be executed on the production environment. This environment will also consist of both authoring as well as publishing instances.

4.3.2 Test Data Management
· Test Data from Production

The test Data would be provided to us by the client. The data should have been validated and be data from the production environment
· Test Data Creation

The dummy data provided to us would be used to create new data. We would use the front end applications of the user to create that data
· Test Data Maintenance



The data would be versioned and saved. This would help preserve the original data as well as show the various transitions in the data that might have happened as the data moved through the application

Testing Methods

4.1.1     Unit Testing

The developers test their module to check if individual units of source code are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual function or procedure. Ideally, each test case is independent from the others: substitutes like method stubs, mock objects, fakes and test harnesses can be used to assist testing a module in isolation. Unit tests are typically written and run by software developers to ensure that code meets its design and behaves as intended. Its implementation can vary from being very manual (pencil and paper) to being formalized as part of build automation.

4.1.2     Smoke Testing

A quick high level test that the major functions of a piece of software work originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire.

4.1.3     Functional Testing

This test will confirm that all the functionalities mentioned in the requirement document are working correctly as designed. From the tester’s perspective, this test will be carried out from Unit Testing to all the way to the production.

4.1.4     Regression Testing

This is a repeated test to check whether the application is working as intended after a bug fix or after adding a new functionality in the application.

4.1.5     Pre-System Testing:

As the developers finish writing their code for Mercury Tours or are about to finish, the Mercury Test Team will create a test environment where the testers will test to check whether there is any major break down in the application. This test will also test the integration of components. Any critical defects (or high level defects in some cases) will be resolved immediately before it goes to System Testing environment. This testing will help create a cleaner application in the System Test environment.

4.1.6     System Testing

This activity will test Mercury Tours in the Test Environment upon the completion of pre-system testing, Mercury will create System Testing environment where the all the functionalities will be tested as per Use Cases. All the Test Cases will be executed and the defects will be logged as found. This environment will be environment for Mercury Test Team and will not be available for Mercury Tours Test Team. Once the System Test meets the exit criteria, then the system will be ready for Beta Testing.

4.1.7      Beta Testing

Upon completion of the requirements, development and system testing phase, Mercury will create a Beta Testing environment (the Beta site). The Beta site will be created within the Mercury network but will be available to the Mercury. The Beta site will be a scaled down version of the planned production environment and as such will not have all of the security and redundancy that a production environment would normally have. It will also not have the same performance as a production environment, but the performance will be adequate considering the minimal number of users accessing it. The network configuration and software codebase will be identical to the planned production environment. Mercury anticipates using the Beta site to continue our own internal testing, and the

Mercury or any of its designees will have full access to test any or all of the features. Mercury will create a test bed of data that the Mercury can use in their testing. These data will not be a full representation of the production site, but will allow a tester to complete an application and choose from a small subset of the member institutions, for example. A couple of supplemental forms will be available, and the e payment testing will use test credit cards and create test transactions. The Beta site is not intended for stress testing. If any problems are discovered, a mutually agreed upon process of reporting and tracking defects will be used. Mercury will use an iterative approach, fixing issues and releasing new code to be retested by the tester who reported the problem until the issue is resolved to the tester’s satisfaction.

4.1.8      Acceptance Testing (UAT)

After Beta testing is completed, Mercury will create a User Acceptance testing environment (the UAT site). The UAT site will be created within the production network environment in the AT&T Data Center and be fully available to the Mercury. The UAT site will be on the production hardware, and will have all the security features of our standard production environment. Redundancy will be added before going live. Performance will be identical to that in production.

Sapient will work with the Mercury to create a full test bed of data .  The UAT site is intended to verify the final configuration of the site and the data, and will be the basis for the production environment.

4.1.9     Stress Testing:

After the Beta Testing is complete, Test Team will perform this testing which will determine the stability of Mercury Tours This testing will be conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. Often this is performance testing using a very high level of simulated load.

4.1.10  Load Testing:

Load testing will be carried out by putting a computer, peripheral, server, network or application to a work level approaching the limits of its specifications. This testing will be done under controlled lab conditions to compare the capabilities of different systems to accurately measure the capabilities of a single system. This testing will be as per realistic and close environment.

The above three different types of testing will be done in three cycles:

1. Cycle 0

2. Cycle 1

3. Cycle 2

The QA Team will execute all scenarios