Let's look at a few criteria that help to distinguish good from poor candidates:

• Length and complexity of the test
• Number of test permutations
• Ability to predict test results

This first recommendation might seem like common sense: choose tests which are short and relatively free of complexity. Especially when new to test automation, select tests that involve only a few pages or screens in your application. Avoid long, complex transactions and tests that involve more than one software application. Once you have built up a library of reusable test steps, you can then think about combining them to form more advanced tests.

Choose tests that have many data permutations. Almost every application has processing paths that need to be traversed with lots of different combinations of data. By creating a reusable test that separates actions from data, you can get a good return on your time investment by passing many sets of data to your data-driven test. For the amount of work that it takes to create one automated tests, you can cover many different test requirements.

Some tests include verification steps that change frequently. Until you develop the skills to automate the generation of expected results at runtime, stick to tests where the expected results are stable. It's worth the time and effort to manage the test data environment before you begin developing automated tests so that you can be sure that results are predictable and stable.

The test plan on the left in the figure above displays a simple list of tests. Notice how it repeats information like the words ‘Missing’ and ‘Required Field’. It’s not easy to figure out what is being covered without studying it. The test plan on the right is structured. A quick look informs the reader that there are three types of tests, ‘Required Fields’, ‘Confirmed Fields’ and ‘Formatted Fields’. During a peer review, it’s easy to guess that one of the first questions that will be discussed is whether all of the required, confirmed and formatted fields are covered. Reviewing a plan written graphically encourages the test plan writer and the reviewer alike to drill down deeper to ensure comprehensive coverage. In a simple example like the one presented above, the difference in the two planning approaches may be subtle, but if you imagine a more complex test problem, the advantage of the outline-based format will quickly become evident. For a full description of AscentialTest's test planning capabilities, please submit an Information Request from the Zeenyx website.

Organizations can significantly cut testing cycles by adopting the step-based testing approach to building manual and automated tests. Unlike keyword-driven testing, the step-based approach does not require the development of a test framework. Instead of requiring testing teams to create layers of spreadsheets to define tests and keywords along with supporting files of functions that need to be either recorded or scripted, the step-based approach generates all of the test components based on the objects and actions selected. The keyword-driven approach advertises the division of labor as a benefit. Proponents claim that it allows domain experts to participate in the automation effort. But organizations waste time needlessly because of miscommunication and duplication of effort. The step-based approach allows effective tests to be built by the team members who understand the application whether or not they have programming experience.

Because manual and automated tests are built upon a common structure in the step-based testing approach, transitioning from one to another is a quick and easy process that can be accomplished by the very team members who designed the tests.

The step-based approach was designed to anticipate change. Because tests, test steps and test data are all reusable, there is virtually no duplication. Consequently maintenance is kept to a minimum. When there is one change in the AUT, there is typically one change across test components.

Perhaps the greatest benefit of the step-based approach is the ability that it provides to reuse test components across multiple platforms. Whether your application is moving from a legacy platform to the web/cloud or your organization plans to support applications in both web and mobile environments, test components created around business logic for one version of the application are fully leveraged on subsequent projects. Since only a new object definition is required to reuse all of the existing test components, organizations receive an even larger return on investment with each new project.

Likewise, many organizations have more than one application that perform a similar function but for different customers or users. For example, an eCommerce vendor may have more than one web storefront to cater to various types of buyers. Despite a different user interface, the step-based approach allows the testing components to be reused saving significant time and money.

For more information on step-based testing, visit Zeenyx on the web at www.zeenyx.com

The Zee language allows classes to be extended. This feature allows the user to add methods and properties to a built-in or user-defined class. To extend a class, use the keyword ‘extend’ as in the following example:

extend class Math

static Number MyNewMethod (Number nValue)

{body of method}

MyNewMethod is now available along with all of the other built-in methods of the Math class. Here are some notes to enhance your understanding of ‘extend’:

• Methods and properties can be added to user-defined or built-in classes.
• Regular and app classes can be extended.
• Properties can only be added for app classes.
• Built-in types that provide methods, like Integer, Enum, Real, String can not be extended.
• Classes can be extended in the same or in different files from the base class being extended.

Extension methods and properties are called like their regular counterparts.

Metadata is similar to annotations in java or attributes in C#. Metadata can be used to mark an object with a value that can be queried at runtime. For example, you can mark all of the app objects in your application with a required field attribute so that a generic test can read the value to determine whether or not to include it in a ‘required field’ test.

Metadata is implemented in Zee as a class. All custom metadata derives from the built-in class Metadata. To add metadata to an AppObject, first create a class as in the example below:

class  CustomData : Metadata   
String  System  
Integer Version

Then apply the metadata to your AppObjects and assign values as in the example below.  The order of the members inside the square brackets does not matter since field/value pairs are used:

WebPage MyPage   
WebTextField MyTextField    %CustomData[System="MySystem",Version=3]

In the previous example, each member of the metadata class was assigned using a field/value pair. An alternate way to assign metadata is to list the members in order as in the example below:

WebPage MyPage   

WebTextField MyTextField  %CustomData["MySystem",3]

To refer to metadata in functions and tests, use the % operator as in the example below:

String SystemName = MyPage.MyTextField.%CustomData.System

It is also possible to create a metadata class without member elements as in the example below. In this case the value of the metadata will be false if it is not assigned to an AppObject. Otherwise it will return true.

class ObsoleteIndicator : Metadata

WebPage MyPage

WebTextField MyTextField %ObsoleteIndicator  
WebTextField MyTextField2 


Print (MyPage.MyTextField.%ObsoleteIndicator)
//Prints  true

Print (MyPage.MyTextField2.%ObsoleteIndicator)
//Prints   false

Here are some notes to enhance your understanding of Metadata:

• Metadata can not be inherited.
• It is not necessary to assign all members of a metadata class to an AppObject. If a member that is not assigned a value is accessed at runtime, a null value will be returned.
• If the members of the metadata class are assigned to an AppObject in order without using the name of the member, members must not be skipped, but it is not necessary to assign all members of the class.
• The fields in a metadata class are constants. If they are listed in a metadata assignment, they must be provided with a value.
• The following classes are supported for metadata member elements: Boolean, Date, DateTime, Enumerated Type, Flags, Integer, List, Number, Real, Record, String, Time and Type.