In Part 1 we'll detail the User Interface for creating tests. At this point forget QTP, or any other test tool. The creation of an application like this, is independent of and does not rely upon any test-tool-specific functionality. An application, or UI, for automated tests has inputs and outputs that should be configurable. The main input is the target application inputs. There are 3. These are the location of existing tests, the location of keyword files to be used in tests and any assets (data, object metadata) for a specific application. The main output is the created tests. In our case this is xml. The schema of resultant xml files may be application specific, but in our case it should be a fairly basic schema that could be applied to most, if not all applications. When a test tool is introduced, the framework that drives the test tool has to comply with the xml schema output by the test editor UI.

There are 2 main components to Part 1. Firstly, I’ll walk you through the Test Editor sample application and explain how to perform core functions. Next I would like to touch on test automation project design and analysis. It may seem logical to get all the technical stuff out of the way first and then talk about how to use this newly created test framework. The reason I choose to do this upfront is that once you understand what I’m showing you in this part, you can start creating tests straight away. It will also add perspective to the entire project. This may be beneficial to users new to test automation project design and management.

Prerequisites

1. Test Editor sample application. This comes with a few sample files
    based on the sample Flight application that comes with QTP

2. Please visit the HP website and install an evaluation copy
    of QTP, if required. We won’t be running tests, but you
    may need QTPs sample flight application. If you don’t
    want to waste evaluation time (currently 14 days) then
    don’t run QTP until we need to.

After installing Test Editor it should open automatically. If it is closed you can open it by clicking

Start -> All Programs -> Shawn Barrett -> Test Editor.

A standard flow for using Test Editor may be,

1. Create / Open test category in tree on the left hand side. All tests within selected test category
    are displayed in the right hand top list

2. Select a test to load test details into test grid below for editing. To create a new test either, enter
    new details into blank test grid and click save or, load an existing test, change the test name, edit details
    and click save.

3. Test steps may be added, removed, moved up and down by using the toolbar buttons.
    You can cut, copy, paste test steps between tests or within the same test.
    a. Adding Test Steps
        The list on the bottom right contains keywords to be used by test steps. Keywords
        are application specific and can be filtered using the drop down above the list. Currently
        we have QTP keywords. Each keyword in the list has a help balloon to the left of the
        keyword name. This shows information about the keyword when you hover your mouse
        over it. To add a keyword to your test select the row in the grid where you would like to
        insert the test step (keyword) and either double-click the keyword or use the toolbar buttons
        to the right of the test grid.
    b. Removing Test Steps
        Delete one test step by clicking on the relevant test step and clicking the cut toolbar button
        next to the test grid.
        Delete multiple test steps by clicking the first step to delete, dragging your mouse to the
        last step to delete, before letting your mouse go. Select the Remove toolbar button.
        Delete a selection of test steps by holding down your Ctrl key and clicking the test
        steps to delete. Click Cut.
    c. Editing Test Steps
        Single or multiple steps may be selected and moved up or down using the toolbar
        buttons next to the test grid. Inspect the context menu that appears when you right-click
        a selection of test steps.

Test step columns are made of mandatory fields and dynamic fields. So looking at the image above,

Column 1: Test Step index
Column 2: Loop times. How many times you would like to execute this step
Column 3: Execute button. This is a placeholder for future functionality we’ll add to execute test
                steps directly from the test editor
Column 4: This is a placeholder for future functionality we’ll add to specify which test framework we
                would like to use to execute the current step. It is highly conceivable that you may want to execute
                some API test steps before running a QTP step to verify UI state.
Column 5: Keyword name. This name will exist in the list on the bottom right. It maps to the VBScript
                method that will be executed when this test step is parsed by the QTP framework.
Column 6 to n: A keyword may require any number of parameters in order to carry out its action. 
                Therefore the number of parameters is not fixed. “Login” has 2 parameters, but “AddOrder” has 7. 
                So the given parameters for each keyword are supplied to the keyword VBScript method .

4. Add test details and save edited or newly created tests.

That is a brief overview of how the application may be used. Next we’ll dive deeper and I’ll show how we
create the keywords and make them available to the Test Editor. We’ll examine the structure of tests, keyword
files and I’ll explain what exactly is under the UI of the sample application. I’ll also provide a brief comparison between this user interface and traditional spreadsheet usage.

Please e-mail me if you have any questions, issues installing or you receive any errors when using the application.

Create Test Automation Framework – Introduction         Create Test Automation Framework – Part 1b

1. Create tests
2. Add test definitions to QC automatically.
3. Schedule and execute tests in QC
4. QTP is invoked and runs specified tests
5. Test results are uploaded to QC

The above diagram outlines the high-level architecture for the test automation framework we will create. I have chosen to use QTP as the underlying test automation "engine". Why? Typically keyword / data driven QTP frameworks are pretty similar, but in many cases the front end, to create the tests, is excel. That in itself is not necessarily a bad thing, but test templates may not be intelligent. Standards in test creation may not exist or test steps require manual entry. Experienced users of such environments rely on copy and paste when creating new tests. Data to populate the test step parameters may not be data driven or difficult to maintain. Using XML as a test format gives us some nice advantages. We save more than half on disk space (I use compression and serialisation in this project). We can diff files in source control (This project will deal with source control later) and more. Converting from XML to XLS(X) is very easy and this can be done if you have an existing QTP test schema that you use. The front end is written in C# (.NET 3.5) and I use Visual Studio 2008.

We will make Quality Centre (QC) the prime candidate for scheduling test execution. This will give you an idea of how to use the QC API. I will also show how we can run tests directly from the test editor (1). This will detail QTP API usage.

We will make use of VBScript to create the QTP framework. This will contain a driver script that will retrieve tests created in the Test Editor when a run is triggered in QC. Each test will be parsed and for each row in the test a VBScript call will be made to execute a VBScript that may be interspersed with QTP functionality. For example,

Step 3, when executed, will cause the driver script in the QTP framework to call a VBScript method "flight_AddOrder" and it will pass the subsequent fields as parameters,

Flight_AddOrder("17-03-2010","31-03-2010","London","Denver")

Notice the drop downs in the test step. These are dynamically populated when you add the test step to the grid.

Notes:

This is the outline for this project. When complete, I will expand this to include other test automation "engines"; Rational Robot, Selenium2, API integration/ Unit tests. I am also interested in showing you how to bypass VBScript for keyword code creation. So we'll create a C# engine that will drive QTP (or any other test automation tool).

Stay tuned...

Create-Test-Automation-Framework - Part-1a