Software Testing Training | QTP, QC, ISTQB, LoadRunner, CSTE, Mercury, Rational Certifications

Comprehensive Functional Testing with IBM Rational Robot
Course Code : CTROB 300 Source : CresTech Course Length : 2 days

This course is designed to familiarize testing professionals with the basics of Rational’s functional test automation tool, Rational Robot. Students will be provided with hands-on instruction, from simple record/playback techniques to advanced test scripting concepts. Rational TestManager will be used to organize and process test results to facilitate data analysis. The focus will be on applying Rational Robot to resolve common automated testing challenges and to build effective, versatile test scripts through best practices and savvy usage of SQABasic code. At the conclusion of this module, principles learned will be applied to a .NET-based sample application.
Further this course gives students a foundation in the SQABasic scripting language and automated testing techniques. Learn to create test scripts that are more robust, durable and easier to maintain. The course includes lecture, workbook exercises and labs.

The advanced module is designed to give students a foundation in the SQABasic scripting language and automated testing techniques. Learn to create test scripts that are more robust, durable and easier to maintain. This module includes lecture, workbook exercises and labs.

Intended Audience

New Rational Robot, TeamTest, TestStudio, or Enterprise users. The principles taught in this course apply to all environments that Robot supports. The course is designed primarily for Quality Assurance professionals who will be using the automation tools.
The audience might also include QA practitioners, managers, or team leaders who are responsible for interacting with testers or who need to ensure that tools are being implemented fully and appropriately.
Course Objectives
At the end of the course, you will be able to:

Describe the function and purpose of Rational Robot.
Navigate the Rational Robot interface.
Apply good scripting practices.
Record and play back automated scripts.
Use Verification Points in an appropriate context.
Modify scripts to extend test capability and reduce script maintenance.
Create data-driven tests
Prerequisites

You must have a solid understanding of:

Microsoft Windows operating systems
Microsoft Windows applications
Be familiar with the following:

Quality Assurance processes
Programming principles and techniques
Course Outline

Benefits of using Rational Robot to automate tests
Test script development process
Contents of a Rational Project and test datastore
Recording, debugging, and playing back techniques
Setting the record and playback options for Rational Robot
Developing and executing shell scripts
Inserting verification points and wait states to ensure test script reliability and validity
Regression testing using existing Rational Robot test scripts
Using the test log and verification point comparators to investigate and analyze test results
Using SQABasic to edit test scripts to extend their functionality and reduce maintenance
Creating custom verification points
Using datapools and data files
Testing a .NET application
Variables: declaration, datatypes, scope
Operators: mathematical, logical, string
Object Scripting - Terminology, meaning, common commands, types of properties, return values
Control Flow Structures: if¦then¦end if and select case statements; loops (for next while doloop)
Use of Dialog and Input Boxes
User-defined functions and sub procedures; header, source, library and template files
Dynamic Verification Points
Robot Debugger
String manipulation
Arrays: static and dynamic; single and multidimensional
Data handling techniques and routines
Files: creating, reading from, writing to
Database access through SQL calls
COM object creation

Web Testing

http://www.crestechsoftware.com

Compatibility Testing
Course Code :CTQCT 105 Source : CresTech Course Length : 2 days

QA professionals have the industry expertise to implement a comprehensive suite of compatibility / interoperability tests for your product. We will test your software, hardware, Web site, or internal application according to industry standards with special focus on your target market.
Compatibility testing is performed on your software or hardware product in our quality test lab, provisioned for an environment specific to your customers. Our QA Lab has a vast array of desktop systems, servers, laptops, operating systems, browsers and plug-ins. Our lab provisioning methods allow test matrixies to be quickly configured to maximize the range of possible testing configurations to meet your needs.
In addition we have expanded the compatibility matrix to include the most popular virtualization environments. So if you are developing a virtual appliance or virtual application stack we can test it in all supported environments.
Also with the increased popularity of VISTA x32 and VISTA x64 there are additional potential compatibility issues especially on the 64bit architecture. SWAT Lab form the necessary tests to ensure your product is compatible with all versions of VISTA

Some typical compatibility tests include:

Testing a Web site, or Web-delivered application for compatibility with a range of the leading browsers and desktop hardware platforms.
Testing a peripheral with a wide range of PCs.
Testing a server with different add-in cards, applications, and operating systems.
Testing an application on a range of different operating systems and in combination with other applications.
Verifying the compatibility and interoperability of a set of enterprise-class applications in a complex hardware and software environment designed to meet your specific business needs.
In addition to the comprehensive compatibility testing provided by SWAT Lab, we also provide online access to the testing through our web-enabled portal. This enables your developers to view the results of the testing in real time and respond immediately to any discrepancies that are uncovered. SWAT Lab becomes your local QA center, helping you to meet your critical project deadlines.

Why utilize Crestech for compatibility testing?
We can test compatibility for both software and hardware, and we can set up almost any test environment you need, from a simple selection of a dozen browsers on the leading desktop systems to a complex enterprise server farm.
We can test your website, CD, or application quickly and inexpensively.
Our testing lab offers all the hardware and software needed for such testing.
We are experts at testing products for compatibility with hardware and software environments.
If testing every possibility strains your budget, we’ll help you narrow the field to the most likely areas, so that you can maximize the return on your testing investment.
We offer web-enabled reporting that ensures you always know the status of your product’s testing.
You will receive objective feedback you can use to insure a stable release of your product.
Our testing process includes:

Expert consultation on defining the compatibility issues that are significant for your product and a cost-effective matrix of platforms it should be tested against.
Development of a Compatibility Test Plan specifying exactly what tests will be executed.
Test execution by our staff of experienced test engineers.
Using our online portal, you will have complete, real-time access to the development and execution of your tests. This allows you to view and supervise the work being done on your project during every phase from start to finish.

http://www.crestechsoftware.com

Business Process Testing 9.2 for Subject Matter Experts
Course Code : CTMBPT 540 Source : CresTech Course Length : 2 days

This entry-level training provides the Subject Matter Expert with a workflow of tasks to follow in order to successfully implement a Business Process Testing solution in a Quality Center environment. Fundamental concepts, terminology and best practices will be presented. These basic concepts and procedures are reinforced by review questions and hands-on labs.

Intended Audience

Individuals interested in implementing the Business Process Testing methodology solution.
Anyone transitioning from a manual test based Quality Center environment to an automated, component based environment.
Course Objectives

At the end of the course, you will be able to:
Use Quality Center 9.2 to create a Business Process Test

Discuss the BPT Workflow and Roles
Create a sample Test Set and Component structure
Discuss the purpose of an Application Area
Create a Manual Component
Convert a Manual Component to an Automated Component

Add parameters to a component

Run and Debug a Manual and Automated Component

View Test Run Results

Prerequisites

Experience with Microsoft Windows
Basic understanding of the testing process
Has successfully completed the Using Test Director or Using Quality Center course
Experience with QuickTest Professional is extremely helpful
Course Outline

Business Process Test Methodology

The BPT Workflow

Working With Requirements for BPT

Test Plans and Requirements Coverage

Introduction to Business Components

Creating Manual Components

Navigate the Business Component module
Keyword-Driven Tests

Executing Business Process Test Sets

http://www.crestechsoftware.com

Application Web Testing
Course Code : CTQWT 100 Source : CresTech Course Length : 2 days

Introduction :

This training course provides a comprehensive overview of methods, techniques and tools that can be applied to testing of e-business systems. In addition the course will focus on management and team skills that ensure that testing is conducted effectively and efficiently. The course is focused on practical approaches to testing, based on the experience of the presenters? skills in consulting and test outsourcing, as well as adopting leading trends and ideas emerging from Europe and the USA . During the course extensive case-studies and real-world experiences will be presented.

Intended Audience :

This course addresses e-business issues of concern to project, development and testing managers as well as testing practitioners. Managers will learn new approaches for identifying and managing risks, preparing test strategies and identify test activities, and for planning and monitoring the testing process. Test practitioners will learn new techniques and tools for conducting e-business tests.

Course Objectives :

By the end of this course participants will be able to:

Develop a strategy and plans for testing e-business applications
Define comprehensive and cost-effective tests to dig out bugs in your systems
Identify bugs and ensure that bugs are being resolved appropriately
Utilise automated test tools to reduce costs involved in testing
Manage your testing activities and test team
Course outline

Web Application Testing Foundation

How Web Application Testing is Different from Traditional Testing

INTERNET/Networking Basics for Testers

Basic Types of Tests and What to Look For

Browser Basics and How to test within the browser

Discuss installation testing
Discuss configuration and compatibility testing
Discuss what to look for in functionality and UI testing

http://www.crestechsoftware.com

An interactive process of concurrent product exploration, test design, and test execution. The heart of exploratory testing can be stated simply: The outcome of this test influences the design of the next test.

The plainest definition of exploratory testing is test design and test execution at the same time. This is the opposite of scripted testing (predefined test procedures, whether manual or automated). Exploratory tests, unlike scripted tests, are not defined in advance and carried out precisely according to plan. This may sound like a straightforward distinction, but in practice it’s murky. That’s because “defined” is a spectrum. Even an otherwise elaborately defined test procedure will leave many interesting details (such as how quickly to type on the keyboard, or what kinds of behavior to recognize as a failure) to the discretion of the tester. Likewise, even a free-form exploratory test session will involve tacit constraints or mandates about what parts of the product to test, or what strategies to use. A good exploratory tester will write down test ideas and use them in later test cycles. Such notes sometimes look a lot like test scripts, even if they aren’t. Exploratory testing is sometimes confused with “ad hoc” testing. Ad hoc testing normally refers to a process of improvised, impromptu bug searching. By definition, anyone can do ad hoc testing

What kinds of specifics affect ET? Here are some of them:

1. the mission of the test project
2. the mission of this particular test session
3. the role of the tester
4. the tester (skills, talents, and preferences)
5. available tools and facilities
6. available time
7. available test data and materials
8. available help from other people
9. accountability requirements
10. what the tester‘s clients care about
11. the current testing strategy
12. the status of other testing efforts on the same product
13. the product, itself- its user interface - its behavior - its present state of execution - its defects- its testability- its purpose
14. what the tester knows about the product- what just happened in the previous test - known problems with it- past problems with it - strengths and weaknesses - risk areas and magnitude of perceived risk - recent changes to it - direct observations of it- rumors about it - the nature of its users and user behavior - how it‘s supposed to work - how it‘s put together - how it‘s similar to or different from other products
15. what the tester would like to know about the product.

http://www.crestechsoftware.com

One of the most difficult aspects of software development is the integration and testing of large, untested sub-systems. The integrated system frequently fails in significant and mysterious ways, and it is difficult to fix it

Integration testing exercises several units that have been combined to form a module, subsystem, or system. Integration testing focuses on the interfaces between units, to make sure the units work together. The nature of this phase is certainly ‘white box’, as we must have a certain knowledge of the units to recognize if we have been successful in fusing them together in the module.

There are three main approaches to integration testing: top-down, bottom-up and ‘big bang’. Top-down combines, tests, and debugs top-level routines that become the test ‘harness’ or ’scaffolding’ for lower-level units. Bottom-up combines and tests low-level units into progressively larger modules and subsystems. ‘Big bang’ testing is, unfortunately, the prevalent integration test ‘method’. This is waiting for all the module units to be complete before trying them out together.

Integration tests can rely heavily on stubs or drivers. Stubs stand-in for finished subroutines or sub-systems. A stub might consist of a function header with no body, or it may read and return test data from a file, return hard-coded values, or obtain data from the tester. Stub creation can be a time consuming piece of testing.

The cost of drivers and stubs in the top-down and bottom-up testing methods is what drives the use of ‘big bang’ testing. This approach waits for all the modules to be constructed and tested independently, and when they are finished, they are integrated all at once. While this approach is very quick, it frequently reveals more defects than the other methods. These errors have to be fixed and as we have seen, errors that are found ‘later’ take longer to fix. In addition, like bottom up, there is really nothing that can be demonstrated until later in the process.

http://www.crestechsoftware.com

An interactive process of concurrent product exploration, test design, and test execution. The heart of exploratory testing can be stated simply: The outcome of this test influences the design of the next test.

The plainest definition of exploratory testing is test design and test execution at the same time. This is the opposite of scripted testing (predefined test procedures, whether manual or automated). Exploratory tests, unlike scripted tests, are not defined in advance and carried out precisely according to plan. This may sound like a straightforward distinction, but in practice it’s murky. That’s because “defined” is a spectrum. Even an otherwise elaborately defined test procedure will leave many interesting details (such as how quickly to type on the keyboard, or what kinds of behavior to recognize as a failure) to the discretion of the tester. Likewise, even a free-form exploratory test session will involve tacit constraints or mandates about what parts of the product to test, or what strategies to use. A good exploratory tester will write down test ideas and use them in later test cycles. Such notes sometimes look a lot like test scripts, even if they aren’t. Exploratory testing is sometimes confused with “ad hoc” testing. Ad hoc testing normally refers to a process of improvised, impromptu bug searching. By definition, anyone can do ad hoc testing.

What kinds of specifics affect ET? Here are some of them:

1. the mission of the test project
2. the mission of this particular test session
3. the role of the tester
4. the tester (skills, talents, and preferences)
5. available tools and facilities
6. available time
7. available test data and materials
8. available help from other people
9. accountability requirements
10. what the tester‘s clients care about
11. the current testing strategy
12. the status of other testing efforts on the same product
13. the product, itself- its user interface - its behavior - its present state of execution - its defects- its testability- its purpose
14. what the tester knows about the product- what just happened in the previous test - known problems with it- past problems with it - strengths and weaknesses - risk areas and magnitude of perceived risk - recent changes to it - direct observations of it- rumors about it - the nature of its users and user behavior - how it‘s supposed to work - how it‘s put together - how it‘s similar to or different from other products
15. what the tester would like to know about the product

http://www.crestechsoftware.com