What is new in TestComplete 8 ? – Part 2

DDT enhancements

Data Driven testing is well supported in this version of TestComplete. The enhancement ‘Data-Driven loop’ is mainly useful for Keyword-driven testing. Usually keyword-driven test can be done with minimum programming/coding knowledge. This ‘Data-Driven loop’ feature still makes it easier to implement without much of technical knowledge.

If your keyword-driven test has repeated actions and differ only with test data, then you can opt for this feature.

To turn the repeated code as a loop with different data, simply select the set of actions (test steps or sub-actions) which you want to turn in to loop and right-click to get the pop up menu. Select ‘Make Data Loop’ option to get the data source configuration wizard.

Selecting or creating data source, configuring how and which data to be read, binding with test steps and much more can be done through this wizard itself.

Based on the data source (Excel, CSV, DB table), the configuring and data selection process (wizard options) will differ. But this wizard will be very useful and can use with minimum programming knowledge.

The good part is after specifying the data source file; it will be visualized inside the wizard itself.

• You can view the data in worksheets in case of Excel worksheet
• Comma separated values in case of CSV.
• Content of tables in case of DB tables

 

This wizard will reduce the typo errors, data source connection problems, test data range specification etc.,

Note: In the script based automation we can reap the above DDT advantages using its built-in drivers, methods and properties.

https://automate101.wordpress.com/2010/07/27/data-driven-testing-with-testcomplete-part-2/

Network suite enhancements

 

Networksuite has a good number of improvements in TestComplete 8. Among these I like automatic logging/Reboot on remote machines and visualizing the remote desktop screens.

Now you can write a script to login/reboot and remote machines which you treat as client and start test suites there.

Also the remote machines desktop screen can be viewed inside the network suite panel. This allows us to track the execution without manually log-in into those systems.

I have to really explore more on this feature because it is said that GUI tests run via the Remote Desktop do not fail if the Remote Desktop is minimized or closed during the test run. Need to know exact difference between TestComplete 7.52 and 8.

TestLog enhancements

 

If you have used test Visualizer while recoding the scripts, it will replay with synchronization to the recorded images while playing back.

We can view the actual image and expected images in the test log once the test were completed. These log items will show as an image comparison where we can analyze the image to find the root cause if it has the failure.

Comparison of Expected and Actual screen shot

 

Now the test logs can be exported as bugs to JIRA, OnTime and Software Planner. This feature minimizes the bug logging and tracking of it.

As we have methods and properties to access test log items using script, this version has new “LogItem.Status” property to determine its status of specified LogItem. These set of methods and properties will be useful when you want to parse the execution log and prepare/document the data that is interested for you.

Script Extension enhancements

1. The next version of WMI (1.1) scripts are added to Script Extensions to support most likely used functions. A total of 10 new functions were added in this version.
2. The bug reporting mechanism to JIRA, OnTime and Software Planner were implemented as script extensions

Still exception handling mechanism can be improved in Script Extension. Also more objects like Registry, Stores etc., can be given access inside script extensions.

Others

In the Toolbar -> options menu item, we can configure the TestComplete options.

• ‘Images’ and ‘When referring to an non-existence object’ items are moved from General list.

• ‘Debug Services’ option was removed

• New option “Java Bridge” is added to map the JVM (for supporting java classes)

• Under “Recording” option, the option to ‘Record text input into simple editors as’ will allow us to use “SetText” or “Keys” function. Also you can set to record only user action on TestedApps application and skip other actions.

• The option “Visualizer” is removed in this version.

• We can configure the sorting of categories displayed in object browser using the option Panels -> Object Browser -> Categories sorting

You can directly send error reports to AutomatedQA support using “Help -> Contact support team” menu option, which will open the new support form of TestComplete.

If you come across any differences/ enhancements in TestComplete 8, please share here…

 

Hope there is 101 ways to automate…

Thanks & Regards,
Giri Prasad

Data-Driven Testing with TestComplete – Part 2

In this continued post we will discuss the data driven approach in detail with examples.

Test data access mechanism in TestComplete for DDT

This diagram explains how DDT is implemented in TestComplete. Looking at it you can understand how DDT object acts as an interface between the Data Source and our scripts.

The DDT object is implemented as an extension (Using COM mechanism) in TestComplete. In order to use it we need to make sure it is installed in our TestComplete. This extension is installed by default. You can verify it in [ File -> Install Extension ].

The DDT object has separate drivers for data sources like Excel, CSV and ADO tables. The main advantage of having these drivers is we can use same code ie., access properties and methods of DDT object independent of data source. Based on the data source use the driver from DDT object.

For example,

function TestDDTDriver()
{
//Connect to ADO data source through windows authentication
var objDB = DDT.ADODriver(“*ADO table connection string*”);
ReadData(objDB);
DDT.CloseDriver(objDB.Name);

//Connect to CSV data source
objDB = DDT.CSVDriver(“CSV File path”);
ReadData(objDB);
DDT.CloseDriver(objDB.Name);

//Connect to excel data source
objDB = DDT.ExcelDriver(“Excel File path”,”Sheet-Name”);
ReadData(objDB);
DDT.CloseDriver(objDB.Name);
}

function ReadData(objDB)
{
while(! objDB.EOF())
{ var strRecord  = ""
for(var idx=0; idx <strong><</strong> objDB.ColumnCount; idx++)
{
strRecord += objDB.Value(idx) + " --- ";
}
Log.Message(strRecord);
objDB.Next();
}
}</pre>
<pre>

I am using a general “ReadData” function to read various kind of data source just by connecting through different drivers.

Thus the complexity of manipulating different data sources is abstracted by DDT object and gives a clean and easy way to access them.

The key point behind this idea was, we can imagine the data source as rows and columns as similar to DB tables and neglect how Excel or CSV actually stores the data.

So how exactly this object gets the schema of each data source…

The assumptions are,

• The object assumes that each row in your CSV/EXCEL file contains data for one test run. Files that use multiple rows for one run are not supported.
• The column names are specified by the first line of the file.
• To retrieve data from the file, the object uses Microsoft Jet Engine.
• While connecting to Excel files we have option to switch to ACE drivers. (Supported for Microsoft Office 2007 and later).

Also we can override the default comma (“,”) as delimiter in CSV files. The format of the CSV file is determined by using a schema information file, named Schema.ini, and located in the same folder as the CSV file. Schema.ini can keep information about several files and for each file it provides data for the general format of the file, field names and field types, used character set, delimiter character, and a number of other data characteristics. For example:

; The contents of the Schema.ini

[MyData.csv]

Format=Delimited(#)

CharacterSet=ANSI

Now the driver will read the CSV file “MyData.csv” with delimiter “#”.

Another best practice I would like to mention is, always close the opened connections with data sources. (Even though Jet Engine has a limitation of 64 connections per process).

Hope there are 101 ways to automate…

Thanks & Regards,

Giri Prasad

Data-Driven Testing with TestComplete

Hi All,

To start with we should first understand what is DDT?

• Data-driven testing is a term used in the testing of computer software for the creation of re-usable test logic to reduce maintenance and improve test coverage. … en.wikipedia.org/wiki/Data-driven_testing

• A scripting technique that stores test input and expected results in a table or spreadsheet, so that a single control script can execute all of the tests in the table. Data driven testing is often used to support the application of test execution tools such as capture/playback tools. www.infodiv.unimelb.edu.au/knowledgebase/itservices/a-z/d.html

• Testing in which the action of a test case is parameterized by externally defined data values, maintained as a file or spreadsheet.  www.astrainfotech.com/software-testing-glossary.html

Where DDT is more associated – Manual testing or Automation testing?

DDT is done where the functionality need to be tested for a range of data. Here the flow won’t change and only the data required will be changed for each execution. My understanding is we can achieve good results in DDT if implemented in automation than manual testing.

So when one thinks on implementing DDT through automation he/she has to decide on many factors.

1. How the data is to be maintained?
2. How the scripts are to be organized?
3. How the driver script is to be interfaced with data and actual test script?
4. Is the implementation feasible/extendable?

When one has answers for the above questions he has a DDT framework too.

The success of DDT Framework relies on organizing test data, Scripts (Driver script+Test script) and implementing with scalability and flexibility.

Let us see how TestComplete supports DDT.

TestComplete has a good support to organize test data, has in-build driver object (DDT driver) to connect with data store and support from TestLog to report the execution results.

Data storage support :

TestComplete supports test data stored in usual data stores such as Excel, CSV and ADO database tables. In addition to this, we can store our test data in TestComplete’s project suite variables or project variables. Most importantly these project variables support data to be stored on a table like structure (2-D array).

Script storage support :

Scripts can be organized inside TestComplete with

• ProjectSuite :- Holds one or more TestComplete projects
• Project :- Collection of test items – scripts, stores, object repository and tested application storage
• Folders – Logical grouping for scripts and files inside a project

Has option to reuse the scripts across projects.

Driver support:

Once the scripts and data are placed in the corresponding location we need to interface it through data drivers. To simplify access to data stored in Excel sheets, ADO databases or CSV files, TestComplete includes special driver (DDT Driver) that hide the actual data storage format and let you access data using a unified table-like interface.

In the next post we will discuss in detail what to be  done to achieve DDT  through TestComplete

Hope there are 101 ways to automate…

Thanks & Regards

Giri Prasad